面试题 · 检索
搜索「重排」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在构建面向专业领域（如医疗或法律）的智能助手时，应如何系统性地设计与优化检索增强生成（RAG）的整体链路？请详细阐述文档预处理、索引构建、检索策略选择、结果重排序、生成内容融合及输出优化等关键环节，并结合实际应用场景说明各阶段的技术选型依据与改进方向。
核心挑战：专业文档格式复杂（PDF表格、扫描件、法律条款层级）
双塔索引设计：
| 索引类型 |
|---|
按学习路线查看教程、项目和面试题。
| 技术选型 |
|---|
| 适用场景 |
|---|
| 稠密向量 | BGE-M3/E5领域微调 | 语义相似、同义词泛化 |
| 稀疏向量 | BM25 + 领域词表扩展 | 专业术语精确匹配 |
| 图索引 | 知识图谱（医疗UMLS/法律法条引用） | 跨文档逻辑关联 |
关键优化：向量模型用领域语料做MLM+对比学习二次预训练
建议先掌握RAG基础流程，再结合垂直领域特点学习文档分块、向量检索、重排序模型和提示工程，多参考医疗/法律类RAG实战案例。
场景切入
假设我们做一个医疗智能助手，用户问症状，你从病历库和文献里检索信息回答。你觉得从原始文档到最后生成答案，整个链路里哪些环节最容易被忽略？比如文档怎么切、索引怎么建，给我讲讲你的设计思路。
层层追问
RAG的流程你熟吧？从文档处理开始……那专业领域文档格式复杂，表格、扫描件你怎么处理？……索引怎么建才能兼顾语义和术语匹配？……检索回来的片段怎么排序和融合，才能保证答案准确？
直球架构
构建一个法律领域的RAG系统，文档预处理、索引构建、检索策略、重排序、生成融合和输出优化，每个环节你选什么技术方案？关键选型依据和改进方向是什么？直接说设计思路。
这道题问的是面向专业领域的[[RAG]]怎么设计，我觉得它的本质不是简单搭一个检索加生成的流水线，而是怎么把领域知识的结构和逻辑嵌到整个链路里，让模型既找得准又生得对。
我先说文档预处理。很多人上来就[[切块]]，但医疗或法律这种领域，文档是高度结构化的，比如法律条款有层级，医疗指南里表格和图片混排。如果直接按固定字数切，容易把一个完整条款切碎，检索时语义不连贯。所以我会先用 [[多模态]]解析，比如LayoutLM或者[[OCR]]把图文位置保留下来，然后按语义边界切分，法律就按条款编号锚定，医疗按UMLS术语边界。另外我会给每个文档块打元数据标签，像文档类型、时效性、权威等级，这样后续检索可以按场景过滤。举个具体例子，假设做企业合规助手，内部SOP文档经常更新，如果检索到过期版本，生成结果就是错的，所以元数据里时效性字段特别重要。这里有个风险：如果文档质量本身差，比如扫描件模糊，解析精度不够，后面全链路的收益都会打折。
接下来索引构建。我的做法是 混合召回，不只用一种。稠密向量擅长语义匹配，比如同义词泛化，但专业术语精确匹配不行，比如法律条文编号“第X条”必须精确命中，这时候稀疏向量比如[[BM25]]配合领域词表扩展就管用。还有一类跨文档的逻辑关联，比如医疗里药物相互作用，靠向量可能不够，我会引入[[Knowledge Graph]]做图索引。但真正落地时，这三种不是等权重，而是根据场景动态调。比如说订单异常场景，用户问“退款到账时间”，关键词匹配“退款”就够了，语义向量反而可能召回无关的“退货”，所以我会优先BM25，向量做补充。前提是你的向量模型得用领域语料做过[[SFT]]或对比学习微调，否则通用模型在专业领域效果差很多。
检索策略这块，我倾向于 多路召回加精排。召回层同时走向量Top-K、BM25 Top-K和图邻居扩展，合并去重。然后[[重排]]用[[Cross-Encoder]]精排，但光靠模型不够，我会加入手工特征，比如法律场景引用频率和时效性，医疗场景权威等级。这里有个坑：重排模型如果不做领域微调，打分可能不靠谱，比如把非权威来源排前面。所以上线前我会用一批标注数据做微调，然后监控[[RAGAS]]指标里的context precision。
生成融合阶段，我最关注的是引用锚定和校验。检索回来的片段不能全塞给大模型，得做上下文压缩，比如用LLM摘要控制token。同时强制生成时标注来源片段ID，法律场景必须输出“依据《XX法》第X条”，这样结果可追溯。后处理加一个领域规则引擎，比如医疗场景查药物禁忌，如果生成内容冲突就拦截。说白了，生成环节如果不做约束，[[Hallucination]]风险很高，尤其专业领域用户对准确性要求极高。
最后说端到端优化。我一般会建一个闭环：线上错误案例回流，分析是检索没召回还是生成乱编，然后针对性微调[[Embedding]]或Reranker。评估体系分两路，检索用Recall@K，生成用答案相关性和事实准确性，医疗场景必须人工医生标注。
其实还有个有意思的延伸点：当检索结果质量不高时，与其硬塞给模型，不如让模型自己判断要不要拒绝回答。比如结合[[Self-RAG]]或者[[Corrective RAG]]的思路，让模型先反思检索结果够不够，不够就二次检索或直接说不知道。这个方向我觉得在风险敏感场景特别有价值。
所以整体上，我更倾向把RAG看成领域知识工程和模型能力的结合，而不是纯技术的堆叠。每个环节的选型都要问自己：这个场景的失败模式是什么？比如法律场景，失败是引用错误法条；医疗场景，失败是漏掉禁忌信息。想清楚这些，设计才有针对性。