Elastic-caveman : 在不损失 Elastic 最佳效果的情况下，将 AI 响应 tokens 减少64%

Elasticsearch
0 阅读9分钟

作者：来自 Elastic Sri Kolagani

了解如何使用 elastic-caveman，在保留 Elastic 代理能力优势的同时减少 AI 响应的 token 消耗。

Agent Builder 现已正式发布。通过 Elastic Cloud Trial 开始使用，并查看这里的 Agent Builder 文档。

当通过 AI 助手查询 Elasticsearch 时，你需要的是事实：索引名称、字段映射、Elasticsearch 查询语言（ ES|QL ）查询、案例 ID、情感分数。但现有的大语言模型（large language model -  LLM ）接口会在每个响应外层包裹大量对话性冗余内容：

`

1.  "Of course! I'd be happy to help you..."

3.  "This should give you a good overview..."

5.  "Feel free to let me know if you need anything else!"

`AI写代码

这不仅令人困扰，而且成本高昂。每个 token 都会产生费用并增加延迟。对于生产环境中的 Elasticsearch 查询，这种开销会快速累积。在本文中，我们介绍 elastic-caveman，并分享在一个受控实验中的结果：在 8 个真实的 Model Context Protocol（ MCP ）场景中对一个 Elasticsearch 集群进行测试。结果显示：平均减少 63.6% token、节省 817 个 tokens，并且技术准确性完全没有损失。

引入 elastic-caveman

elastic-caveman 验证了一个简单假设：去除 AI 响应中的 “对话噪音”，只保留信号，并测量其影响。方法如下：

  • 普通模式：完整的对话式 AI 输出，包含问候、解释和结束语。
  • 原始（ caveman ）模式：只返回原始数据，仅保留最小结构标签。

我们使用 MCP，在一个真实的 Elasticsearch 实例上进行了测试，数据来自实际的 support ticket 和 Salesforce case，在 8 个生产场景中对两种模式进行对比。

结果：64% token 减少，准确性为零损失

以下是我们在 8 个真实 MCP 工具调用中观察到的结果：Elastic-Caveman 项目成功在不影响质量或功能的前提下优化了 AI 响应大小。

MetricResult
Scenarios tested8
Success rate88%
Token reduction63.6% average
Total normal tokens1,284
Total Caveman tokens467
Tokens saved817
Max reduction (single scenario)91.5%

关键保留项（0% 损失）：

  • 技术准确性
  • API 路径
  • ES|QL 语法
  • 字段名称

关键发现：每一个字段名、case ID、ES|QL 查询、账户名称以及情感分数都被完全保留——不是近似保留，而是完全一致地保留。

真实示例：前后对比

示例 1：列出索引：减少 87%

用户：_Show me my indices/_显示我的索引

普通模式（107 tokens）：

`Of course! I'd be happy to help you see your indices. Here's a comprehensive list of all the indices in your Elasticsearch cluster. Each entry shows the index name along with relevant metadata. This should give you a good overview of what's stored in your cluster:-- salesforce-cases-- support-ticketsThese are all the indices I found. If you'd like to dive deeper into any specific index, just let me know and I'll be glad to assist!`AI写代码

Caveman mode (14 tokens):

`Indices: salesforce-cases, support-tickets`AI写代码

Saved: 93 tokens (86.9%)

示例 2：生成 ES|QL 查询：减少 75%

User: Show me open critical tickets grouped by product area

Normal mode (208 tokens):

`Sure thing! I'd be happy to help you write that ES|QL query. What you're looking for is a query that will filter for open tickets with critical priority and group them by product area. Here's how you can accomplish this...`AI写代码

【普通模式输出】（150+ tokens）

Caveman mode (52 tokens):

`

1.  FROM support-tickets
2.  WHERE status = "Open" AND priority = "Critical"
3.  | STATS count = COUNT(*) BY product_area
4.  | SORT count DESC
5.  | LIMIT 100

7.  Filters open+critical, groups by product_area, counts, sorts desc.

`AI写代码

Saved: 156 tokens (75.0%). ES|QL syntax is character-for-character identical in both modes.

示例 3：搜索最近的支持工单：减少 35%

User: Show me 5 recent support tickets

Caveman mode (143 tokens):

