RAG检索增强生成 思维导图定稿版总览文档解析与内容提取检索策略增强与生成系统架构与工程化评估与质量保障一、文档解析与内容提取工具选型PDFPyMuPDF快适合可编辑PDFpdfplumber准但慢Unstructured一站式但重OCRPaddleOCR中文识别率高Tesseract英文好表格Camelot规则表格首选Tabula无边框表格选型逻辑根据文档类型、数据量、中文/英文场景做决策工程风险预判通用工程思维格式兼容性风险 → 上线前跑兼容性测试失败case分类处理内容丢失风险 → 解析后加质量检查空文本/长度异常自动告警处理链路稳定性 → 异步任务队列 失败重试 断点续传兜底设计解析失败 → 自动重试(1次) → 降级OCR → 人工兜底解析质量自动检查产出文本为空或异常短时告警失败case分类存档持续优化解析链路真实踩坑可选只写真做过的[你的项目中的具体问题及解决方式]二、检索策略基础检索方式关键词检索BM25原理基于词频和逆文档频率算相关性优势精确匹配强实体/专有名词不会漏劣势同义词搞不定适用场景专业术语多、缩写多的领域法律/医疗向量检索稠密检索原理把文本转成向量算余弦相似度优势能理解语义劣势专有名词/精确匹配有时不如关键词Embedding模型选型中文用BGE/M3E英文用OpenAI ada混合检索BM25 向量检索为什么需要两者互补精确匹配语义理解融合方式各自打分后用RRF倒数排名融合或加权求和权重怎么定实体查询降向量权重模糊查询升向量权重工具Elasticsearch/Weaviate自带混合检索LangChain有EnsembleRetriever检索优化查询改写用LLM将模糊问题润色后再检索指代词补全“它怎么配置” → “K8s集群怎么配置”多路召回一个问题生成多个变体同时检索合并去重检索后处理重排序Rerank粗召回50条 → 精排取Top5工具Cohere Rerank / BGE-Reranker多样性控制MMR算法避免返回的5条内容高度重复元数据过滤 → 检索前先用标签缩小范围时间/来源/文档类型高级检索策略加分项了解原理即可知识图谱增强GraphRAG核心思路文档先抽实体和关系建图检索时问题→匹配实体→沿关系找到关联知识优势多跳推理能力强工具Neo4j LLMGraphTransformer / Microsoft GraphRAG自查询检索Self-Querying → LLM从问题中同时抽取语义和过滤条件向量数据库选型专用向量库Milvus大规模首选/ Qdrant / Weaviate / Pinecone传统数据库扩展PostgreSQLpgvector小规模省事/ Redis选型逻辑数据量小用pgvector少维护一个中间件量大了换Milvus三、增强与生成上下文构建Prompt组装模板设计结构角色设定 任务指令 参考资料 输出约束面试点角色设定要具体“你是客服”不如“你是某银行信用卡客服语气专业亲切”上下文注入方式直接拼接到System/User消息中注意点多轮对话时历史消息检索结果容易超窗口需动态截断引用溯源每条检索结果加编号[1][2]要求LLM引用时标注来源编号作用用户能核实也方便排查幻觉上下文窗口管理问题检索文档太多历史对话太长 → 超出token上限截断策略方案一优先保留最新消息历史消息从旧开始丢弃方案二对历史对话做摘要压缩保留关键信息检索结果数量控制 → 根据问题复杂度动态调整简单问题Top3复杂问题Top5-10幻觉抑制生成阶段能做的指令约束“仅根据提供的资料回答不知道就说不知道”“如果资料不足以回答列出缺失信息”输出校验要求LLM先引用原文再给结论结构化输出JSON更容易做格式校验置信度门槛 → 检索相关性分数低于阈值的直接回复“未找到相关信息”生成策略控制解码参数调优temperature事实问答设00.3创意类设0.71.0top_p一般设0.8~0.95和temperature二选一结构化输出让LLM输出JSON/Markdown格式工具LangChain的StructuredOutputParser / instructor库兜底解析失败时重试一次修复常见JSON错误尾部逗号/引号流式输出与体验优化为什么要流式首Token延迟高时用户会等得不耐烦实现方式SSE协议前端逐字展示注意点流式输出时引用标注可能会被截断需后处理补全四、系统架构与工程化整体架构设计核心链路用户提问 → 查询改写 → 检索 → 重排序 → 组装Prompt → LLM生成 → 后处理 → 返回解耦设计检索服务和生成服务分开部署独立扩缩容多级缓存体系为什么需要相同/相似问题反复检索成本高、延迟大三层缓存结构L1内存缓存最快存热点问题结果有过期时间L2Redis存语义相似问题的缓存用问题Embedding做KeyL3向量数据库本体无缓存命中时走完整检索缓存更新策略定时失效简单但知识更新不及时事件驱动知识库更新时主动失效相关缓存更实时但复杂相似问题匹配 → 新问题先算Embedding去Redis里找相似度0.95的缓存问题命中直接返回高并发与性能优化异步处理检索和LLM调用都用async避免阻塞多路并行查询改写生成的多个变体同时检索连接池管理向量库和Redis都配连接池别每次请求新建连接监控连接池状态满了说明需要扩容或限流批处理 → 离线索引构建用批量Embedding比逐条调API快10倍以上LLM调用优化流式输出减少用户等待体感设置合理max_tokens不让模型“废话”浪费延迟稳定性保障超时控制检索超时设500msLLM调用设15-30s超时不重试直接降级返回兜底答案或提示用户稍后重试限流用户级每人每分钟最多20次请求服务级LLM API有QPS上限用令牌桶做流量整形熔断LLM连续失败5次 → 熔断10秒 → 半开探测 → 恢复或继续熔断工具semaphore或circuitbreaker库降级链路检索挂了 → 返回“系统繁忙请稍后”LLM挂了 → 直接返回检索到的原文片段全部挂了 → 返回兜底话术告警幂等性 → 同一请求重试多次不会重复扣费/重复写入可观测性日志每次请求一个trace_id串联全链路关键节点打日志原始问题→改写后→检索结果数→LLM耗时→最终回复长度监控指标接口层QPS、成功率、P99延迟检索层召回率、检索耗时、缓存命中率LLM层首Token延迟、Token生成速度、幻觉率告警错误率5%或P99延迟翻倍 → 飞书/钉钉/企微告警LLM余额不足提前预警排查工具 → 至少能用trace_id在日志系统里查到一条请求的完整链路向量数据库运维索引更新策略增量更新新增/修改文档只更新对应向量全量重建碎片多、性能下降时定期做索引类型选择HNSW查询快内存占用高IVF内存省查询稍慢但有损精度备份与恢复定期快照五、评估与质量保障检索质量评估核心指标召回率Recall相关文档被找回的比例精确率Precision找回的文档中有多少是相关的MRR平均倒数排名第一个相关文档排第几NDCG考虑排序质量排名越靠前权重越高评估方法准备标注数据集50-100条问题 人工标注相关文档ID跑检索后用上述指标算分没有标注数据怎么评 → 用LLM当裁判判断检索结果和问题是否相关生成质量评估核心维度忠实度答案是否基于检索文档有没有瞎编相关性答案是否回答了用户问题完整性有没有遗漏关键信息评估方式人工打分准确但慢适合小规模评测LLM-as-Judge用GPT-4等强模型打分给评分标准示例工具RAGAS框架几行代码自动算faithfulness/context_relevancyRAGAS原理一句话把生成答案拆成原子陈述逐条检查能否从检索文档推断端到端评估业务指标用户点赞率/点踩率人工介入率多少问题最终转了人工客服答案采纳率用户看了答案后有没有继续追问性能指标端到端延迟P50/P99吞吐量QPS上限评测数据集构建来源真实用户历史问题 产品/业务方给的FAQ覆盖维度简单事实查询、复杂推理、模糊/边界问题对抗样本故意问知识库没有的、问得很像但实际不相关规模初期50-100条就够跑一轮评估持续更新线上badcase定期加入评测集反馈闭环线上采集用户点踩/举报的答案自动记录Badcase分析用trace_id找到完整链路日志分类归因检索没召回 / 召回了但排序低 / 召回了但LLM没用对症下药检索问题改切片/改混合权重LLM问题改Prompt/微调定期Review每周过一遍top badcase迭代优化