RAG

RAG 不是直接把整篇文档丢给大模型，而是先切成小块，叫 chunk。

常见策略：

• 按固定长度切，比如每 500 字一个 chunk。
• 按标题、段落、Markdown 层级切。
• 设置 overlap，比如相邻 chunk 重叠 50-100 字，避免上下文断裂。

优化点：

• chunk 太大：召回不精准，塞进模型上下文也浪费。
• chunk 太小：语义不完整，模型拿不到足够背景。
• 行业知识库通常要保留标题、章节、来源、时间等元数据。

把文本转成向量，语义相近的文本向量距离更近。

比如：

• “如何申请报销？”
• “报销流程是什么？”

这两句话字面不同，但语义相近，embedding 后距离会比较近。

关键点：

• embedding 模型决定语义表示质量。
• 中文/行业术语场景要选适配中文和专业领域的模型。
• 文档和用户问题最好用同一个 embedding 模型向量化。

用户提问后，也会被转成向量，然后在向量库里找最相似的文档 chunk。

常见相似度指标：

• Cosine Similarity：看方向是否相近，最常见。
• Inner Product：内积，常用于归一化后的向量。
• L2 Distance：欧氏距离，看空间距离。

常见参数：

• top_k：召回前 K 个 chunk，比如 5、10、20。
• score threshold：低于某个相似度分数的结果不要。

问题：

• 只靠向量检索可能召回“语义类似但不够准确”的内容。
• 对数字、专有名词、代码、表名、政策条款，向量检索有时不如关键词检索稳定。

把向量检索和关键词检索结合起来。

例如：

• 向量检索找语义相近内容。
• BM25/关键词检索找精确词、编号、术语、表名。
• 最后把两路结果融合。

适合场景：

• 行业术语多。
• 用户问题里有明确实体名、指标名、系统名。
• 文档里有编号、字段、代码、政策条款。

重排序是在“初步召回”之后，再用更强的模型重新判断哪些 chunk 最相关。

流程通常是：

1. 向量库先召回 top_k=20。
2. rerank 模型对“问题 + 每个 chunk”打相关性分。
3. 取前 3-5 个最相关 chunk 给大模型。

为什么需要 rerank：

• 向量检索是粗筛，速度快但可能不够准。
• rerank 是精排，速度慢一点，但相关性更好。
• 可以减少无关上下文进入 LLM，降低幻觉。

常见模型：

• bge-reranker
• Cohere Rerank
• cross-encoder 类模型

检索到相关 chunk 后，会把它们拼进 Prompt，让大模型基于资料回答。

常见模板：

请基于以下资料回答用户问题。

如果资料中没有答案，请说明不知道，不要编造。

资料：

{retrieved_context}

问题：

{user_question}

优化点：

• 明确要求“只基于资料回答”。
• 保留来源，方便引用。
• 控制上下文长度，避免塞太多无关 chunk。

RAG 评估不只是看最终回答好不好，还要拆开看检索和生成。

常见指标：

• Recall@K：正确资料是否出现在前 K 个召回结果里。
• Precision@K：前 K 个结果里有多少是真相关。
• MRR：第一个正确结果排得是否靠前。
• Context Relevance：给模型的上下文是否相关。
• Faithfulness：回答是否忠于资料，有没有编造。
• Answer Relevance：回答是否真正回答了用户问题。
• Citation Accuracy：引用来源是否正确。

简单说：

• 检索差：模型拿不到正确资料，再强也答不好。
• 生成差：资料拿到了，但模型总结错或编造。
• Prompt 差：模型不知道该如何使用资料。

• 调整 chunk 大小和 overlap。
• 换更适合中文/行业的 embedding 模型。
• 增加 metadata，比如文档类型、业务线、时间、来源。
• 使用 hybrid search。同时使用关键词检索（BM25）和语义向量检索，取并集后融合排序。关键词检索擅长精确匹配（如产品型号、错误码），语义检索擅长理解意图，两者互补能大幅提升召回率。
• 提高 top_k 后再 rerank。
• 对用户问题做 query rewrite，比如补全简称、改写口语问题。

• 引入 reranker。初步检索返回 Top-50 后，用 flow_ranker 对 Query 和每个候选片段做精细打分，重新排出 Top-5 送入 LLM。本质是"以计算换智能"，解决向量检索中 Top-K 排序不够精准的问题。
• 调整初召回数量，比如先召回 20 个，再精排到 5 个。
• 对长文档 chunk 做去重，避免同一段重复占满上下文。

• 优化 Prompt，要求基于资料、不可编造。
• Prompt 约束：在 System Prompt 中明确要求模型“只基于给定的上下文回答，无法从上下文找到答案时明确说明”，杜绝幻觉。
• 加引用来源。要求模型在回答中标注信息来源（如“根据《XX 手册》第三章...”），方便用户验证和溯源。
• 对不同问题类型设计不同 Prompt，比如流程类、定义类、对比类。
• 控制上下文顺序，把最相关内容放前面。

• 清洗 PDF/OCR 噪音。
• 删除重复文档。
• 保留标题层级，避免 chunk 失去语境。
• 建立问题-答案-证据集，用于评估。
• 对行业术语、缩写、别名做词表增强。

对行业本地知识库来说，最容易决定效果的通常不是 LLM，而是：

• 文档是否干净。
• chunk 是否合理。
• embedding 是否适配中文和行业语义。
• 正确资料能否被召回。
• 是否有 rerank。
• 是否要求模型基于资料回答并给出处。

一句话总结：RAG 的核心不是“把文档丢给大模型”，而是先把正确资料找出来，再让大模型基于这些资料稳定作答。