前言
最近一年，RAG（Retrieval-Augmented Generation）几乎成了大模型应用的标配。无论是企业知识库问答、智能客服，还是内部文档助手，只要提到“让大模型知道你的数据”，十有八九会想到RAG。它看起来门槛低、见效快——把文档切一切、向量化、存进数据库，再拼个Prompt，一个“智能问答”就跑起来了。但现实往往比演示复杂得多。上线后用户问“为什么答非所问？”、“为什么答案和文档对不上？”，甚至“为什么干脆不回答？”，这些问题背后，是RAG系统中每一个环节都可能成为性能瓶颈或质量短板。
笔者在多个RAG项目实践中发现，真正决定效果的，往往不是用了哪个大模型，而是那些被忽视的基础环节：如何切分文档才能保留语义又不丢失上下文？向量检索召回的内容真的相关吗？LLM生成的答案是否忠实于原文？这些问题没有标准答案，但有可复用的方法论。本文试图以工程师视角，系统性地拆解RAG落地过程中最常遇到的问题，不仅告诉你“是什么”，更解释“为什么”以及“怎么办”。希望这份汇总能帮助你在构建RAG系统时少走弯路，更理性地看待这项技术的能力边界。
1. RAG、微调与提示工程：何时该用谁？
1.1 三者的核心差异在于知识注入方式
RAG通过外部检索动态引入知识，微调将知识固化到模型参数中，提示工程则依赖静态模板引导模型行为。这种根本差异决定了它们各自的适用边界。
- RAG的优势在于知识可更新、可溯源、成本低。它不改变模型本身，仅在推理时提供上下文。
- 微调改变模型内部参数，适合调整模型风格、格式偏好或处理高度专业术语，但知识一旦固化便难以更新。
- 提示工程是最轻量级的方法，适用于规则明确、知识范围小的场景，但面对复杂或动态知识时力不从心。
1.2 选择RAG的五大典型场景
当面临以下情况时，RAG通常是更优解：
- 知识频繁更新：如产品文档、政策法规、FAQ，只需更新向量库，无需重新训练模型。
- 需要引用来源：客服、法律、医疗等场景要求答案可追溯，RAG天然支持标注出处。
- 训练数据不足：微调通常需要数千条高质量样本，而RAG仅需可检索的文本。
- 依赖实时信息：股票价格、新闻事件等无法通过训练固化的内容，必须通过检索获取。
- 预算有限：微调涉及GPU资源、数据标注、模型部署等高成本，RAG初期投入更低。
值得注意的是，三者并非互斥。实践中常见组合如“RAG + 微调”：先微调模型使其更擅长理解检索结果的结构，再通过RAG注入最新知识。这种混合策略能兼顾灵活性与专业性。
2. 文档分块：RAG效果的隐形基石
2.1 分块策略直接影响检索精度
文档分块（Chunking）是RAG流程中最易被低估的环节。切得太碎，上下文断裂；切得太大，噪声干扰严重。理想分块需在语义完整性和检索粒度间取得平衡。
- 固定长度切分：简单但危险，可能在句子中间切断，导致语义不完整。
- 按句子/段落边界切分：保证每个块是完整语义单元，但块大小不一，影响向量一致性。
- 滑动窗口策略：在句子边界基础上增加重叠（如20%），确保跨块信息不丢失。
2.2 实践中的分块配置建议
对于FAQ类知识库，推荐采用“句子边界 + 滑动窗口”混合策略：
- 块大小：512 tokens 是经验值，兼顾上下文与噪声控制。
- 重叠比例：20%（如window=512, step=100）能在存储开销与信息保留间取得平衡。
- 依据：FAQ问题常涉及连续多段内容，重叠可避免关键信息被切分到不同块中。
笔者认为，分块不应一刀切。技术文档适合按章节切分，会议纪要适合按发言轮次，而法律条文则需保留条款编号。分块策略应与知识结构对齐，而非机械套用参数。
3. RAG系统全流程解析
3.1 三大核心阶段
RAG系统可概括为三个阶段：
- Indexing（索引构建）：将原始文档转化为可检索的向量表示。
- Retrieval（检索）：根据用户查询找到最相关的知识片段。
- Generation（生成）：结合查询与检索结果，生成最终答案。
这三个阶段看似线性，实则相互影响。例如，分块策略影响索引质量，索引质量决定检索效果，检索结果又直接制约生成质量。
3.2 九步详细流程
具体实施包含以下步骤：
- 文档解析：将PDF、Word等转为纯文本，注意表格、图片等特殊内容处理。
- 文档分块：按前述策略切分。
- 向量化：使用Embedding模型生成向量。
- 向量存储：存入FAISS、Milvus等向量数据库，附带元数据。
- Query改写（可选）：对模糊或依赖上下文的查询进行扩展。
- 向量检索：计算相似度，返回Top-K结果。
- 重排序（Rerank）：用Cross-Encoder精排Top-K结果。
- Prompt构建：拼接检索结果与用户问题，控制总长度。
- LLM生成：输出答案，可要求引用来源。
每一步都存在优化空间。例如，Query改写能显著提升模糊问题的召回率，而Rerank则是提升最终答案质量的关键杠杆。
4. Embedding模型选择与调优
4.1 主流模型对比
Embedding模型的选择需考虑语言、部署方式与性能：
| 场景 | 推荐模型 | 部署方式 |
|---|---|---|
| 中文 | BGE、text-embedding-v4 | API/私有化 |
| 英文 | OpenAI text-embedding | API |
| 多语言 | bge-m3 | 私有化 |
4.2 选择考量因素
- 语言支持：中文场景优先BGE系列，其在中文语义理解上表现优异。
- 部署方式：API调用方便但长期成本高；私有化部署需GPU，但可控性强。
- 性能指标：本地部署延迟低，吞吐取决于硬件；精度需在自有数据上验证。
- 维度：高维向量（如1024维）表达能力强，但存储成本高。
笔者观察到，许多团队直接使用OpenAI Embedding，却忽略了领域适配问题。在金融、医疗等专业领域，通用Embedding对术语理解不足，导致检索偏差。此时，微调Embedding模型或使用领域专用模型更为有效。
5. RAG效果差？系统性调试方法
5.1 检索阶段调试
若答案错误，首先检查检索结果是否相关。可通过调试函数打印Top-K结果，观察：
- 相似度分数是否合理
- 内容是否与问题相关
- 来源是否权威
若检索结果无关，问题可能出在分块、Embedding或Query表述上。
5.2 生成阶段调试
若检索结果正确但答案错误，问题在生成阶段：
- Prompt是否明确要求“仅基于上下文回答”？
- 是否设置了低temperature以减少幻觉？
- 是否要求模型引用来源？
建立Bad Case库至关重要。记录失败案例，分析是检索问题还是生成问题，针对性优化。
6. 混合检索与重排序：超越纯向量检索
6.1 向量检索的局限性
纯向量检索对精确关键词（如产品型号、人名）不敏感，可能漏掉字面匹配但语义相近的内容。Embedding模型对领域专有词理解也可能不准。
6.2 混合检索与Rerank
- 混合检索：结合向量检索与BM25关键词检索，取长补短。例如，对包含型号的查询，优先保证关键词匹配。
- Rerank：使用Cross-Encoder对Top-K结果精排。Bi-Encoder（向量检索）速度快但精度低；Cross-Encoder交互强、精度高，适合精排少量候选。
实践建议：召回20条，Rerank后取Top 3喂给LLM。中文场景推荐bge-reranker，效果显著优于纯向量检索。
7. 评估与维护：RAG系统的长期生命力
7.1 RAGAS评估框架
RAGAS提供自动化评估，核心指标包括：
- Faithfulness（忠实度）：答案是否基于检索内容，避免幻觉。
- Answer Relevancy：答案是否回答问题。
- Context Precision/Recall：检索内容是否相关且完整。
无需人工标注，通过LLM自动评估，大幅降低维护成本。
7.2 知识库维护最佳实践
- 定期审核：每周分析Bad Case，识别系统性问题。
- 增量更新：避免全量重建索引，支持高效更新。
- 版本控制：保留历史索引，便于回滚。
- 监控告警：跟踪空结果率、负反馈率等指标。
笔者认为，RAG系统不是一劳永逸的。知识库的生命周期管理、用户反馈的闭环迭代，才是保证长期效果的关键。
8. 高级话题：GraphRAG、多模态与安全
8.1 GraphRAG：知识图谱增强
GraphRAG通过构建实体-关系图谱，支持复杂推理。适合高价值、复杂知识库，但构建成本高。简单FAQ仍以传统RAG为主。
8.2 多模态RAG
处理图片、表格、视频时，需统一多模态Embedding（如CLIP）。表格转Markdown保留结构，视频抽帧+语音转文字分别索引。
8.3 安全防护
- Prompt注入防护：过滤用户输入中的恶意指令。
- 权限控制：按角色过滤可检索文档。
- 敏感信息脱敏：入库前处理，输出时二次过滤。
结语
RAG看似简单，实则是一个系统工程。从文档分块到向量检索，从Prompt设计到效果评估，每个环节都藏着影响最终体验的细节。它不是万能药，无法解决所有知识问答问题，但在合适的场景下，它确实是最经济、最灵活的方案。技术的魅力不在于追逐热点，而在于理解其边界，并在边界内做到极致。希望这份汇总能成为你构建RAG系统时的实用手册，在喧嚣中保持清醒，在实践中持续精进。
