利用预计算上下文，更快速、更低成本地开展支持问题调查-北京尧图网络

作者来自 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 IndicatorsKIs。随后文章解释了 agent 如何在扫描原始文档之前先检索这些精简的记录。针对这一支持场景我们希望了解哪些上下文值得提前准备以及上下文的选择如何影响响应效率和可靠性。我们还希望弄清楚当 agent 可以使用多种类型的 KI 时需要制定哪些检索规则。本文将介绍这一设计过程并报告相关研究结果。从索引 profiles 入手我们从索引 profile KI 入手。一个工作流会读取每个支持索引的 Mapping并抽样读取几条文档。随后它会生成一份精简的概况描述该索引的用途、能够回答的问题、重要字段、排除项、经过验证的 Join 关系、时间覆盖范围、示例 Elasticsearch 查询语言ES|QL查询等内容。一个具有代表性的 KI 文档及其部分选定字段如下{ _id: index-profile-support-cases, _source: { type: ki, title: Index profile: Support cases, origin: { uri: ki://support-cases }, tags: [ki-kind:index-profile, index-selection, support-data], content: [ BACKING_INDEX: support-cases, PURPOSE: Primary metadata and the customer-reported problem for enterprise support cases (status, product, severity, reported symptom)., 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?, 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., KEY_FIELDS: case_number, subject, status, product, severity, created_at, resolved_at, EXAMPLE_QUERY: FROM support-cases | WHERE product \elasticsearch\ AND status \open\ | KEEP case_number, subject, severity, created_at | LIMIT 20 ], 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. } }这些概况帮助 agent 选择数据源并构建查询。它们减少了前期的信息梳理工作尤其是在索引名称或字段名称不明确时但并没有消除工单调查的主要成本。选择索引后agent 仍然需要收集工单记录并重建对话内容。它们还需要跟踪指向工程和知识来源的链接然后整合并核对证据。路由确实很有用但反复进行的综合分析才是主要工作。改变上下文的组织单位这一观察促使我们转向工单级 KI。工作流会为每个符合条件的工单生成一个包含证据信息的快照。它会收集工单记录、近期重要的对话事件、关联的工程问题及评论以及关联的知识文章。生成的 KI 文档包含稳定的工单标识符和来源引用还包含标签和新鲜度元数据。随着我们逐步梳理支持场景中的特定细节设计也变得更加完善。支持对话中包含初步推测、后续更正、管理状态变更有时还会在同一个工单中涉及多个独立故障事件。单一、流畅的摘要可能会模糊这些区别。因此工单 Schema 会记录故障事件阶段、包含已确认、推断、相互矛盾和未解决等状态的假设清单、根本原因状态及置信度、技术处理结果、可复用的经验等更多信息。由于大语言模型LLMs可能会对其中某些细节产生幻觉我们在生成后增加了确定性检查。例如尚未确定的根本原因必须留空且置信度必须较低。推断得出的根本原因不能具有高置信度。在客户关系管理CRM系统中标记为已关闭的工单需要与技术问题是否已解决分别进行评估。这些检查可以修复结构上的矛盾而无需再次调用模型来重新解读证据。一个具有代表性的 KI 文档及其部分选定字段如下{ _id: 1234567, _source: { type: ki, title: Case 1234567: Cluster writes blocked after disk flood-stage watermark breach, origin: { uri: case://1234567 }, tags: [ ki-kind:case-intelligence, support-data, cohort:closed, technical-outcome:resolved, rca-confidence:high ], references: [ { uri: case-number://1234567 }, { uri: https://github.com/elastic/elasticsearch/issues/00000 } ], content: [ CASE_NUMBER: 1234567, STATUS: Closed, PRIORITY: High, 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., PROBLEM_AND_IMPACT: Indexing failed cluster-wide with FORBIDDEN/12/index read-only; the customers ingest pipeline was stalled for 1 hour., PRODUCTS_AND_COMPONENTS: Elasticsearch, disk-based shard allocation., 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., 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., 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., ROOT_CAUSE_STATUS: confirmed, ROOT_CAUSE_CONFIDENCE: high, 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., TECHNICAL_OUTCOME: resolved, 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. ], 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. } }图 1. 工作流根据实际观察到的限制逐步完善。每一项新增内容都针对重复劳动、噪声或检索失败的特定来源。仅在有用时生成 KI经过几轮迭代后我们意识到为每个工单都生成 KI 会增加成本和噪声。许多工单几乎没有可用的证据。有些工单只有一条简短的初始提交信息另一些则没有实质性的对话记录也没有支持工程师的确认回复。因此我们在工作流中增加了门槛和过滤条件。例如当工单具有关联的工程证据或者至少包含两个重要的对话事件其中包括支持团队参与的证据时才会继续处理。工作流会将已存储 KI 的水位标记watermark与工单及其重要对话记录中的最新时间戳进行比较。如果工单没有变化就复用现有 KI而不是每次都重新生成。工作流通过优先处理近期工单或其他可能被查询的工单限制纳入语料库的范围尤其是在源语料库规模较大时。当关联的数据源可以独立发生变化时工作流也会刷新工单 KI而不是仅仅依赖可能不完整的水位标记。对于延后处理的工单仍然可以通过原始数据查询获取相关信息并在有新活动出现后重新评估。来源溯源信息也是已存储 KI 的一部分引用会指向关联的数据源输出还会记录缺失或无法验证的信息。KI 可以缩短常规调查所需的时间同时仍然保留原始记录以便查询最新状态、完整历史、附件以及生成的快照之外的证据。图 2. 工单级上下文将重复的证据收集工作转移到预计算工作流中。响应路径仍然保留原始数据验证和回退机制。检索 skill 是系统的一部分工作流负责生成 KI而 agent 还需要检索指导才能有效地使用这些 KI。为此我们开发了一个检索 skill其中提供了用于查询索引中存储的 KI 的 ES|QL 模板以及何时使用每种检索方法的指导。例如已知工单编号时会采用词法检索因为它是一个精确标识符。对于相似工单或先例相关的问题则使用词法与语义相结合的混合检索对于官方知识、工程问题、评论或其他非工单实体相关的问题则先从索引概况入手然后查询选定的原始数据源。该 skill 还为每一类 KI 明确分配了职责。索引概况提供数据源路由和字段使用指导而工单 KI 则提供与某个工单相关证据的有限快照。如果没有可用的工单 KIagent 会将其视为缓存未命中并根据索引概况的指导回查底层数据而不是假定现有上下文已经完整。这种区分在典型的工单查询过程中非常重要。对于 “工单 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

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

相关推荐

巴菲特投资体系实战拆解：能力圈、护城河与安全边际

Playwright自动化测试实战：从Selenium迁移到动态页面抓取

给编码助手接入实时搜索：基于MCP的Google搜索配置指南

更多资讯

2026年降AI率工具真实测评：10款改写工具的优劣与使用边界

BigBanana AI Director：一站式AI短剧与漫剧导演平台工程实践

BigBanana AI Director：工业级AI短剧与漫剧全流程制作实战指南

深入理解Spring三级缓存：循环依赖的机制、局限与排查实践

用编程思维打造个人知识体系：IoC、依赖注入与响应式学习实操指南

联邦学习赋能大模型WAF：破解数据孤岛与攻击变异难题

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？