RAG应用指南

大多数把语言模型接到自己文档库里的团队，都会撞上同一堵墙：模型自信满满地引用六个月前的训练数据，或者干脆拒绝引用那篇其实装着答案的内部政策 PDF。检索增强生成（RAG）就是为了修这个缺陷而生：不把 LLM 当成事实来源，而是当成一台"读了你刚检索到的上下文，才开口"的推理引擎。这篇指南会带你过真实的 RAG 应用、让一个 Demo 变成生产系统的关键决策，以及每一阶段你应该预期的数字。想先把背后的 AI 基础打牢，可参考中文站的 用 AI 学 Python，从模型与工程底层出发再回到检索。

为什么检索增强赢下了生产之争

微调主导了 2023 年的讨论，随后悄悄输掉了部署这场仗。微调后的模型记住了模式，却无法吸收新事实——那需要另一趟昂贵的训练。RAG 反转了这套经济学：模型保持冻结，检索索引在变，所以更新知识库是一次索引活，而不是训练活。这也是为什么今天几乎所有认真的企业 LLM 部署都会经过一个检索层。想把回答锚定在自己的销售合同、客服工单或工程手册上？靠检索，而不是重训，才不用烧 GPU 预算。还有一个准确率天花板的问题：当模型必须纯凭记忆作答，它会幻觉出看似具体实则编造的引文；当它被迫基于检索段落作答，证据是可以核查的。你能审计它为什么这么说——这在受监管行业是不可妥协的。"模型这么说"和"这是出处片段，你自己判断"之间的差别，就是落地锚定回答的价值。

最能回本的应用：客户支持

客户支持是高 ROI 最高的 RAG 用例，因为失败模式便宜好算。客服专员大概有四成时间在翻答案，而聊天机器人解决一张工单的成本，只是人工处理的一个零头。做得好的支持型 RAG 系统，从帮助中心、产品文档和已解决的历史工单里检索，然后草拟一份带原文引用出处的、有据可答的回复。真正该看的指标是"遏制率"：从没到过人工手上的工单占比。这里的现实陷阱是切块（chunking）。多数支持文档把答案埋在 2000 字页面的第四段：按固定字数切块，你会检索到引言，而不是解决方案。切对块的团队按语义分节、把块保持在 200 到 500 token、并加重叠上下文让问题永不落在块边界上。在调 embedding 之前，先用一组成留的不见问题量 recall——切块还是坏的，调嵌入是在白费几周。

企业知识检索与合规

律所、审计团队和受监管公司用 RAG 检索他们依法必须定位和保存的文档。要求不是"找到相似文本"，而是"找到控制性条款"。这把设计从纯向量相似转向混合检索：把稠密嵌入模型和精确关键词匹配以及日期、作者、文档类型的元数据过滤结合起来。实践上，这意味着让一个向量存储配上一个关键词索引和一个过滤层，而不是把宝全押在语义距离上。合规还要求血缘（lineage）。生产系统要记录检索了哪些块、什么顺序、模型据此生成了什么。如果法院或审计师质疑一个回答，你必须能复现检索路径。这是个先于模型问题的"数据建模"问题：把块、父文档、置信分和时间戳存在一起，让审计轨迹自动生成而不是事后补。这些管流水线、保索引常新的运维纪律，就是LLM 应用开发与 MLOps 的核心，也是企业落地 AI 的必答题。想系统补齐 MLOps 认知，可再看英文站的 LLM 应用开发 指南。

代码助手接地

开发者工具已成 RAG 的主战场之一。靠训练数据回答的代码助手，会建议那些已被弃用的 API 或公司里根本不存在的内部库。检索增强的代码生成从你的仓库、内部包注册表和编码规范里取料，让建议匹配你真实的栈。团队报告说，把代码建议接地到内部代码库，能大幅砍掉"听着对、编译不过"的比例。这里的检索对象不是散文，而是函数签名和用法示例；按函数或按类切分源码，打败任意 token 切分。为包版本与弃用单独建一个索引，让生成器绝不再建议已删除的 API。如果你直接操作基础设施，一层接地还能让建议紧紧贴着你要部署的那个确切运行时。

不烧钱地评估一个 RAG 系统

多数团队靠肉眼扫几个输出评估 RAG，这正是不像样的系统能上线的原因。标准评估拆成两半。检索质量：对一个问题返回的 top-k 段落里，有多少真正含答案（recall@k、命中率）。生成质量：给定正确段落后，最终答案是否匹配期望答案（忠实度、答案相关性）。两个都要，因为系统可能检索得很好，却仍让模型溜回训练数据的习惯里。在调任何东西之前，先建一套 100 到 200 条真实问题的带标注评估集——这是任何 RAG 项目里杠杆率最高的单项投入。用它比较切块大小、嵌入模型和重排序器。如果你的 recall@5 低于 70%，再多的提示词工程也修不好答案。先修索引，再修生成提示词，最后才扩展到更大语料。这套"评估先行、数据先行"的思路，和中文站 数据分析基础 里"先有指标再优化"的训练一脉相承。

