面试题 · 评估
搜索「医疗」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
假设需要为医疗或法律等专业领域构建一个基于检索增强生成（RAG）的智能助手，请设计其整体技术链路，包括数据处理、检索系统、生成模型和评估机制。
核心挑战：专业文档结构复杂、术语密集、更新频繁
单一向量检索不够，需多路融合
学习内容与项目面试，在同一条路上。
| 检索方式 | 适用场景 | 实现 |
|---|
| 稠密向量检索 | 语义相似、同义表达 | 领域微调Embedding（如MedCPT、法律BERT） |
| 稀疏关键词（BM25） | 精确术语、药品名、法条编号 | Elasticsearch |
| 知识图谱检索 | 关联推理、禁忌症、判例引用 | Neo4j + 子图匹配 |
| 重排序（Rerank） | 精排Top-K | 交叉编码器微调 |
关键设计：查询改写（Query2Doc）处理口语化输入，如"心跳快"→"心动过速"
| 维度 | 指标 | 方法 |
|---|---|---|
| 检索质量 | Recall@K、MRR | 人工标注黄金文档集 |
| 生成质量 | 事实准确性（FactScore）、幻觉率 | 领域专家审核 + NLI模型 |
| 端到端 | 答案有用性、合规性 | 医生/律师打分 + 用户反馈闭环 |
| 效率 | 延迟P99、吞吐 | 线上压测 |
持续优化：Bad Case归因分析（检索失败？生成忽略？），针对性迭代。
建议系统学习该知识点
场景切入
假设你要给某三甲医院做一个智能问诊助手，医生会问患者症状，然后系统要检索最新指南和药品说明书来辅助诊断。你觉得从原始文档到最终回答，整个技术链路该怎么搭？
层层追问
专业领域的RAG系统，你觉得数据层面有什么特别的难点？……那处理完数据后，检索只用向量够吗？……如果用户问的问题口语化，比如‘头很痛’和‘剧烈头痛’怎么匹配？……最后生成时怎么保证模型不瞎编，还能引用原文？
直球架构
设计一个面向医疗或法律领域的RAG智能助手技术架构，请从数据处理、检索系统、生成模型和评估机制四个方面讲清楚你的设计思路和关键决策点。
这道题问的是专业领域[[RAG]]智能助手的设计，我觉得它本质上是在问一件事：怎么让大模型在知识密度高、容错率极低的场景下，既能用上最新最准的知识，又能给出可信、可解释的回答。说白了，就是解决专业领域的 可信生成 问题。
我会从数据处理、检索、生成和评估四条线来讲，不过先划个边界：很多人纠结RAG和微调选哪个，我的看法是，高频更新的知识、需要引用溯源的场景，RAG是必选项；但像处理病历或合同这种格式稳定的文档，微调反而能提升格式规范性。真正落地往往是 RAG加微调混合，RAG负责事实，微调负责风格和合规。
先说数据处理层。专业文档结构复杂，比如一份医学指南，里面有诊断标准、用药方案、注意事项，如果你按固定字数[[切块]]，很可能把“症状”和“对应治疗”切到两个块里，检索出来就是错的。所以我会按语义边界切，比如医疗文档按“症状-诊断-治疗”完整保留，法律文档按“事实-法条-判决”逻辑链来切。同时，我会提取实体关系构建一个轻量级 [[知识图谱]] ，比如药品的禁忌症、法条之间的引用关系，这能补上纯文本检索做不了的关联推理。举个例子，用户问“高血压能不能吃布洛芬”，纯文本可能只匹配到“布洛芬”和“高血压”两个词，但知识图谱能直接告诉你“布洛芬与ACEI类药物联用需谨慎”，这个信息在文本里可能分散在两段。
检索层我倾向用混合召回。单一向量检索在专业领域不够，因为术语表达很精确，比如“心动过速”和“心跳快”语义相近，但“盐酸二甲双胍”和“降糖药”向量距离可能很远。所以我会把稠密向量检索和 [[BM25]] 关键词检索结合起来，前者抓语义相似，后者保精确匹配。另外，我会做一个查询改写模块，把用户口语化的输入翻译成专业术语，比如“心跳快”转成“心动过速”。[[重排序]]这一步也很关键，用 [[Cross-Encoder]] 对初筛结果精排，把最相关的文档顶到前面。
生成模型层，基座我倾向选一个在领域上做过预训练的，比如医学的Huatuo或法律的LawGPT，如果不够成熟，就用通用模型加领域 [[SFT]] 。关键设计是强制模型输出引用来源，比如“根据《指南》第3章第2节”，这样专家能追溯验证，也方便用户判断可信度。另外，没有可靠来源的问题必须拒答，医疗场景我还会加一句“请咨询专业医师”的风险提示，这既是合规要求，也是安全底线。
评估机制不能只看ROUGE或BLEU，那些在专业领域没用。我会分三层：检索质量用 Recall@K 和MRR，生成质量用事实准确性指标，比如 [[Faithfulness]] ，让领域专家审一批典型case。最核心的是建一个bad case闭环，每次发现模型答错了，追下去看是检索没找到正确文档，还是找到了但模型生成时忽略了，还是引用格式错了。针对性地修，迭代几轮之后质量会稳定很多。
最后提一个我最近在关注的方向：当知识库频繁更新时，比如药品说明书改了，索引更新不及时会导致检索结果过时。这种情况下，我倾向用双缓冲策略，新旧索引共存，线上查询先走新索引，如果召回率不足再回退到旧索引，同时后台异步重建。但这里有个坑，如果更新太频繁，重建压力会很大，需要设计增量更新机制。
所以整体上，我更愿意把领域RAG助手看作一个知识可信的工程系统，而不是单纯堆模型。从数据切分到检索融合，再到生成约束和评估闭环，每一步都要为可解释和低容错服务。