关于 AsterMind MCP
AsterMind MCP 是面向 RAG 流程的本地重排服务,帮助减少发送给大模型的文本段落。它提供评分、筛选和令牌计数工具,数据不会通过网络发送。
主要功能
- 01重排并筛选检索段落
- 02按令牌预算裁剪上下文
- 03统计令牌并估算节省量
- 04搜索、分类和比较文本
- 05返回置信度信号
适用场景
- 01减少 RAG 流程发送的上下文
- 02为单跳问题筛选段落
- 03调整多跳查询的段落保留量
MCP 相关
向 MCP 客户端提供本地重排、上下文筛选、令牌、搜索和文本分析工具。处理在本机通过 AsterMind Community Edition ELM 引擎运行。
配置
本地服务的配置在各客户端中通用,复制后粘贴到客户端的 MCP 配置文件即可。
工具
10收录的工具列表 · 更新于 2 周前
| 参数 | 类型 | 必填 | 说明 |
|---|---|---|---|
| topK | integer | 否 | 仅返回前 K 个(默认:全部)。 |
| query | string | 是 | 用户查询或问题。 |
| documents | array | 是 | 要排序的候选文档/文本块。 |
详细介绍
AsterMind MCP
在本地、调用发出之前,减少发送给大模型的 token。
AsterMind MCP 是一个 Model Context Protocol 服务,可在本地对检索到的上下文进行排序和筛选,让你只向模型发送真正能回答问题的少数段落,而不是检索器返回的全部内容。它基于 AsterMind Community Edition ELM 引擎运行。 不进行网络调用,不需要 API 密钥,数据不会离开本机。
实际效果(实测,而非承诺)
在包含 6 个场景的 RAG 基准测试中(支持知识库、API 文档、人力资源政策、电商常见问题、DevOps 运维手册、金融科技帮助),将检索到的 10 个候选项筛选为按重排分数排列的前 3 个:
| 指标 | 结果 |
|---|---|
| 平均上下文 token 节省量 | 66.9%(按 token 计算总体节省 66.8%) |
| 答案命中率 | 100%(每个场景中,能回答查询的段落都通过了筛选) |
| Token 总数 | 926 → 307 |
| 严格的“保留所有相关段落”召回率 | 55.6% |
| 精确率 | 50% |
Token 数量使用 gpt-tokenizer 计算
(o200k/cl100k BPE,与 OpenAI 兼容)。你可以自行复现:npm run benchmark。
完整的方法说明和各场景结果见 BENCHMARK.md。
坦诚说明取舍
节省量和召回率此消彼长——保留的区块越少,节省的 token 越多,但丢失相关段落的风险也越高。你可以选择合适的取舍:
| 保留前 K 个(共 10 个) | Token 节省量 | 答案命中率 | 全部相关内容召回率 |
|---|---|---|---|
| 1 | ~87.9% | 100% | 38.9% |
| 3(默认) | 66.8% | 100% | ~55–75% |
| 6 | ~46% | 100% | 75% |
在我们测试的所有 K 值下,排名第一的段落都在 100% 的场景中包含相关内容。 这是有力且站得住脚的结果。对于单跳问题(常见问题、支持问题、单一事实查询),保留前 1–3 个,可减少约 67–88% 的上下文。对于需要多个段落的多跳问题,保留前 5–6 个——不要过滤过度,否则会丢掉必要段落。
安装
npx @astermind/astermind-mcp
或者将其添加到 MCP 客户端配置中(Claude Desktop、Cursor、VS Code、Cline):
{
"mcpServers": {
"astermind": {
"command": "npx",
"args": ["-y", "@astermind/astermind-mcp"]
}
}
}
支持 Node 18+。无需 GPU、构建步骤或配置。
工具(10 个)
| 工具 | 功能 | 优势 |
|---|---|---|
rerank_documents | 根据查询为候选项打分并排序 | 强 — 核心价值 |
filter_context | 保留前 K 个段落,或保留高于阈值的段落 | 强 |
compress_context | 对上下文块重新排序并裁剪至 token 预算 | 强 |
count_tokens | 精确计算任意文本的 BPE token 数量 | 精确 |
estimate_savings | 计算筛选前后的 token 数量差 | 精确 |
semantic_search | 根据查询对语料库进行排序 | 良好(词汇层面) |
detect_language | 识别文本语言 | 良好,带置信度标记 |
classify_text | 将文本归入指定类别 | 弱 — 会标记低置信度结果 |
generate_embeddings | 为文本生成字符级向量 | 仅适用于近似重复内容 |
compare_texts | 计算两段文本的相似度 | 仅适用于近似重复内容 |
每个工具都会返回置信度信号。当引擎能力较弱时,工具会明确说明,而不会默默猜测。
已知局限(有意说明)
- 重排器基于词汇匹配(TF-IDF)。 它会匹配共同出现的词,因此可能无法识别纯粹的同义词差异——搜索“付款方式”时,只提到“Visa/Mastercard”的段落排名不会很靠前。查询与答案使用相同词汇时,它表现出色,而这也是常见的 RAG 场景。
- 分类功能开箱即用时较弱,训练后也只是尚可——请将其作为低置信度提示,而非决策依据。它会标记低置信度结果。
- 嵌入基于字符级别,适用于检测近似重复内容,而非深层语义相似度。
以上节省的 token 只有在保留相关段落时才是真实的。删除答案来减少 token 并不算节省,而这项基准测试会同时衡量两者。
何时能为你省钱
该服务不会缩减大模型的词汇表,也不会神奇地压缩提示词。它只通过一种特定方式节省 token:先广泛检索,然后只向模型发送相关段落。 如果你的 RAG 流水线目前会在每个提示词中塞入 8–12 个检索片段,那么在本地重排后只发送 3 个片段,就能直接、稳定地减少每次调用的输入 token,而且可以在你的设备上免费运行。
开发与验证
npm install
npm test # engine + MCP client round-trip tests
npm run benchmark # regenerates benchmark/results.json
npm run benchmark:sweep # top-K policy sweep
许可证
MIT © AsterMind AI。基于 @astermind/astermind-community 构建。
评论
一个开放协议,规定了 AI 应用如何以统一方式连接外部工具与数据源。客户端负责与模型对话,MCP 服务负责提供工具、资源和提示模板,两者通过标准消息通信,同一个服务可以被不同客户端复用。