底层选型：向量数据库怎么挑

检索后端是最容易被低估的组件。向量数据库存嵌入并在毫秒级返回最近邻，但不同系统在成本、一致性和过滤支持上有不同取舍，选择会塑造你未来几年的运维负担，值得用决策树而不是随便默认。如果你向量不足百万、想要最少运维，托管服务可以去掉基础设施的烦恼；如果你已经跑着 PostgreSQL 且语料不大，pgvector 扩展省掉一个新存储；针对规模与专用性能，专用的向量引擎提供高级过滤和横向扩展，但运维足迹更重。托管还是自管，是个工程取舍，也出现在更广的平台架构讨论里。下面是几款主流选择：

如果你已经熟悉 PostgreSQL 和 Elasticsearch，完全可以先不上专用向量库，把检索质量调明白比换引擎更值钱。想从业务决策角度评估上不上 RAG，可参考英文站的 面向业务的 AI 课程 决策框架，帮你在锁定基础设施前先算清成本与所有权。

常见故障与团队实际的修法

报告最多的生产故障是检索精度低：系统返回主题相邻但错误的块。团队用重排序（reranking）修它——第二遍对前 20 个候选按查询重新打分，再送前 3-5 个给模型。一个重排序器多花点延迟，但实质抬升答案质量。第二常见的故障是模型完全无视检索上下文、直接回归记忆。用更严格的强制引用系统提示词、以及基于引文锚定的输出约束来修。第三是过期块：你的索引是昨天的文档快照。在文档变更事件时触发重新嵌入，而不是靠一个忘事的定时任务。对刚建立检索层的团队，把向量库怎么索引、怎么过滤搞扎实，收益远大于追最新的模型名。这方面的工程基础，可参考中文站的 AI 与 Excel 自动化里对数据流水线一致性的强调。

RAG 接下来去哪，以及怎么开始

路径越来越偏向把多次检索和工具调用串起来的 Agent，而不是单次问答。一个智能体 RAG 系统决定先查哪个源，读结果，再决定要不要第二次查。这种转变把检索当成一门独立的纪律，而让这些系统可靠的评估与流水线技能，正是 LLM 应用开发 和 MLOps 教育里讲的事。如果你正从原型走向团队每天依赖的系统，对扎实检索、纪律化评估和干净数据管线的投入，会胜过任何一次模型替换。从小处起步：挑一份可量化问题的文档集，建带标注的评估集，在碰提示词之前先调切块和检索。从那里往后，支持、合规和代码助手都是自然的首选目标，因为价值好量化。能上线可用的 RAG 团队，不是提示词最花哨的那批，而是索引最干净、评估最诚实的那批——正是区分"Demo"和"用户愿意拿真问题来问你的系统"的那个纪律。

常见问题

保持答案跟进新信息，RAG 比微调更好吗？

对频繁变化的知识，是的。微调把事实烤进权重里，更新一个事实意味着又一次昂贵训练，还有回归旧知识的风险。RAG 把事实放在索引里、只更新索引，模型不用重训就能保持新鲜。调风格或格式一致性可以用微调，但内容会变、需要锚定在源文档时，用 RAG。

RAG 的切块大小该从多少开始？

从每块约 300 token 开始，重叠调到问题绝不再落在边界上。更小的块（200 及以下）提升检索精度但可能丢周围上下文；更大的块（500+）带更多上下文但稀释相关性、单次更贵。在 100 条以上真实问题的标注集上量 recall@k，再据此调，而不是靠猜。

为什么我的 RAG 答案看着对，却引用了错误的文档？

那是检索精度故障，不是模型问题。模型只能引用你检索到的东西，所以错误块在 top-k 里，答案是会看着合理却指向错来源。加一个重排序器、收紧元数据过滤，并检查是不是切块把正确答案劈成了两块。先修索引，答案质量会自己上来。

语料只有几千份文档，还需要 RAG 吗？

需要，而且这正是最好下手的地方。几千份文档不需要重型引擎，现有 Postgres 实例上的 pgvector 就能便宜搞定，评估纪律比机器更重要。难点在切块和评估，你正想在小而可控的语料上练会它们，再去面对几百万向量。

RAG 基础设施一个月实际要花多少？

差别很大，小型生产系统通常落在几十到几百元人民币每月。托管向量库从 $0 起，小型索引每月几十元；嵌入 API 每块几分钱；规模上来后生成 token 占大头；监控和重排序再加一点。也要为评估工作量留预算——一套像样的标注集很便宜，省下的远超它所花。