一个 MCP + RAG 的小组合
做了个小工具:把内部文档向量化存好,然后用一个 MCP server 暴露"检索文档"这个工具给 Agent。Agent 回答问题时会自动调这个工具查文档,效果比纯 RAG 好。 原因是 Agent 能判断"要不要查""查什么""查到的够不够",而不是无脑检索拼接。相当于 RAG
这里聚合 CodeNodeX AI 社区中与 RAG 相关的技术文章和讨论,覆盖概念解释、工具对比、工程实践、常见问题和独立开发经验。
如果你正在研究 RAG,建议先阅读高质量长文,再参与帖子讨论,形成从理解到实践的完整路径。
做了个小工具:把内部文档向量化存好,然后用一个 MCP server 暴露"检索文档"这个工具给 Agent。Agent 回答问题时会自动调这个工具查文档,效果比纯 RAG 好。 原因是 Agent 能判断"要不要查""查什么""查到的够不够",而不是无脑检索拼接。相当于 RAG
每次看到"上下文又翻倍"的新闻,都有人喊"RAG 要死了"。但我学了一阵子 RAG 之后觉得,这说法太夸张。 长上下文确实能塞下更多原文,但贵、慢、而且模型对超长上下文的"中间遗忘"问题还在。RAG 的优势是精准召回 + 成本可控 + 可追溯来源,这些是长上下文替代不了的。 我的
搭了个 RAG,文档塞了几百篇,但检索效果很差,top 5 里经常只有一两条相关,甚至完全不沾边。embedding 用的也是主流模型,不知道哪出了问题。 怀疑过几个点:chunk 切太大(一段塞了多个主题)、问题太短召回不上、或者文档本身噪音多。 排查了一周没头绪。大家有没有
给公司搭内部知识库,选了个专用向量库,用下来踩坑不少。 一是维度选择一开始瞎选,后来才知道要和 embedding 模型对齐;二是索引构建巨慢,几万条数据等了好久;三是"召回快但召回不准",调了好几天 HNSW 的参数。 最坑的是换 embedding 模型后所有向量得重新生成,
每次有人问"我要让模型懂我们的业务,微调还是 RAG",评论区就吵起来。我说说我的判断。 绝大多数业务场景,RAG 优先:成本低、可更新、可追溯、不动模型。微调适合"风格/格式/领域术语深度内化"的场景,比如让模型说你们公司的黑话、固定输出格式。 最常见误区是拿微调去解决"知识更
上下文动辄上百万 token 后,"把所有文档塞进去不就行了"成了流行观点。我实测过,结论是:能,但很贵,而且不总是好。 塞一百万 token 的成本和延迟,比 RAG 召回几十条 chunk 高一个数量级。更别提模型对长上下文中间部分的注意力会下降(lost in the mi
给公司内部搭了个问答机器人,把规章制度、技术文档、历史工单全喂进去,本以为效果会很一般,结果同事反馈意外地好。 复盘下来几个关键:文档预处理做得细(去噪、分章节、加标题);chunk 切得合理(按语义而非固定长度);加了个"重排"步骤把最相关的顶上去;最后用强模型做答案生成。 没
RAG 里 chunking 看着不起眼,实际决定召回质量。分享我用得最顺的策略。 核心思路是"按结构切,不按字数切"。对 Markdown 按标题层级切,每块带上父标题作为上下文;对代码按函数/类切;对长文按段落+滑动窗口。 加父标题前缀之后,召回时模型能知道这块在讲啥。细节决
我的 RAG 召回率一直上不去,调了几招之后有所改善,分享下。 一是 query 改写:用户原话往往召回不准,先用模型把问题改写成更"检索友好"的表述;二是混合检索:向量 + 关键词(BM25)一起上,取长补短;三是重排:召回 top 50 后用专门的 reranker 模型重排
给站内搜索加了语义检索,记录下流程备忘,也给大家参考。 老搜索是纯关键词,搜"怎么部署"匹配不到标题写"上线流程"的文章。加 embedding 之后,把每篇文章向量化存进 pgvector,搜索时把 query 也向量化,按余弦相似度排序。 pgvector + 一行 SQL
RAG 加重排(rerank)效果立竿见影,但用专门的重排模型成本不低。分享个轻量做法。 先用向量检索粗召回 top 50,再用一个便宜的小模型(或者直接用交叉编码器)对这 50 条和原 query 打分,按分数重排取 top 5。重排只算 50 次,成本可控。 大家 RAG 都
GraphRAG 火了一阵子,我研究了下,说说我的理解。 普通 RAG 是"找相关片段拼答案",适合具体问题。GraphRAG 把文档抽成知识图谱,能回答跨文档、需要全局总结的问题,比如"这本书的主要论点是什么"——这种问题普通 RAG 召回不出来。 代价是构建图谱很贵很复杂。所