下周去上海出差，你想订一家每晚 650 元的酒店，于是问 AI："这个价格，公司能报销吗？"
AI 可能知道出差报销通常要提供哪些凭证。但要回答你这笔住宿费能不能报销，它需要看到你公司的差旅制度，确认上海的住宿标准，以及是否有额外审批要求。
这些信息不会因为模型会写文章、会编程，就自动出现在它面前。公司内部的规定，尤其是刚刚修改的规定，需要通过某种方式提供给它。
RAG 就可以用在这里。
RAG 的全称是 Retrieval-Augmented Generation，中文叫"检索增强生成"：系统收到问题后，先从外部资料中寻找相关内容，再把这些内容和问题一起交给大模型，用来生成回答。
你可以把它理解成一次带着资料答题的过程。不过，资料可能散在很多文件中，系统还得先把适用的部分找出来。
先看一次完整的问答
假设公司的《差旅报销制度》有下面三条规定。
第 1 条：上海住宿费标准为每人每晚不超过 600 元。
第 2 条：超出标准的住宿费用，须在预订前获得部门负责人批准；获批后可按批准金额报销。
第 3 条：报销时须提供住宿发票及相应支付凭证。
用户的问题是："下周去上海出差，酒店每晚 650 元，能报销吗？"
系统会先检索制度。它需要找到上海的金额标准，还要找到超标审批和凭证要求。只拿到"600 元"这个数字，依据还不完整。
随后，系统把问题、查到的原文和回答要求放在一起，交给模型。把这份输入简化展开，大致是这样：
用户问题
下周去上海出差，酒店每晚 650 元，能报销吗？
检索资料
《差旅报销制度》第 1 条：上海住宿费标准为每人每晚不超过 600 元。
第 2 条：超出标准的住宿费用，须在预订前获得部门负责人批准；获批后可按批准金额报销。
第 3 条：报销时须提供住宿发票及相应支付凭证。
回答要求
根据以上资料回答，保留适用条件并标明出处。影响判断的信息不足时，向用户补问，不自行假定。
一份符合这些要求的回答可以是：
每晚 650 元超过了上海每人每晚 600 元的住宿标准。如果你在预订前获得部门负责人批准，且批准金额覆盖这笔住宿费，可以按批准金额报销；报销时仍需提交住宿发票和支付凭证。
依据：《差旅报销制度》第 1---3 条。
你是否已经获得预订前审批，批准金额是多少？
在这个过程中，检索系统负责寻找资料，大模型负责根据资料组织回答。制度能告诉模型规则，但不能证明你已经获批；这部分信息需要你补充，或者由系统另行查询审批记录。
这里也没有重新训练模型。相关条款进入了这次回答的输入，上传制度并不意味着模型已经永久记住它。
读到这里，你可能会问：就三条规定，直接复制给 AI 不就可以了吗？
确实可以。如果资料只有这么一点，临时问几个问题，直接提供全文通常就够了。需要对一份材料做整体总结时，也可以考虑让模型阅读完整内容，前提是资料能放进它可处理的输入范围。
我们把制度简化，是为了看清过程。当差旅、人事、采购等资料分散在多个文件里，不同的人反复提出不同问题时，每次由人挑选、复制适用条款就比较麻烦。RAG 中的检索环节，可以承担这部分找资料的工作。
代价也随之出现：需要把资料整理成可以查找的形式，持续维护版本，还得处理漏检。资料多，并不自动说明 RAG 就适合；要看按问题选取资料，是否能满足实际任务。
提问之前，怎么把文件变成可检索资料？
要让系统在提问时找到相关条款，需要提前把文件中的内容提取出来，整理成便于查找的资料。我们从这份差旅制度文件开始，看看它是怎样被处理的。
提取文档里的文字和表格。
制度文件可能是 Word、网页，也可能是 PDF。系统需要解析文件，提取标题、段落、表格；扫描图片里的文字还可能需要 OCR，也就是文字识别。
如果住宿标准放在表格里，提取结果得保留城市与金额的对应关系。把"上海"留在一行、把"600 元"放到另一座城市下面，后面的检索和回答都会受到影响。
接着，把长文档分成多个片段。
这些片段叫 Chunk，常译为"切片"。制度可能有几十页，用户问住宿费时，通常不需要把交通、餐饮和办公用品的全部规定一起取出来。
但切片也不能只按字数随意截断。如果一个片段只留下"每晚不超过 600 元"，另一个片段才有超标审批条件，检索时又只找到前者，答案就可能变成"650 元不能报销"。
可以将相互关联的条款保留在同一片段中，或让系统在取用某条规定时补回必要的相邻内容。片段需要足够集中，也需要让人读得懂它的适用条件。
然后，为这些片段建立索引。
索引是为了方便查找而组织起来的数据。关键词索引记录哪些词出现在哪些片段中；另一种常见方式是向量索引。
建立向量索引时，会用到 Embedding 模型。它把一段文字转换成一组数字，也就是向量。通过比较向量，系统可以寻找语义上可能相关的内容。
例如，"酒店费用"和"住宿费"用词不同，但都在讨论住宿开支，向量检索有机会把它们联系起来。它并不因此就能保证找到正确条款，更不能直接决定 650 元是否符合规定。
原文仍然需要保存。向量用来帮助查找，取回的原文才是模型回答时阅读的资料。
每个片段还应带着来源信息：来自哪份文件、哪个章节、哪个版本，以及哪些人有权访问。这些描述信息叫元数据。没有它们，系统即使找到一段文字，也可能无法判断是否过期，或带用户回到原文核对。
资料没有变化时，通常不必每次提问都重新解析整份制度、重算全部文档向量。制度更新后，则需要同步更新对应的检索数据，并处理失效版本。
提问之后，系统怎样找到适用条款？
现在，资料已经准备好，用户再次问："下周去上海出差，酒店每晚 650 元，能报销吗？"
这次问答可以沿着下面的过程展开：
用户问题 → 明确检索范围 → 检索召回 → 候选融合与可选重排 → 组装上下文 → 生成回答。
明确问题和检索范围。
系统需要围绕上海、住宿费用、超标处理等信息寻找依据。如果用户只说"出差酒店能报多少"，却没有提供城市，而制度又按城市区分标准，系统就可能需要先补问。
检索前，需要明确用户有权访问哪些资料，并让后续各路检索都遵守这个范围。文档的版本、生效日期、适用对象等元数据，也可以帮助系统限定候选范围。
但过滤条件不能过窄。查询上海住宿标准时，还要保留适用于所有城市的超标审批规定，否则可能找到金额，却漏掉例外条件。
怎样找资料？
查找资料可以使用关键词检索，也可以使用向量检索。
关键词检索会根据"上海""住宿"等词寻找匹配内容，并进行相关性排序。BM25 是常用的评分算法之一。城市名、制度编号、产品型号、错误码等明确的信息，都可以用于关键词匹配。
向量检索则会把用户的问题转换成查询向量，与文档片段的向量比较。问题和文档片段需要用相互兼容的方式转换成向量，才能放在一起比较。即使用户说"酒店"、制度写"住宿费"，向量检索也有机会找到语义相关的片段。
前面准备的文档向量，就在这一步与用户问题联系起来。关键词检索不必经过向量化，两种方式都可以返回一批可能相关的片段。取回这些候选的过程，也常叫"召回"。
找到了候选，各自取多少？
Top-K 控制选取排名靠前的多少个结果，本身不是评分算法。例如，关键词检索取前 10 个，向量检索也取前 10 个。这里的 10 只是示例，两路的数量可以不同；候选不足或经过过滤后，实际返回的数量也可能更少。
排名靠前，只说明这些内容在当前资料中比较接近问题，不代表足以回答。假设你问"出差洗衣费能不能报销"，资料中却只有住宿规定，检索仍可能返回一些与出差相关的片段。
在向量检索中，可以设置相似度阈值，过滤掉分数未达到要求的候选。阈值过高可能漏掉有用资料，过低则可能留下无关内容，需要用实际问题调整。相似度分数也不能直接当作答案正确的概率。
即使片段通过了阈值筛选，仍需检查它是否包含回答所需的依据。例如，其他城市的住宿规定也可能与问题很相似，语义接近不能替代适用条件的判断。
两路结果怎样融合？
结合关键词检索和向量检索的结果，是一种常见的混合检索方式。比如，一路找到了上海住宿标准和凭证要求，另一路也找到了上海住宿标准，还找到了超标审批规定。融合就是把两份候选整理到一起，合并重复片段，再综合排序。
两路的评分含义不同，不能直接比较原始分数来确定谁更相关。RRF（Reciprocal Rank Fusion，倒数排名融合）是一种常见的融合方法：它参考每个片段在不同结果列表中的排名，进行综合排序。同一片段被两路找到时，会合并它们的排名贡献，不在结果中重复列出。
这里产生的是融合分数，与前面的向量相似度分数含义不同。因此，向量检索设置的相似度阈值，不能直接套用到 RRF 或 BM25 的分数上。
融合以后，还可以进一步重排。
前面的 RRF 融合主要参考两路结果中的排名。要进一步比较候选正文是否贴合问题，还可以增加重排（Rerank），把更相关的内容排在前面。
重排是可选步骤，并非每套 RAG 都必须配置。
选好资料，再组装上下文。
组装输入时，需要保留必要的前提和例外，必要时补回关联条款。模型一次能处理的输入有长度限制，给它塞入大量无关片段也会增加干扰，因此两路各自取出的候选数量，不等于最终交给模型的片段数量。
本次实际提供给模型的信息，就是它的上下文。回到报销案例，其中需要包含上海住宿标准、超标审批和凭证要求，再加上用户问题与回答要求。
模型读到这些文字后，才能据此比较 650 元与 600 元，组织回答，标注来源。我们在前面看到的完整问答，就是这样衔接起来的。
得到回答后，还可以打开引用的条款核对：它是否适用于这次出差，是否保留了提前审批和凭证要求。有引用方便我们检查依据，但并不保证回答已经准确理解了原文。
你的工作适不适合用 RAG？
可以先看你希望 AI 回答的问题，究竟依赖什么。
如果你经常需要从公司制度、产品手册、交付说明或研究笔记中寻找答案，而且希望回答能指出依据，可以考虑使用带知识库检索能力的工具。尤其是资料会反复使用，不同问题又只涉及其中一部分时，检索能减少逐次翻找和复制资料的工作。
但"住宿费的报销标准是多少"和"我的报销到账了吗"，需要的资料不同。前者可以查制度，后者需要查询业务系统中的实际状态。"替我提交报销"还涉及填写信息、上传凭证和提交审批，需要相应工具与授权，仅靠检索制度不能完成。
如果你的需求确实是围绕资料提问，可以按使用方式来选择。
临时读几份文件，直接提供资料。
偶尔读一份报告、查几条制度，可以直接把内容提供给支持文件阅读的 AI 工具，说明要解决什么问题，并要求标出依据。这种方式不一定需要建立长期知识库。文件较多、每次都要重新挑选和上传时，再考虑其他方式。
长期围绕一批资料提问，使用现成的知识库产品。
例如，ima 提供个人知识库和文档问答能力。持续研究一个主题时，可以将相关材料放进知识库，之后围绕这批资料提问，减少反复准备材料的工作。ima 产品说明
这类方式主要需要你选好资料、处理旧版本、核对回答。使用现成的知识库问答产品，也可能已经在使用 RAG，不需要先自己开发一套系统。
团队资料已经在协作平台中，先看现有平台的知识问答能力。
如果公司的制度和手册已经放在飞书等协作平台中，可以先了解平台能检索哪些资料、是否遵守原有访问权限，以及答案能否回到来源。飞书知识问答说明
这里要结合团队实际开通的功能和资料范围判断，不必为了做知识库，把已经维护好的文档全部搬到另一套系统。
需要定制问答流程，再考虑搭建平台或自行开发。
如果需要将知识库接进客服入口，或调整资料处理、检索和回答流程，可以考虑 Dify 这类应用搭建平台。它支持创建知识库、配置切片与检索，并把知识检索接入问答流程。前面提到的 Chunk、Top-K、重排等概念，会在这类配置中出现。Dify 知识库入门教程
采用搭建平台仍需要有人负责配置和维护。如果现成能力无法满足数据接入、权限或部署要求，再评估自行开发，承担相应的工程工作。
这些方式不需要逐级体验。选哪一种，取决于资料在哪里、是否反复使用、谁来使用，以及需要定制到什么程度。
无论选择哪种方式，资料都需要有人维护。
回到那笔 650 元的住宿费，系统能否找到有效的标准、保留审批条件，并让你核对原文，比知识库里存了多少份文件更能说明它是否有用。
我是宅小年，下期我们再见！
关注公众号「宅小年」，阅读更多分享文章