目录1. 概述2. 向量数据库基础原理3. Embedding嵌入4. 向量数据库5. 分块策略Chunking6. 检索7. 重排序8. Prompt9. 评估10. 问答1. 概述RAGRetrieval-Augmented Generation检索增强生成。让 LLM 在生成回答前先从外部知识库中检索相关信息的技术。核心问题信息干什么用的领域分类通用的、专业的信息从哪里来的信源分类网络搜索、行业共享、内部数据有哪些额外要求实时性外部更新、内部更新、不更新数据安全性第三方存储、私有化部署有哪些检索方案技术分类字符串匹配、语义匹配2. 向量数据库基础原理存储将知识文档 通过 Embeding 模型转换为高维向量存储为向量数据库。检索在检索时用户问题或者关键词也通过 Embeding 模型转换为高维向量通过向量匹配找到语义相近的资料文本。回填将资料拼装到对话记录中作为大模型输入的一部分。3. Embedding嵌入将文本或者其他模态的内容映射到语义空间中。所谓语义空间就是一个高维向量空间向量相似度高或者距离近表示两个东西的语义相近。对于RAG做的是段落级别的Embeding每个切割好的文档通过 Embeding 模型转换为一个高维向量。RAG 的 Embeding 模型有哪些闭源模型如 OpenAI通过API进行操作效果好较贵开源模型如 BGE-M3、E5、Jina支持本地部署效果需要测试相对便宜RAG 的 Embeding 模型 的超参数上下文长度每个文本片段的长度上限语义空间维度768维、1024维、1536维… 理论上维度高意味着语义精度高但是也会导致匹配的检索速度变低语种支持如何选型 RAG 的 Embeding 模型效果匹配精度和 模型来源、语义空间维度、领域适配 有关性能查找速度和 语义空间维度、查找算法、服务器部署 有关成本闭源省心价格高、开源自己调试价格低安全性对数据安全有强需求则可考虑私有化部署4. 向量数据库原理概述向量数据库专门存储高维向量并支持近似最近邻搜索ANN, Approximate Nearest Neighbor。核心算法包括 HNSW图索引、IVF倒排文件索引等。ANN 是近似搜索用牺牲极小精度换取极大速度提升。在 1000 万条向量中精确搜索可能需要几秒ANN 只需几毫秒。选型数据库适合场景注意点Pinecone快速上线、不想运维贵、 vendor lock-inMilvus/Zilliz大规模、云原生生态成熟学习曲线略陡Qdrant自托管、高性能Rust 编写资源占用低Weaviate需要 GraphQL 接口模块化设计扩展性好pgvector已有 PostgreSQL 架构适合中小规模超大规模性能受限选型标准效果是否需要混合搜索向量关键词过滤性能延迟要求毫秒级 vs 秒级可接受数据规模与增长预期成本采购成本运维成本与团队能力安全是否需要私有化多租户隔离需求5. 分块策略Chunking概述长文档不能直接整体 Embedding太长、太粗、噪声多需要切成小段。Chunking 的核心矛盾是块太大→检索不精准块太小→丢失上下文。分块方案策略适用场景优缺点固定长度快速上线、通用文本简单但可能切断语义如把一句话切两半递归分块结构化文档Markdown、HTML按标题层级切保留文档结构语义分块高质量要求场景按句子/段落语义边界切效果最好但成本高Agentic 分块复杂文档合同、论文用 LLM 判断边界最贵但最精准固定长度分块的要点分块大小通常 256~1024 tokens从 512 tokens 开始测试上下调整关注资料的召回率和精确度重叠大小相邻块重叠 10%~20%避免关键信息被切在边界元数据每个 Chunk 必须保留来源信息文件名、页码、章节否则无法溯源特殊文档表格、图片、代码块 怎么切割内容去噪页码、页眉、页脚6. 检索检索是从向量库中找出与用户问题最相关的 Chunk检索方案按语义查找按关键词混合查找检索要点预处理改写、提取关键词、引申同义词处理检索召回 10~20 个资料多召回一点后面再筛选后处理组合、去重、重排、筛选检索质量评估内部测试数据集召回率、精确度上线回答采纳率7. 重排序原理用更复杂的模型通常是 Cross-Encoder对粗筛结果精细排序。重排要点必要性数据量小10万或质量要求不高时可省略数据量大或要求精准时必须加选几个Rerank 后只取 Top 5~10 给 LLM控制 Token 成本选型BGE-Reranker开源、Cohere RerankAPI、Jina Reranker补充延迟成本: Rerank 是同步阻塞的100 条 × 几百 ms 几秒延迟需评估用户体验容忍度8. PromptRAG 的 Prompt 核心任务是把检索到的 Chunk 以结构化方式注入并约束 LLM 只能基于这些内容回答。要点设计要点说明上下文窗口管理检索到的 Chunk 总长度不能超过模型上下文上限要留余量给输出引用格式统一编号、统一格式方便前端解析高亮防幻觉指令不知道就说不知道比尽力回答更可靠要显式写入系统提示系统提示隔离把角色设定和约束条件放在 system prompt用户问题放在 user prompt多轮对话历史对话如何参与检索是只拿最新问题检索还是把历史也拼进去难点如何防止编造资料提示词明确禁止编造对于冲突信源进行综合分析结构化输入格式明确输出格式也明确标出引用校验增加一个校验模块规则、模型来核对引用是否真实存在检索到的内容太长超出上下文窗口怎么办选用长窗口模型精排与筛选压缩成摘要让大模型逐个理解并整合9. 评估每个环节的质量都需要评估数据质量 → 分块质量 → 检索质量 → 重排序质量 → Prompt 质量 → 生成质量 ↑____________________________________________________↓ 用户反馈回流评估指标指标含义怎么测Context Precision检索到的 Chunk 里有多少是真正相关的人工标注每个 Chunk 的相关性Context Recall回答一个问题需要的信息有多少被成功检索到了对比理想答案和检索结果的覆盖度Faithfulness回答内容是否忠实于检索到的资料用 LLM 判断每个陈述是否能被 Chunk 支撑Answer Relevance回答是否切题有没有答非所问用 LLM 判断回答与问题的匹配度Answer Correctness回答事实是否正确与标准答案对比或用专家人工评分关于产品层面的溯源设计可点击的索引侧栏展示信息源置信度标注用户可反馈用户体验追问引导多模态展示历史检索10. 问答Embedding 和传统的关键词搜索如 Elasticsearch有什么区别关键词搜索基于字面匹配TF-IDF/BM25适合精确匹配但无法理解同义词Embedding 基于语义相似度能捕捉意图层面的相似。实际产品中通常采用混合检索Hybrid Search两者互补。怎么选一个 Embedding 模型看三个维度① 语言支持是否覆盖业务语种② 领域适配通用 vs 垂直领域如法律、医疗③ 成本与性能维度、推理延迟、是否开源可私有化。通常先用开源模型跑通 MVP再考虑是否换更强的商业模型。为什么不用 MySQL/PostgreSQL 存向量传统数据库的索引B树是为低维结构化数据设计的高维向量查询会退化为全表扫描性能无法接受。pgvector 是 PG 的扩展适合中小规模但千万级以上规模还是需要专用向量数据库。向量数据库的选型标准是什么① 数据规模与增长预期② 是否需要混合搜索向量关键词过滤③ 运维成本与团队能力④ 多租户隔离需求⑤ 延迟要求毫秒级 vs 秒级可接受。Chunk Size 怎么定需要实验。原则① 不超过 Embedding 模型的最大输入长度② 保证每个 Chunk 语义自洽最好是一个完整观点/段落③ 通过评估召回率和回答质量反推最优大小。通常从 512 tokens 开始上下调整对比效果。分块策略不好会导致什么问题① 检索失败关键信息被切散无法被召回② 回答不完整Chunk 缺少上下文LLM 无法完整理解③ 幻觉增加LLM 被迫基于碎片信息脑补答案。检索不到相关内容怎么办设计多层降级策略① 扩大 Top-K 或放宽相似度阈值② 切换为关键词搜索兜底③ 触发联网搜索如果允许④ 诚实告知用户未找到相关信息而非让 LLM 编造。产品层面要区分检索失败和生成失败的日志与监控。怎么评估检索质量离线用 RecallK、MRR 等指标在线用检索结果是否包含正确答案的人工标注。更产品化的指标是同样的问题有 RAG 和没 RAG 的回答采纳率差异。为什么需要检索Rerank 两层架构而不是直接用 RerankCross-Encoder 需要把查询和每个文档拼接后一起编码计算复杂度是 O(N)无法承受百万级文档的实时排序。所以先用向量检索O(1) 近似搜索粗筛到 Top-K再用 Rerank 精排平衡效率与精度。Rerank 的瓶颈是什么延迟和成本。Rerank 模型通常比 Embedding 模型大每对查询文档都要过一遍模型。如果 Top-K 很大或文档很长延迟会显著增加。产品上要设计好超时降级策略。怎么设计 Prompt 让模型不编造引用三层约束① 系统提示中明确禁止编造设定无信息则拒绝回答的基调② 给引用内容加明确边界如用 XML 标签包裹③ 后处理校验用正则或 LLM 二次检查回答中的引用编号是否真实存在于输入的 Chunk 中。检索到的内容太长超出上下文窗口怎么办① 压缩用 LLM 先对每个 Chunk 做摘要只把摘要注入 Prompt② Map-Reduce每个 Chunk 单独让 LLM 回答再汇总③ 长上下文模型如果预算允许换支持 128K/200K 上下文的模型④ 精排用 Rerank 确保只把最相关的少量 Chunk 送进去。RAG 能完全消除幻觉吗不能。RAG 减少的是无中生有的幻觉但如果检索到的资料本身有误或者 LLM 错误理解了资料仍然会产生幻觉。产品上要设计溯源置信度人工反馈的多层防御体系而不是追求绝对零幻觉。为什么 RAG 有时检索到了正确内容但 LLM 还是答错了可能原因① Chunk 被截断关键信息在边界处丢失② 多个 Chunk 信息矛盾LLM 综合错误③ Prompt 设计不当模型忽略了关键 Chunk④ LLM 本身对复杂逻辑推理能力有限。排查方法看检索日志确认 Chunk 是否进入 Prompt做 Faithfulness 评估定位问题环节。RAG 的延迟怎么优化① 检索侧用更小的 Embedding 模型、更高效的索引算法、缓存热门查询② Rerank 侧控制 Top-K 数量、用更轻量的 Rerank 模型或跳过 Rerank③ 生成侧用流式输出SSE降低感知延迟、换更快的 LLM④ 架构侧预检索用户输入时就开始检索、边缘缓存。怎么设计溯源功能才能让用户信任① 可见性引用必须可点击、可查看原文不能只是文字标注② 精确性溯源要精确到段落甚至句子而不是整篇文档③ 透明性当信息来自多个冲突来源时诚实展示不同观点④ 可验证性提供原文链接或文档 ID方便用户自行核实。怎么评估一个 RAG 系统的好坏分三层① 检索层RecallK、Context Precision看找得全不全、准不准② 生成层Faithfulness、Answer Relevance看答得对不对、切不切题③ 业务层用户满意度、任务完成率、人工介入率。自动化评估用 RAGAS 跑离线测试集在线用 A/B Test 对比不同策略的效果。Faithfulness 怎么自动化评估用 LLM-as-a-Judge。把回答拆成多个事实陈述逐一检查每个陈述是否能被检索到的 Chunk 支撑。可以设计 Prompt 让 LLM 输出支撑/不支撑/无法判断三分类并给出理由。注意要定期用人工标注校准 LLM 评委的偏差。RAG / Fine-tuning 选哪个RAG是否需要 RAG 实际上是判断是否需要给模型提供额外的资料最典型的是需要一定实时性的资料时使用 RAG 是有必要的。再比如模型能力有边界一些专业知识模型答不上来。Fine-tuning是否需要 Fine-tuning 实际上是要判断我们是否需要调整模型能力。比如无论我们如何调整 prompt模型回答与预期始终有差距此时就需要训练模型。成本RAG无训练成本增加预测或者说使用成本Fine-tuning有训练成本包括构造数据的成本降低预测成本设计一个面向企业内部的 RAG 知识库产品你会怎么做需求分析明确用户是谁员工客服、知识类型文档制度产品手册、更新频率数据层文档解析PDF/Word/Excel、分块策略、元数据设计部门、权限、版本检索层Hybrid Search Rerank按用户权限过滤生成层Prompt 设计角色约束引用格式、多轮对话管理评估层离线测试集 在线满意度 Bad Case 复盘产品层溯源展示、置信度提示、反馈收集、权限控制RAG 产品的定价模式怎么设计常见模式① 按查询次数适合轻量用户② 按存储量查询量适合知识库场景③ 按席位SaaS 模式适合企业④ 按 Token 消耗透明但用户难预估。产品上要提供用量仪表盘让用户感知到知识库大小和查询频率对成本的影响。