在开始写之前我想先说明一下我读到的这个标题："走进 AI Agent 第四篇：知识获取管道——RAG 基础"。这是当前 AI 圈子里最热的实操方向之一。如果说 Agent 是一台智能机器，那 RAG 就是它的供水系统。没有水，机器再聪明也转不起来；有了管道，大模型才能真正接触到私域知识、实时数据，回答出有依据的内容。这篇就围绕"知识获取管道"这条主线，把 RAG 的全流程拆开讲透，适合正在从零搭建 Agent、想搞清楚 RAG 到底在解决什么问题、以及如何在 2026 年的产品环境里把知识库落地的开发者参考。
1. 知识获取管道：为什么 Agent 必须先解决"吃饱饭"的问题
1.1 Agent 的三层知识结构
先想一个最核心的问题：AI Agent 的知识从哪里来？当你让 Agent 回答"公司 2025 年第四季度的销售数据是多少"，它凭什么能给出准确的答案？这里面的知识其实分三层：
第一层是大模型自身的参数知识。也就是模型在海量语料上预训练时学会的那些通用能力——语法、逻辑、常识、数学推理。这一层知识在模型训练完成的那一刻就"冻结"了，它不会主动更新，也不会知道你的公司内部发生了什么。很多企业上来就让大模型回复业务问题，发现它一本正经地胡说八道，毛病就出在这——你拿着一个只能靠"记忆"回答问题的引擎，去处理它根本没记忆过的事情。
第二层是上下文窗口内的临时知识。也就是你在 Prompt 里塞给它的那些参考资料。这一层非常灵活，你能把最新报告、数据库查询结果直接喂进去，让模型基于这些内容作答。但缺点也很明显：上下文窗口是有限的，你不可能每次都把几十万字的文档全塞进去，而且塞得越多，模型"顾此失彼"的概率就越高，注意力被稀释，回答质量反而下降。
第三层才是 RAG 真正干的事——外部知识库。把文档切碎、向量化、存起来，等用户提问的时候，系统实时从库里召回最相关的内容，拼装成上下文，再交给大模型生成答案。这层的核心价值是"既无限又新鲜"：知识库可以无限扩充，知识可以随时更新，而且每次回答都带着证据链回来，模型不用猜，照着材料说就行。
RAG 等于把"模型的知识边界"和"系统的知识供给"解耦了。模型还是那个模型，但你可以给它装上源源不断的活水。
1.2 知识获取管道在 Agent 里的定位
把 Agent 拆开看，它的工作流通常是这样的：用户输入 → Agent 规划任务 → 调用工具/检索知识 → 整合信息 → 生成回复 → 执行动作。在这个链路里，知识获取管道承担的是"信息输入"的职责。没有它，Agent 就是一个只有"大脑"没有"眼睛和耳朵"的空壳；有了它，Agent 才能感知到具体的、鲜活的、私域的信息环境。
我常给团队打的一个比方是：大模型是一个刚毕业的高材生，聪明但没经验。你直接问他"咱们公司的报销流程是什么"，他只能瞎编；但你递给他一本员工手册，让他查完再回答，他就能给你一个八九不离十的准确答案。RAG 就是那本员工手册，而且是会自动更新、自动检索、自动标注页码的手册。
从实际工程角度看，RAG 在 Agent 里还有一层规划层面的意义。一个复杂的 Agent 任务往往需要多轮工具调用，而每轮调用之后拿到的结果，本质上都是"知识获取"的一部分。你查数据库、调 API、读文件，全部可以理解为知识管道的延伸。所以 RAG 不是 Agent 的一个可选配件，而是整个 Agent 系统的地基工程。
1.3 国内 2026 年 RAG 落地环境：为什么要现在动手
看热搜词里那一串——rag知识库、rag实战、搭建本地rag、基于 langchain 的 rag流程、agentic rag——就知道这个领域已经从"概念验证"走到了"规模化落地"的阶段。2026 年国内做 AI Agent 的产品盘点里，几乎所有拿得出手的智能体都内置了知识库能力，区别只是做得好不好、快不快、准不准。
这个时间点动手做 RAG，最大的红利是工具链已经成熟到"不用重复造轮子"的程度。本地有 net rag 甚至 ontology rag 这种带本体建模的选择，云端有 rag as service 的托管方案，Java 生态里 spring ai rag 已经能跟 spring cloud 无缝集成，LangChain4j 让 JVM 系开发者也能轻松上车。换句话说，现在的问题不是"能不能做"，而是"怎么做得更好"。
但反过来也要提醒一句：工具成熟不等于效果达标。我做过的 RAG 项目里，真正拉开差距的往往不是选了哪个框架，而是对管道的理解深度——你知道文档切多碎吗？你知道 embedding 模型选哪个吗？你知道怎么评估召回命中率吗？这些细节才是决定知识库"好用还是废掉"的分水岭。下面我就一步步拆。
2. RAG 全流程解剖：从文档到答案的五段管道
2.1 管道总览：先看整体，再看局部
RAG 的完整流程可以压缩成一句话：知识入库 → 知识切分 → 向量化 → 检索召回 → 生成增强。这句话听起来简单，但每个环节都有大量工程细节，任何一个环节出问题，最终答案的质量都会断崖式下跌。
我习惯把 RAG 画成一条流水线：
- 入库阶段：把 PDF、Word、Markdown、HTML、数据库记录等异构数据统一采集进来，做清洗和格式归一化。这步做不好，后面全是脏数据。
- 切分阶段：把长文档按语义、标题、固定长度切成"块"，每块是一个可检索的知识单元。
- 向量化阶段：用 embedding 模型把文本块变成稠密向量，说白了就是把"一句话"变成"一串有数学意义的数字"，让计算机能计算语义相似度。
- 索引与存储阶段：把向量和原文一起存进向量数据库，建立倒排索引和向量索引，支撑快速召回。
- 检索与重排阶段：用户提问时，把问题也向量化，到库里找出 Top-K 最相似的文本块，必要时再用重排模型精排一次。
- 生成阶段：把召回结果拼进 Prompt，要求模型只基于这些材料回答，并附上来源引用。
这六个环节对应到用户感受上，就是"你问它一句，它翻了一遍整个知识库，然后把最相关的内容带上答案一起给你"。而"翻"得准不准、"带"得好不好，直接决定了这个 Agent 是"真懂"还是"装懂"。
2.2 入库与清洗：脏进脏出，干净进才干净出
很多人第一次做 RAG 时，脑子里全是向量数据库、embedding 这些"高级词汇"，结果第一步就在数据清洗上栽了跟头。我见过的典型场景是：直接从公司内网拉了一堆 PDF 扔进去，里面有扫描件、有表格、有页眉页脚、有重复段落，结果检索出来的内容乱七八糟，模型引用了一堆带"第 3 页共 20 页"的废文本。
数据清洗的核心就三件事：去噪、去重、归一化。
去噪指的是把那些对语义理解没有帮助的噪声信息干掉——导航栏文字、页眉页脚、二维码描述、乱码字符都算。扫描版 PDF 要做 OCR，这一步可以用 PaddleOCR 这类开源工具。表格类内容要考虑转成 Markdown 或者结构化数据，而不是直接当作纯文本切，否则表格语义会在切分时被切碎。
去重更关键。很多企业内部文档有多个版本，比如"报销制度_V3_最终版.pdf"和"报销制度_最终版.pdf"其实内容高度重合。如果你不去重，索引里全是重复块，检索时会反复召回同一个主题的不同说法，模型容易把旧版本和新版本混在一起回答，甚至自相矛盾。我一般用 MinHash 去做近似去重，阈值调到 0.85 左右，既能去掉重复又不误杀相似但不同的段落。
归一化则是把格式统一。日期写成"2025-01-15"还是"2025 年 1 月 15 日"其实无所谓，但要统一；单位是"元"还是"人民币"要统一；同样的专有名词大小写要统一。这一步不复杂，却直接影响后面切分和检索的一致性。
2.3 文本切分：块的大小决定检索的天花板
切分是整个管道里最容易被低估、又最影响效果的一步。它的难点在于"度"的把握：块切得太小，每块承载的信息不完整，检索召回的片段支离破碎，模型拼不出完整的答案；块切得太大，向量化后语义被稀释，相似度计算不精准，而且喂给大模型的上下文容易被无关信息灌满。
我实际项目里的经验值给大家参考：
- 通用文档：按 300~500 个 Token 切一块，重叠 50~80 个 Token。这样既能保证每块有足够的语义完整性，又能让跨块的上下文衔接不断裂。
- 技术手册/操作指南：这类文档行文结构清晰，优先按标题层级切分。先用 Markdown 解析把标题树拉出来，遇到二级标题就开新块，块内再按段落续接。这样切出来的块，天然跟用户的"我要查某个功能怎么用"这种需求对齐。
- 表格数据：单独处理，不要跟大段文字混在一起切。建议每个表格作为一个独立块，并且把表头信息重复拼接在每一行前面，方便检索时命中行级内容。
- 代码示例：按函数或代码块切分，保留注释。代码的语义边界在函数级别，注释里往往藏着"这段代码干什么"的关键信息。
切分策略没有银弹，我的做法是"多策略并行+评估调优"。先把几种切分策略都跑一遍，用小样本的数据集标出哪些问题是系统该答对的，然后对比不同切分策略下的召回命中率（hit rate），让数据说话，而不是拍脑袋。
2.4 向量化与索引：先选对着色盘，再谈画画
切分完之后，每一块文本就要变成向量了。这里的选择主要在两个层次：embedding 模型和向量数据库。
embedding 模型决定了"语义相似度"的度量基准。市面上有 openai 的 text-embedding-3 系列，也有国产的 bge-large-zh、bge-m3、m3e，还有最近很多企业用的通义 text-embedding-v3、Jina Embeddings 等。做中文知识库，我建议优先考虑中文表现更好的国产模型。bge-m3 支持 100 种语言，对中英混合场景格外友好；通义的 text-embedding-v3 在中文长文本上的效果很稳。选模型的时候别只看榜单分数，拿自己领域的真实数据测一遍才靠谱，很多通用榜单一骑绝尘的模型到了你的业务场景里反而表现平平。
向量库的选型也有讲究。milvus 适合大规模高并发场景，单机版 qdrant 上手极快，chroma 适合原型验证，es 的向量检索能力也不弱。如果公司里已经有 elasticsearch 或者 opensearch，用它顶上最省运维成本；如果从零开始，我建议先用眨眼就能跑起来的 chroma 或 falkordb 做 PoC，等量级上来了再换专用向量库。记住，不要在验证阶段就开始做架构军备竞赛。
索引方面有个小细节：一定要建"混合索引"。什么意思呢？就是除了向量索引，还要建全文索引。向量检索擅长找到"语义相近"的内容，关键词检索擅长找到"字面匹配"的内容——这两者往往互补。用户问"报销流程"时，向量检索能找到讲"费用报销制度"的段落，因为语义相近；但用户问"ABC-1023 型号参数"这种典型代码串时，向量检索反而容易失手，关键词检索却一打一个准。我现在的做法是两路并行召回，融合排序后再取 Top-K，效果比单用向量检索稳定得多。
3. 检索策略与评估：命中率是知识库的生命线
3.1 从 Top-K 到重排序：怎么让最相关的内容排最前面
检索阶段的目标很纯粹：找出跟用户提问最相关的 Top-K 个知识块。但"最相关"这个词在工程里往往很模糊。我举一个特别真实的场景：用户问"如何申请加班补贴"，知识库里有十条内容：三条讲定义和适用范围、五条讲线上申请步骤、两条讲常见问题。向量检索召回的 Top-5 可能有三条都在讲"适用范围"，因为这段文字跟"申请"这个动作的向量距离相近，但它并不是用户想看的操作路径。
这时候就需要重排序（rerank）来救场。rerank 模型跟 embedding 模型的区别在于：embedding 是"把文本映射到向量空间再比距离"，rerank 是"把问题和候选文档直接拼在一起做深度语义交互"，后者更精细但计算成本高。所以现在的主流做法是"双阶段召回"：第一阶段用向量检索+关键词检索快速把范围缩小到 Top-50，第二阶段用 rerank 模型精排成 Top-5 输出给大模型。
bge-reranker-v2-m3 是我用下来性价比最高的 rerank 模型，效果稳定，资源开销可控。如果团队里没有 GPU 推理条件，Cohere Rerank 这类 API 服务也可以用，只是要评估延迟和成本。重排序这步在知识库规模小的时候可以省，但一旦知识块数量超过一万，它就是标配——直接决定你的 Agent 是"次次都答到点上"还是"偶尔蒙对一次"。
3.2 命中率评估：先定标尺，再谈优化
做 RAG 最忌讳的就是"凭感觉"。什么叫"检索效果好不好"？如果没有量化指标，你跟同事争论一天也争不出结果。我团队里默认的评估指标是三个：
第一个是 Hit Rate（命中率）。定义是：对每个测试问题，检查真实答案所在的原文块是否出现在召回结果里。如果在，就算命中。比如你有 100 个测试问题，其中 82 个问题的答案块被召回，那 hit rate 就是 82%。这是知识库最核心的生命线指标。Hit rate 不高，生成环节再努力也白搭。
第二个是 MRR（平均倒数排名）。它衡量的是"正确答案排得有多靠前"。假设正确答案在召回列表的位置是 3，那对这个问题的分数就是 1/3。把所有问题的分数平均，得到 MRR。这个指标适合衡量重排效果——重排之后，正确答案的位置是不是往前挪了。
第三个是生成准确率（Answer Accuracy/Correctness）。让评测模型对 Agent 的最终回答打分，看它是否正确、完整、并且忠实于召回文档。这一步可以借助 gpt-4o 或 qwen-max 做自动评估，但要设计好评分 Prompt，防止模型"放水"。
有了这三把尺子，优化方向就变得特别清晰。Hit rate 低 → 回头调切分策略、换 embedding 模型、加大召回数量；Hit rate 可以但 MRR 低 → 上 rerank；前两个都好但生成准确率差 → 改 Prompt 模板、调整上下文组织方式。数据驱动，而不是感觉驱动。
3.3 常见检索坑位：为什么知识库"有答案却找不到"
项目里踩过最多人踩的坑，我给大家排个雷：
第一个坑是切分与问题粒度不匹配。用户的问题往往是"某个完整功能怎么用"，而文档被切成 300 Token 的碎片后，每块只讲了一个小步骤，模型看到的是"残缺的手册"，自然答不对。这种问题要从切分策略上解决——按文档结构切，而不是机械地按固定长度切。
第二个坑是语义相似但答案相反。比如知识库里有"支持"和"不支持"两个矛盾段落，向量距离都很近，召回都把两段带上了。模型面对互相矛盾的材料，要么胡乱调和，要么挑一边回答，结果你怎么测都测不准。解法是：入库前做冲突检测，同一主题下矛盾的段落要打标或者人工确认；检索时如果两段落相似度过高，要去重降权。
第三个坑是向量检索对"窄召回词"失效。很多专业名词、型号编码、冷门缩写，向量空间里找不到相近的邻居。我刚才说的混合索引就是从这来的——关键词检索兜住字面匹配，向量检索兜住语义扩展，双保险才能减少漏召回。
第四个坑是评测集不小心"作弊"。评测问题本身来自知识库原文改写，跟训练语料重合度过高，导致指标虚高、上线后立刻露出原形。评测集一定要留出"类似用户在真实场景里会说的话"，而不是简单地把文档里的句子抽出来当问题。
4. 从 RAG 到 Agentic RAG：知识管道的进阶玩法
4.1 传统 RAG 的局限：一问一答，但不会思考
到这一步，你已经能用基础 RAG 搭出一个"文档问答助手"了：用户提问、系统检索、模型回答，流程固定、效率稳定。但如果你把它搬进真正的 Agent 场景，很快会发现几个问题的存在。
第一个局限是"多跳问题"。用户问"去年销售额最高的产品里，哪个在华东区的退货率最低？"这需要先查出销售额排名，再针对排名靠前的产品查退货率，再对比得到结论。传统 RAG 一次检索只做一步，回答这种问题全靠大模型瞎编。你需要让 Agent 自己规划：先检索什么、拿到结果后再检索什么。
第二个局限是"不知道什么时候该查"。在开放对话里，用户可能先闲聊两句，再抛出一个需要查知识库的问题。传统 RAG 会把每个问题都拿去检索，导致闲聊话题也去库里找，检索结果毫无用处还占上下文。Agent 需要判断"现在是否需要调用知识管道"。
第三个局限是"工具与知识的割裂"。用户问"帮我预约明天下午的会议室，顺便告诉我上季度项目总结的重点"——这既要调日历 API 又要查知识库。如果 RAG 和工具调用是两套体系，Agent 就没法在一个任务里同时编排它们。
这几个局限指向同一个方向：RAG 不能只是一个"被调用的函数"，它要变成 Agent 可自主决策的一部分——这就是 agentic rag。
4.2 Agentic RAG 的三种核心能力
我一直觉得 agentic rag 不是一种具体技术，而是一组设计模式。落地时主要拆成三种能力：
第一种是"按需检索"。Agent 拥有一个决策节点，判断当前对话是否需要检索知识库。判断的依据可以是：问题是否包含事实性信息、是否涉及私域术语、用户是否明确要求查资料。这个决策可以用一个小模型来做，也可以让 Agent 通过工具选择的机制自己决定。做到位之后，闲聊不会误触发检索，上下文也不会被无意义的检索结果污染。
第二种是"多步检索编排"。Agent 可以拆解复杂问题，生成检索计划：先查什么、再查什么、中间是否要调用外部工具。实现方式可以是在 Agent 的工具列表里暴露多个检索入口（按知识域分库检索），也可以让 Agent 反复调同一个检索工具、每轮携带上一轮的推理结果再检索新内容。这一步是 Agent 化 RAG 的关键，本质上是从"一次检索定生死"变成"边推理边检索"。
第三种是"查询改写与意图扩展"。用户在对话里经常说"它"，"那个表格"，"刚才提到的问题"——代词多到检索系统想哭。Agent 的优势在于它看得到上下文，可以先把用户的话改写成独立、明确的检索查询，再送进知识库。比如用户说"我跟你说过的那个报销问题的第二步怎么操作"，Agent 回溯对话历史，改写成"差旅报销申请流程第二步：上传发票"，再下手检索，命中率会大幅提升。
4.3 技能（Skill）与 RAG 的结合思路
热搜词里有人在问"skill 怎么和 rag 结合起来"，这个问题太真实了。我的理解是：skill 是 Agent 的"行为能力"，RAG 是 Agent 的"知识来源"，两者结合的关键是让知识触发技能、让技能产出新知识。
举一个落地的例子：企业内部有一个"合同审查 Agent"。它的技能清单里有"条款一致性比对""风险条款识别""法规合规检查"。这些技能的核心逻辑是规则和 Prompt 流程，但执行每条技能时都需要查阅大量背景知识——历史合同模板、相关法条、公司风控红线。于是整个工作流就是：Agent 接收合同 → 调用 RAG 检索公司历史合同库和法规库 → 加载文档内容作为技能执行的输入 → 执行合同审查技能 → 输出风险报告。RAG 相当于给技能装上了"弹药库"，没有这个弹药库，技能就是一个空壳的流程。
反向的结合同样成立：一次完整的技能执行会产生新的结果（比如审查报告、数据结论），这些结果也可以写回知识库，供未来的检索使用。这就是 RAG 的"自我进化"——用过的知识沉淀下来，越用越聪明。
4.4 从零到一：我推荐的 RAG 落地路线图
如果你现在正要动手做一个 RAG 项目，我建议按这个路线走，能少走很多弯路：
第一个阶段，先别碰代码。拿一个成熟的 RAG 产品把整个交互流程玩明白。现在国内外的 rag 托管服务、开源项目都有在线 demo，你先给它们喂自己的文档，看它们的切分效果、检索效果、引用方式。这一步是建立"手感"——你知道好的 RAG 应该长什么样，才有资格谈自己搭。
第二个阶段，用一个轻量框架 48 小时跑通闭环。fastgpt、dify 这类工具，或者 langchain 的 quickstart 教程，都可以让流程先转起来。不要追求完美，目标是"看得到错误"。跑通之后，把代码停在本地，开始动手改细节。
第三个阶段，建立评测集。从你的真实业务文档里挑 50~100 个问题，逐个人工核对答案来源。这步不要省，它是后续所有优化的基准线。没有评测集，后面你换 embedding、调切分、加 rerank，全都无法判断好坏。
第四个阶段，逐项优化。先切分、再 embedding、再检索策略、再重排、最后调 Prompt。每改一步跑一遍评测，看 hit rate 和 MRR 的变化。经验数据是：切分策略改写后 hit rate 往往提升 5~10 个百分点，换成领域匹配的 embedding 又提升 5 个点，加起来 rerank 再贡献 5 个点左右。这个阶段的产出才是有含金量的"调通"。
第五个阶段，接入 Agent 体系。把 RAG 管道封装成一个工具接口，暴露给 Agent 调用；再加上查询改写的逻辑，让 Agent 带上下文地使用检索。到这一步，你已经从"RAG 基础"走向了"agentic rag"。
5. 避坑手记：那些文档不会告诉你的实操经验
5.1 关于 Prompt 模板：生成环节才是最终"背锅侠"
检索做得再好，如果生成 Prompt 写得敷衍，答案照样不行。我在多个项目里迭代出来一套相对稳的生成模板，核心就三点：角色设定、材料使用规则、答案格式约束。
角色设定很简单："你是企业内部知识助手，请严格根据以下材料回答用户问题。"
材料使用规则是关键："如果材料与问题无关，请直接回答'知识库中未找到相关信息'；如果材料存在冲突，请指出冲突并说明多个说法；不要编造材料外的内容。"这一条能用指令把幻觉的可能性压到最低。
答案格式约束可以让模型输出引用来源编号，比如"[1] 报销制度 V3 第 2.3 节"。这样做的好处不止是让用户信服，更重要的是方便你事后排查问题——用户说答得不对时，你直接看引用了哪些块，就能快速定位是检索错了还是生成错了。
5.2 关于成本和延迟：先算账再开工
RAG 不是免费的，主要成本在三个地方：embedding 调用、rerank 调用、生成调用的 Token 消耗。我见过不少团队技术方案做得很漂亮，一算账发现每天的成本根本扛不住。
控制成本的几个土办法：一是把知识库改成"按需 embedding"，文档入库时算一次，而不是每次检索都全库重算；二是缓存系统消息和常用知识块的向量，避免重复计算；三是在 Prompt 里严格限制召回块数量，Top-3 能解决的事不要 Top-10；四是低频访问的知识库走冷热分层，热数据放高配向量库，冷数据放便宜存储甚至磁盘索引。
延迟方面有个很实用的技巧：把检索和生成做成"流式并行"。用户提问后，先并行地跑向量检索和关键词检索，等两者都回来后汇总重排，再流式生成答案。第一 token 的延迟可以从传统的 3~5 秒压到 1~2 秒，体感提升非常明显。
5.3 关于安全与权限：知识库也有"涉密等级"
企业内部知识库最容易被忽视的就是权限隔离。很多团队的 RAG 管道是全公司共用一个向量库，结果就是普通员工一搜索，把 HR 的薪酬文档、核心项目组的保密方案全都召回了。这个问题上线前必须解决。
做法上，可以给知识块打权限标签（标签颗粒度可以细到部门、角色、项目），检索时根据当前用户的身份过滤不可见块。更进一步的方案是"多库隔离"——权限不同的知识域放到不同的索引里，Agent 根据用户上下文动态选择可检索的库。技术上都不复杂，但一定要纳入一期方案，不要等到出事故再补。
5.4 关于持续更新：知识库是活物，不是一次性工程
RAG 上线只是开始，它更像一个需要持续运营的知识产品。文档会更新、业务会变化、用户会问出知识库里没有的新问题——这些都需要有一套更新机制来兜底。
日常运营里，我建议至少做三件事：一是定期的增量索引任务，新文档入库后自动切分、向量化、去重；二是"未命中"日志分析，把系统召回不到答案的问题定期捞出来，人工判断是切分问题、检索问题还是真缺知识，分类处理；三是知识库质量回顾，每个月挑一次优先级最高的知识域做一次人工评测，防止检索效果随着文档膨胀而劣化。
这个活很累，但它才是 RAG 项目真正的护城河。工具链谁都能搭，持续把知识库喂好、调好、迭代好，才是别人抄不走的竞争力。
6. 终点也是起点：知识管道的下一站
写到这里，RAG 的整个知识获取管道就算完整拆完了——从数据清洗、文本切分、向量化、索引、检索、重排，到生成增强，再到 agentic rag 的进阶玩法，每一步都有它存在的理由，也都有它在实操中的坑位。你拿这篇文章对照自己手头的项目，应该能立刻定位到问题出在管道的哪一段。
我个人在实际操作中的体会是：基础 RAG 的门槛没有想象中高，但要真正让它成为 Agent 可信赖的知识底座，靠的是对数据细节的死磕和对评测指标的坚持。别急着上高大上的框架，先把手里的文档洗干净、切好块，把 hit rate 测明白，你离一个真正有用的知识库就不远了。
最后再分享一个小技巧：刚开始做的时候，尽量把知识库的规模控制在"小而精"——先做公司里使用频率最高的那 50 份文档，做到检索准确率 90% 以上，再去铺量。很多项目失败都不是因为技术不行，而是因为知识库越做越胖、越胖越糊，到最后什么内容都搜不准。小而精，精而准，这条路才是 RAG 落地最稳的方向。
