利用预计算上下文，更快速、更低成本地开展支持问题调查

作者：来自 Elastic Abhimanyu Anand

预计算上下文使 Elastic 的支持 agent 的输入 tokens 减少了 58%，延迟降低了 40%，通过减少重复检索，提高了支持问题调查的效率。

Agent Builder 现已正式发布（GA）。立即开始使用 Elastic Cloud 试用版，并点击此处查看 Agent Builder 文档。

当支持工程师接到一个工单时，需要回答的问题可能看起来很简单：发生了什么？有哪些证据支持根本原因的判断？接下来应该采取什么措施？这些答案可能分散在工单记录、冗长的对话流、关联的工程问题及评论、知识文章和相关工单中。预计算上下文会在 agent 收到问题之前，收集并整理这些相关记录中的证据。这样，agent 就可以直接利用已经识别出的工单关联关系开始工作，而不必在每次回答时重新梳理这些关系。在我们的评估中，这种方法降低了输入 tokens 的使用量和延迟，同时事实准确性没有出现统计学上显著的下降。

在引入预计算上下文之前，Elastic 的支持团队已经使用 agent 来调查工单、进行根本原因分析（RCA）、分诊以及处理相关工作。为了回答问题，agent 必须先发现相关索引、检查 Schema、执行多次查询、协调相互矛盾的更新信息，然后整合出答案。问题的范围从简单的状态查询到涉及多个数据源的调查，不一而足：

支持工单 1234567 的当前状态和优先级是什么？
客户 ABC 的集群迁移证书后，出现了安全套接字层（SSL）握手错误和 certificate_unknown 错误。故障原因是什么？应该如何修复？有哪些相关的知识库文章？
客户 ABC 的集群停止处理索引请求，并返回 rejected execution of primary operation 错误。根本原因是什么？服务是如何恢复的？

当用户继续询问同一个工单或相关工单时，通常仍然需要重复进行大量相同的信息梳理和综合分析工作。这种重复消耗了输入 tokens，并增加了延迟。同时，它也提高了生成无效查询或选择错误数据源的可能性。

此前关于预计算上下文的研究为我们提供了一个起点。该研究介绍了如何提前提取有用的上下文，并将其存储为结构化的知识指标（Knowledge Indicators，KIs）。随后，文章解释了 agent 如何在扫描原始文档之前，先检索这些精简的记录。

针对这一支持场景，我们希望了解哪些上下文值得提前准备，以及上下文的选择如何影响响应效率和可靠性。我们还希望弄清楚，当 agent 可以使用多种类型的 KI 时，需要制定哪些检索规则。本文将介绍这一设计过程，并报告相关研究结果。

从索引 profiles 入手

我们从索引 profile KI 入手。一个工作流会读取每个支持索引的 Mapping，并抽样读取几条文档。随后，它会生成一份精简的概况，描述该索引的用途、能够回答的问题、重要字段、排除项、经过验证的 Join 关系、时间覆盖范围、示例 Elasticsearch 查询语言（ES|QL）查询等内容。一个具有代表性的 KI 文档及其部分选定字段如下：

swift 复制代码

