面试题 · 检索
搜索「分块」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请设计一个专业领域的RAG(Retrieval-Augmented Generation)系统架构，包括数据预处理、检索优化、生成改进等关键环节
文档解析与清洗
智能分块策略
按学习路线查看教程、项目和面试题。
多路召回
| 召回通道 | 适用场景 | 实现方式 |
|---|---|---|
| 向量检索 | 语义相关 | 领域微调Embedding + HNSW索引 |
| 关键词检索 | 精确匹配 | BM25 + 领域同义词扩展 |
| 结构化检索 | 条件过滤 | 元数据标签（时间、版本、文档类型） |
重排序与精排
上下文工程
生成策略
场景切入
我看你做过电商客服系统，假设用户问“我的订单为什么还没发货”，我们得从商品、物流、政策多个文档里找答案。你会怎么设计一个RAG系统来搞定这种多源检索和准确生成？
层层追问
专业领域的问答系统，你一般怎么从文档里找答案？……那如果文档格式很乱，有PDF、表格、条款呢？……检索出来一堆结果，怎么挑出最相关的？……最后生成时怎么避免幻觉，还能让用户信服？
直球架构
请直接设计一个面向专业领域的RAG系统架构，重点讲数据预处理（解析、分块、质量过滤）、检索优化（多路召回、重排序）和生成改进（上下文压缩、引用溯源）三个环节的具体方案。
这道题其实问的是，当你要把一个专业领域的[[RAG]]系统真正用起来的时候，你到底要解决哪些工程问题。不是搭积木，是系统工程。我重点讲几个环节。先说数据预处理。很多团队上来就[[分块]]，但专业文档最大的坑是结构丢失。比如法律合同里的条款层级、表格里的数值对应关系，如果纯文本切碎，后面检索就找不准。我的做法是，先用专门的解析器把PDF、Word这些格式统一处理，保留标题层级和表格结构，再做[[实体链接]]和指代消解，比如把“本协议”替换成具体合同名。分块策略上，我倾向语义分块加结构感知，按章节切分，同时保留父子关系，这样递归检索时能拿到上下文。还有一个细节，我会对同一内容生成256、512、1024三种粒度的chunk，适配不同查询深度，短查询用细粒度，长查询用粗粒度。当然，这么做的前提是你的存储和索引能撑住多粒度冗余。再说检索。我一般不做单一召回，而是[[混合检索]]：向量检索抓语义，关键词检索抓精确匹配，比如订单号、错误码这些必须精确命中。结构化检索用来过滤元数据，比如只查某个时间段的文档。你问向量和关键词怎么选？其实看场景：语义相关用向量，精确匹配用关键词，真正落地是两条路一起走。检索完还有[[重排]]，我用领域微调的[[交叉编码器]]做精排，同时引入用户反馈信号，比如点击停留时长，做在线学习。这里有个坑：如果领域数据量不够，微调[[Embedding]]和重排器效果反而会变差，所以我会先评估数据量，不够就先用通用模型加少量领域样本做快速适配。生成层，我重点做两件事。一是上下文工程，根据问题复杂度动态调整top-k，复杂问题用递归检索扩展上下文，同时强制生成时标注来源chunk_id，方便验证。二是生成策略，领域Prompt模板定义输出格式，比如法律场景必须精确引用法条。还有一个关键：当检索置信度低时，我不让模型硬生成，而是触发“需补充信息”话术，避免[[幻觉]]。简单说，我宁可不答，也不错答。评估闭环我会做两层：离线用Recall@K和答案相关性，用LLM-as-judge打分；在线看用户满意度和答案采纳率，人工标注badcase回流。持续更新上，增量索引加版本管理，支持数据回溯。其实还有一个更前沿的方向，就是让模型在生成过程中主动判断是否需要额外检索，比如用[[Self-RAG]]或者[[Agentic RAG]]，这样能减少无效检索，但实现复杂度高，需要平衡延迟和效果。