`

1.  5 recent tickets, newest first:
2.  Case     | Priority | Status    | Account               | Subject                                    | Days | Sentiment
3.  CASE-0012 | Critical | Open      | Pinnacle Financial    | Regulatory reporting: incorrect tax calcs  | 2    | -0.94
4.  CASE-0021 | Critical | Escalated | Riverstone Capital    | Security audit blocking renewal            | 2    | -0.93
5.  CASE-0046 | Medium   | Open      | Blackrock Partners    | Pen test findings need vendor response     | 2    | -0.70
6.  CASE-0006 | High     | Open      | United Oil & Gas      | Unauthorized access -- urgent               | 3    | -0.91
7.  CASE-0017 | High     | Open      | Riverstone Capital    | Renewal paperwork stalled                  | 4    | -0.86

9.  All negative sentiment. Two critical cases from April 7. All case IDs, priorities, account names, and sentiment scores preserved verbatim.

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

删除什么 vs 保留什么

当我们清理输出时，会移除对话性填充内容，例如：“当然！我很乐意帮你……”、“这应该能让你更好地理解……”、“你需要我帮你优先排序这些吗？”之类的表达。

同时保留所有事实性内容，例如 ES|QL 片段，如 FROM support-tickets WHERE status = "Open"；字段名如 sentiment_score、product_area 和 resolution_hours；以及索引名称，如 support-tickets 和 salesforce-cases。

我们还保留具体标识符和业务实体，例如 case ID（ CASE-0012、CASE-0002 ）、账户名称（ Pinnacle Financial、United Oil & Gas Corp ），以及所有数值信息，例如 sentiment_score -0.94、重复计数 47、持续时间 18 days，或指标如 27.0 average hours。

这样处理后的文本会高度聚焦在查询语法、实体和数值上，只移除礼貌性的 “外壳” 内容。

结果按操作类型有所不同：

查询类型Token 减少原因
元数据列表85–92%载荷较小，普通模式中的冗余内容最多
ESQL 生成70–75%
数据密集型搜索35–40%实际数据占比高，可删除的“冗余内容”较少

完整评估拆解

在针对真实 MCP 数据的 8 个场景中，不同查询类型的 token 节省情况如下：

场景普通 tokensCaveman tokens减少比例T节省 tokensMCP 工具
T1: List all streams1181091.5%108platform.streams.list_streams
T2: List indices1071486.9%93platform.core.list_indices
T3: Get index mapping1434072.0%103platform.core.get_index_mapping
T4: Generate ES|QL query2085275.0%156platform.core.generate_esql
T5: Execute ES|QL aggregation1494470.5%105platform.core.execute_esql
T6: Search recent tickets22114335.3%78platform.core.search
T7: Search escalated cases19812835.4%70platform.core.search
T8: ES|QL stats by priority1403674.3%104platform.core.execute_esql
TOTALS1,28446763.6%817

技术准确性验证：

准确性检查结果详情

ES|QL 语法保留

PASSFROM, WHERE, STATS, SORT, LIMIT 完全一致
字段名称保留PASSaccount_id, sentiment_score, product_area 完全一致
索引名称保留PASSsupport-tickets, salesforce-cases 未改变
Case ID 保留PASSCASE-0012, CASE-0002 完全一致
账户名称保留PASSPinnacle Financial, United Oil Gas Corp 完全一致
数值保留PASS情感分数 -0.94、-0.88；天数 18、7 完全一致
优先级/状态标签PASSCritical、Escalated、Open 完全一致
空值保留PASS低优先级 resolution hours 的 null 保留
错误信息保留PASS工具校验错误按原文完整保留

这对 Elastic 用户的意义

对于在 Elasticsearch 上构建 AI 助手的团队来说，64% 的 token 减少意味着在规模化场景下 64% 的输出成本节省、更快的流式响应，以及更多上下文窗口空间可以留给真实数据，而不是冗余填充内容。当你在凌晨 2 点调试 ES|QL 查询时，你不需要一个 AI 告诉你“很乐意帮你”；你只需要查询结果本身。

更大的图景：重新思考 AI 接口

这个实验揭示了一个本质问题：对话式 AI 接口优化的指标可能是错位的。它们优化的是“听起来像人”，但用户往往只想要准确、快速的数据。

对于技术工作流，尤其是数据查询，有一个很强的理由去做模式切换：

  • 对话模式：用于探索或学习
  • 原始模式（caveman mode）：用于明确知道自己要什么并且需要快速结果时

Elastic MCP server 使这一点成为可能：它返回结构化、准确的响应，在两种模式下都无需修改即可使用。

elastic-caveman 如何工作

elastic-caveman 是一个 Agent Skill，本质上是一个带 YAML front matter 的 markdown 文件，任何兼容的 AI agent 都可以读取并遵循它。没有运行时、没有二进制文件、没有 API 调用。只有改变 agent 与 Elasticsearch 交互方式的指令。

安装方式如下：

`npx skills add srikolag/elastic-caveman`AI写代码

支持的 agents：Claude Code、Cursor、Codex、Windsurf、GitHub Copilot、Gemini CLI、Roo

触发方式：/elastic-caveman

禁用方式："normal mode" 或 "verbose"

实际运行效果

我们使用 Claude 模型测试 elastic-caveman，以衡量其对 token 使用量和成本的影响：

  • 使用 elastic-caveman：输入 368 tokens，输出 1.6k tokens，总成本 $0.11。
  • 未使用 elastic-caveman：输入 367 tokens，输出 1.8k tokens，总成本 $0.12。
`Prompt: Get me the critical support tickets from the support-tickets index in kibana for Pinnacle Financial` AI写代码

该测试展示了 elastic-caveman 的效率提升。

www.bilibili.com/video/BV1JD…

接下来是什么

caveman mode 只是一个开始。可以考虑动态模式切换：在一次会话中随时在精简模式和对话模式之间切换。或者采用混合方式：成功时保持简洁，在错误发生时切换为解释型输出。也可以为团队定义自定义 verbosity 等级，在两者之间找到平衡点。目标不是让 AI 助手变得机械，而是让用户能够控制信噪比。

自己试试

在你的 Elasticsearch 数据上测试 caveman mode：

  1. 启动 Elastic MCP server
  2. 安装 elastic-caveman
  3. 在 normal mode 和 caveman mode 下分别运行查询
  4. 对比 token 数量与准确性
  5. 完整评估方法与脚本可在 GitHub 仓库中获取

核心结论

在 8 个真实 Elasticsearch 场景中，elastic-caveman 实现了平均 64% 的 token 减少，同时零准确性损失，并且 100% 保留 ES|QL 语法、字段名称和技术数值。

有时候最好的 AI 回复并不是最 “啰嗦” 的那个。有时候你只需要数据本身；而使用 elastic-caveman，你可以让它快 64%。

准备优化你的 Elasticsearch AI 工作流了吗？可以查看 Elasticsearch Labs 获取更多教程、集成与 AI + Elasticsearch 研究内容，或者直接开始使用 Elasticsearch 构建应用。

想优化你的 Elasticsearch AI 工作流？查看 Elasticsearch Labs 获取更多教程、集成与研究内容。准备亲自试试？现在就开始用 Elasticsearch 构建吧。

原文：www.elastic.co/search-labs…

avatar
文章
阅读
粉丝