`

1.  {
2.    "_id": "index-profile-support-cases",
3.    "_source": {
4.      "type": "ki",
5.      "title": "Index profile: Support cases",
6.      "origin": { "uri": "ki://support-cases" },
7.      "tags": ["ki-kind:index-profile", "index-selection", "support-data"],
8.      "content": [
9.        "BACKING_INDEX: support-cases",
10.        "PURPOSE: Primary metadata and the customer-reported problem for enterprise support cases (status, product, severity, reported symptom).",
11.        "QUESTIONS_ANSWERED: What is the status of a case? | Which cases affect a given product or version? | What symptom was reported? | Which high-severity cases are still open?",
12.        "WHEN_TO_USE: Start here to find or filter cases by status, product, or severity before pulling the conversation thread or root-cause detail from other indices.",
13.        "KEY_FIELDS: case_number, subject, status, product, severity, created_at, resolved_at",
14.        "EXAMPLE_QUERY: FROM support-cases | WHERE product == \"elasticsearch\" AND status == \"open\" | KEEP case_number, subject, severity, created_at | LIMIT 20"
15.      ],
16.      "description": "Tells the agent which index holds support-case metadata and how to query it, so it can choose the right data source and narrow to relevant cases before deeper analysis."
17.    }
18.  }

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

这些概况帮助 agent 选择数据源并构建查询。它们减少了前期的信息梳理工作，尤其是在索引名称或字段名称不明确时，但并没有消除工单调查的主要成本。选择索引后，agent 仍然需要收集工单记录并重建对话内容。它们还需要跟踪指向工程和知识来源的链接，然后整合并核对证据。路由确实很有用，但反复进行的综合分析才是主要工作。

改变上下文的组织单位

这一观察促使我们转向工单级 KI。工作流会为每个符合条件的工单生成一个包含证据信息的快照。它会收集工单记录、近期重要的对话事件、关联的工程问题及评论，以及关联的知识文章。生成的 KI 文档包含稳定的工单标识符和来源引用，还包含标签和新鲜度元数据。

随着我们逐步梳理支持场景中的特定细节，设计也变得更加完善。支持对话中包含初步推测、后续更正、管理状态变更，有时还会在同一个工单中涉及多个独立故障事件。单一、流畅的摘要可能会模糊这些区别。因此，工单 Schema 会记录故障事件阶段、包含已确认、推断、相互矛盾和未解决等状态的假设清单、根本原因状态及置信度、技术处理结果、可复用的经验等更多信息。

由于大语言模型（LLMs）可能会对其中某些细节产生幻觉，我们在生成后增加了确定性检查。例如：

尚未确定的根本原因必须留空，且置信度必须较低。
推断得出的根本原因不能具有高置信度。
在客户关系管理（CRM）系统中标记为已关闭的工单，需要与技术问题是否已解决分别进行评估。

这些检查可以修复结构上的矛盾，而无需再次调用模型来重新解读证据。一个具有代表性的 KI 文档及其部分选定字段如下：

bash 复制代码

`

1.  {
2.    "_id": "1234567",
3.    "_source": {
4.      "type": "ki",
5.      "title": "Case 1234567: Cluster writes blocked after disk flood-stage watermark breach",
6.      "origin": { "uri": "case://1234567" },
7.      "tags": [
8.        "ki-kind:case-intelligence",
9.        "support-data",
10.        "cohort:closed",
11.        "technical-outcome:resolved",
12.        "rca-confidence:high"
13.      ],
14.      "references": [
15.        { "uri": "case-number://1234567" },
16.        { "uri": "https://github.com/elastic/elasticsearch/issues/00000" }
17.      ],
18.      "content": [
19.        "CASE_NUMBER: 1234567",
20.        "STATUS: Closed",
21.        "PRIORITY: High",
22.        "SUMMARY: A production cluster stopped accepting writes after a data node crossed the disk flood-stage watermark, which put all indices into read-only mode; freeing disk and clearing the block restored writes.",
23.        "PROBLEM_AND_IMPACT: Indexing failed cluster-wide with 'FORBIDDEN/12/index read-only'; the customer's ingest pipeline was stalled for 1 hour.",
24.        "PRODUCTS_AND_COMPONENTS: Elasticsearch, disk-based shard allocation.",
25.        "INCIDENT_PHASES: Phase 1: disk usage crossed the 95% flood-stage watermark, indices auto-set to read-only. || Phase 2: disk freed and read-only block cleared, writes resumed.",
26.        "HYPOTHESIS_LEDGER: Flood-stage watermark breach auto-applied a read-only block (confirmed); node stats showed disk at 96% and cluster logs recorded the flood-stage event.",
27.        "ROOT_CAUSE: A data node exceeded the flood-stage disk watermark, so Elasticsearch automatically applied a cluster-wide read-only block to protect the nodes.",
28.        "ROOT_CAUSE_STATUS: confirmed",
29.        "ROOT_CAUSE_CONFIDENCE: high",
30.        "RESOLUTION_OR_CURRENT_STATE: Freed disk space (removed stale snapshots/indices), cleared the read-only block, and verified writes resumed; recommended more headroom plus watermark alerting.",
31.        "TECHNICAL_OUTCOME: resolved",
32.        "REUSABLE_LEARNING: When every index goes read-only at once, check disk watermarks first; the flood-stage block is applied automatically but must be cleared manually after space is freed."
33.      ],
34.      "description": "Distilled root cause of a single case: symptom, confirmed root cause with high confidence, resolution, and a reusable lesson so the agent can explain the fix and find precedent for similar cases."
35.    }
36.  }

`AI写代码![](https://csdnimg.cn/release/blogv2/dist/pc/img/runCode/icon-arrowwhite.png)

图 1. 工作流根据实际观察到的限制逐步完善。每一项新增内容都针对重复劳动、噪声或检索失败的特定来源。

仅在有用时生成 KI

经过几轮迭代后，我们意识到，为每个工单都生成 KI 会增加成本和噪声。许多工单几乎没有可用的证据。有些工单只有一条简短的初始提交信息；另一些则没有实质性的对话记录，也没有支持工程师的确认回复。因此，我们在工作流中增加了门槛和过滤条件。例如：

当工单具有关联的工程证据，或者至少包含两个重要的对话事件（其中包括支持团队参与的证据）时，才会继续处理。
工作流会将已存储 KI 的水位标记（watermark）与工单及其重要对话记录中的最新时间戳进行比较。如果工单没有变化，就复用现有 KI，而不是每次都重新生成。
工作流通过优先处理近期工单或其他可能被查询的工单，限制纳入语料库的范围，尤其是在源语料库规模较大时。
当关联的数据源可以独立发生变化时，工作流也会刷新工单 KI，而不是仅仅依赖可能不完整的水位标记。

对于延后处理的工单，仍然可以通过原始数据查询获取相关信息，并在有新活动出现后重新评估。来源溯源信息也是已存储 KI 的一部分：引用会指向关联的数据源，输出还会记录缺失或无法验证的信息。

KI 可以缩短常规调查所需的时间，同时仍然保留原始记录，以便查询最新状态、完整历史、附件，以及生成的快照之外的证据。

图 2. 工单级上下文将重复的证据收集工作转移到预计算工作流中。响应路径仍然保留原始数据验证和回退机制。

检索 skill 是系统的一部分

工作流负责生成 KI，而 agent 还需要检索指导，才能有效地使用这些 KI。为此，我们开发了一个检索 skill，其中提供了用于查询索引中存储的 KI 的 ES|QL 模板，以及何时使用每种检索方法的指导。例如，已知工单编号时，会采用词法检索，因为它是一个精确标识符。对于相似工单或先例相关的问题，则使用词法与语义相结合的混合检索；对于官方知识、工程问题、评论或其他非工单实体相关的问题，则先从索引概况入手，然后查询选定的原始数据源。

该 skill 还为每一类 KI 明确分配了职责。索引概况提供数据源路由和字段使用指导，而工单 KI 则提供与某个工单相关证据的有限快照。如果没有可用的工单 KI，agent 会将其视为缓存未命中，并根据索引概况的指导回查底层数据，而不是假定现有上下文已经完整。

这种区分在典型的工单查询过程中非常重要。对于 "工单 1234567 当前的优先级是什么？" 这样的问题，agent 会通过工单 _id 检索对应的工单 KI，以了解调查情况及其支持证据。随后，它会检查实时工单记录，获取可能发生变化的值，包括状态、优先级以及 updated_at。如果实时记录的更新时间晚于 KI 的最后更新时间，则以实时值为准。KI 仍然适用于提供持久性证据，而源记录仍然是当前状态的权威依据。下一次符合条件的刷新会重新构建 KI，使用工单及其重要对话记录的时间戳，同时也考虑关联数据源的时间戳。

这一设计上的区分源于评估过程中发现的一次失败。在早期版本中，agent 使用工单 KI 来规划检索，却在查询原始数据源时使用了推断出来的 Schema，而不是索引概况提供的字段。查询因此失败，引发了重试和额外的模型处理工作。在后续版本中，我们在 skill 中明确规定了优先级规则、数据源职责、字段使用指导，以及 Mapping 错误的恢复步骤。

图 3. 检索 skill 根据问题类型进行路由。精确工单查询、先例搜索和非工单检索采用不同的上下文路径，同时保留原始证据，以便进行验证和回退。

我们的观察结果

我们使用 20 个不同的问题对 agent 进行了评估，其中每种工作流约有 10 个问题：一类是工单调查与事后总结，另一类是涵盖多种数据源类型的简短技术支持问答。每个问题进行了 3 次试验，以衡量不同运行之间的差异。本文中的示例均在运行 Elasticsearch 9.4.2 的 Elastic Cloud Hosted 部署上进行了测试。

不同的 agent 配置使用相同的回答模型和可比的工具条件。它们的区别仅在于 agent 是否能够访问 KI，以及在可以访问时能够使用哪些 KI：索引 profile KI、工单级 KI，或两者兼有。我们衡量了相对于预期答案的事实准确性、输入和输出 tokens 数量、延迟以及工具执行失败情况。我们还使用单独的 LLM 评判模型对事实准确性进行评分。

在两种工作流中，工单级 KI 都表现出了最明显的运行效率提升。与仅使用原始索引的基线方案相比，观察到的输入 tokens 使用量和延迟变化如下：

工作流	输入 tokens	延迟
工单调查	约减少 58%	约降低 40%
技术支持问答	约减少 43%	约降低 17%

我们注意到，索引概况缩短了数据源梳理所需的时间，但仍然需要 agent 自行整合信息；而工单级 KI 则提供了一组精简的证据集合，与所需的输出内容直接对应。这减少了原始数据查询的次数，也降低了因 Schema 和分区相关问题而导致工具调用错误的可能性。

不同工作流的事实准确性有所差异，但在本次评估中，我们没有观察到具有统计学显著性的下降。

需要注意的是，这些结果应当如何解读：本次评估使用的数据集规模较小。在 agent 开发生命周期的早期阶段，这种做法很常见，也很有价值，因为此时通常还没有大型的标注评估数据集。因此，我们将这些结果视为比较不同方案的方向性信号。这也与 Elastic 以及其他公司（例如 Anthropic）在工程博客中提出的策略一致：从少量源自真实故障的任务开始，随着不同方案之间的效果差异逐渐缩小、产品日趋成熟，再逐步扩展评估任务集。

为什么工单级 KI 适合支持工作

工单级策略在多个方面都契合支持调查工作的特点：

工单编号是稳定的检索锚点。
成本高昂的操作，是反复整合相同数据源关联关系中的信息。
用于解释问题的大部分证据具有持久性，而易变的状态可以单独验证。
KI Schema 与工程师在工单总结和根本原因分析（RCA）过程中提出的问题类型相匹配。
成熟度和新鲜度控制机制会将生成范围限制在证据充足且可能被重复使用的工单上。

索引概况仍然具有价值。它们有助于发现数据源、了解 Schema、回答非工单类问题，以及在必要时进行回退。但对于工单调查，它们仍然需要在响应过程中重建跨数据源的信息关联。工单级 KI 消除了其中一部分重复性工作，这也是我们预期它能在这一领域降低 tokens 使用量和延迟的主要原因。

组合策略暴露了组合方式的问题

在评估回答时，我们发现了一个违反直觉的现象：同时提供索引概况和工单 KI，并没有比单独使用工单 KI 带来更好的效果。检查 trace 后发现，agent 能够理解部分工单上下文，却缺乏可靠的规则来组合使用这两类 KI。它使用工单级 KI 进行规划，但在查询原始数据时忽略了索引概况提供的 Schema 指导，导致查询失败和回答效果不佳。

这带来了一个切实的经验，有助于改进检索 skill 中的指导规则：上下文来源必须明确各自的职责和优先级。agent 必须知道哪个来源能够为答案提供依据，哪个来源仅用于定位证据，何时需要进行验证，以及在缓存未命中或出现 Mapping 错误后应该如何处理。当这些约定不够明确时，即使两种上下文类型各自都很有用，组合使用也可能增加额外的工作量。

关于预计算上下文的经验总结

在这一支持工作流中，最有用的上下文单位是工单及其关联的证据，包括工单记录、对话内容、关联的工程工作和相关知识。提前准备这些证据，意味着 agent 不必在每次响应时都重新梳理相同的关联关系。与仅使用原始索引的基线方案相比，工单级方案的输入 tokens 使用量和延迟均有所降低，同时事实准确性没有出现统计学上显著的下降。

由于工单状态可能发生变化，系统仍然会检查源数据，以获取优先级和工单状态等信息；当现有证据不足以支持生成工单级 KI 时，则会回退到原始数据。

接下来，我们计划测试这一设计在 Salesforce 等外部系统的支持数据上能否保持同样的效果，并确定是否需要进行相应调整。

原文：Precomputed context: How we reduced token usage | Elasticsearch Labs