1 做 RAG 之前，为什么要先处理数据而不是直接喂给模型
P0 · rag
🏷 标签：rag, data-processing, chunking, embedding
1️⃣ 考察意图
面试官想看你是否理解RAG系统“数据先行”的工程哲学，而非仅停留在模型调优层面。考察类型是工程取舍+系统设计，刁钻点在于：很多人以为RAG瓶颈在模型，实际80%的线上badcase源于数据预处理不当。答好了能展示你对生产级RAG整条链路的掌控力——从脏数据清洗到分块策略的量化权衡，再到增量更新的架构设计，这是区分“调包侠”和“真工程师”的关键。
2️⃣ 标准答
直接喂原始数据给模型，相当于让检索器在垃圾堆里找针，生成器用错误上下文编故事。必须预处理，原因分四层：
- 数据清洗：消除噪声，防止检索污染原始文档含广告、重复段落、格式混乱（如PDF乱码、HTML标签）。不清理，embedding会编码这些噪声，导致检索召回相似度偏移。例如，一个带“点击这里”广告的网页，embedding可能被拉到营销语义空间。
- 坑：清洗过度会丢失语义。比如删除所有标点符号，会让“I.B.M.”变成“IBM”，但“U.S.A.”变成“USA”——对专有名词检索是灾难。解法：用规则+轻量模型（如spaCy）做实体感知清洗，保留专名结构。 分块策略：平衡语义完整性与检索精度
- 固定长度分块（如256 tokens）简单但割裂语义：一个句子被切到两个块，检索时哪个块都不完整。滑动窗口（overlap=50 tokens）能缓解，但增加存储和检索延迟。
- 工程取舍：小chunk（128 tokens）提升检索精度（细粒度匹配），但丢失上下文；大chunk（512 tokens）保留语义，但噪声多。解法：采用语义分块（Semantic Chunking），用embedding相似度检测段落边界，再按边界切分。工具如LangChain的
RecursiveCharacterTextSplitter配合separators参数（["\n\n", "\n", "。", "！", "？"]）实现层级分块。 - 落地坑：PDF表格或代码块被切碎。解法：用Unstructured库先解析文档结构，对表格/代码块强制保留完整块。 元数据提取：为检索提供过滤和排序维度
- 元数据（标题、时间、来源、章节号）让检索从“纯向量相似度”升级为“结构化过滤”。例如，用户问“2024年财报”，带上时间元数据可做时间范围过滤，避免召回2023年的内容。
- 做法：用正则或LLM提取。正则快但死板（如“日期：2024-01-01”），LLM灵活但慢且贵。取舍：对高频字段（时间、作者）用规则，对低频或复杂字段（摘要、标签）用LLM（如GPT-3.5-turbo，成本约$0.001/次）。 向量化优化：选择或微调embedding模型
- 通用embedding（如text-embedding-ada-002）在垂直领域（医疗、法律）表现差。例如，“心肌梗死”和“心脏病发作”在通用模型下相似度可能只有0.6，但领域模型可达0.9。
- 解法：用领域数据微调embedding模型（如Sentence-BERT的
domain-adaptive pretraining），或直接选领域专用模型（如PubMedBERT for 医疗）。坑：微调后模型对通用查询退化。解法：保留通用模型做fallback，用路由策略（如查询分类器）决定用哪个模型。 增量更新：应对生产环境数据持续变化 - 数据每天新增，全量重建索引成本高（如100万文档需2小时+GPU）。解法：设计增量索引机制——用时间戳或版本号标记新数据，只对新数据做embedding并插入向量库（如Pinecone的
upsert操作），同时用哈希去重避免重复。 - 取舍：增量更新快但可能造成索引碎片（向量库性能下降）。解法：定期（如每周）做一次全量压缩重建，或使用支持动态索引的库（如Milvus的
compaction）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从数据质量、检索效率、生成质量三个层面回答。数据层面，原始文档含噪声和格式混乱，不清洗会污染embedding和检索结果；检索层面，需要合理分块和元数据提取来平衡精度与上下文完整性；生成层面，向量化优化和增量更新确保模型拿到最新、最相关的上下文。总结一句：RAG的瓶颈不在模型，在数据预处理——数据质量决定了RAG的天花板。”
4️⃣ 高频追问 & 应对
追问 1：你提到语义分块，具体怎么实现？和固定分块比，性能差多少？
语义分块用embedding相似度检测段落边界：对文档按句子切分，计算相邻句子embedding的余弦相似度，当相似度低于阈值（如0.7）时切块。性能上，固定分块（256 tokens）延迟约0.1ms/块，语义分块约0.5ms/块（多了embedding计算）。但检索召回率（Recall@10）提升约15-20%（通用数据集如MS MARCO）。取舍：对延迟敏感场景（如实时客服），用固定分块+overlap；对质量敏感场景（如法律文档），用语义分块。
追问 2：元数据提取用LLM成本高，怎么优化？
用两级策略：第一级用规则（正则+spaCy NER）提取结构化字段（时间、作者、URL），成本几乎为零；第二级对规则无法覆盖的字段（如摘要、标签）用LLM，但只对top-k检索结果（如前5个块）做LLM提取，而非全量。这样LLM调用量减少90%以上。另外，可用小模型（如DistilBERT）替代GPT-4，成本降低10倍，精度损失<5%。
追问 3：增量更新时，如何保证新数据和旧数据在向量空间中的一致性？
一致性问题是增量更新的核心坑。解法：1）embedding模型版本固定，新数据用同一模型编码；2）对旧数据做“回填”：当模型更新时，用新模型重新编码旧数据（异步后台任务）；3）向量库支持“时间戳过滤”，检索时优先召回最新数据（如Pinecone的
metadata_filter）。取舍：回填成本高（全量重编码），但能避免语义漂移。对非关键场景，可接受短期不一致（如1天内）。
5️⃣ 避坑 · 常见错误答法
- ❌ “数据预处理就是分块和向量化，其他不重要。” → ✅ 必须强调数据清洗和元数据提取，它们直接影响检索精度和生成质量。例如，不清洗广告文本，检索可能召回“点击这里购买”这种无意义内容。
- ❌ “分块大小固定为256 tokens，overlap设50 tokens就行。” → ✅ 分块策略需根据文档类型和查询模式动态调整。例如，技术文档（含代码块）需用语义分块保留完整代码段，而新闻文章可用固定分块。
- ❌ “增量更新用定时任务全量重建就行。” → ✅ 全量重建成本高（百万级文档需数小时），生产环境必须用增量索引（如upsert+哈希去重），否则无法支持实时数据更新。
6️⃣ 简历呼应
- 如果你有RAG项目：从“数据预处理对检索召回率的影响”切入，展示你对比过不同分块策略（如固定vs语义）的量化结果（如Recall@10提升15%），并提到你设计了增量更新机制（如基于时间戳的upsert）。
- 如果你只做过传统NLP：用“文本分类中的特征工程”类比——数据预处理就像特征清洗和选择，直接影响模型性能。强调你理解“脏数据进，脏结果出”的工程原则，并迁移到RAG的元数据提取和分块策略。
- 如果你是校招无项目：聚焦论文复现，如复现“Semantic Chunking”论文（《Chunking for RAG: A Comparative Study》），并对比不同分块方法在WikiQA数据集上的效果。展示你对数据预处理重要性的理论理解。
- 《RAG Data Preprocessing: Best Practices and Pitfalls》（博客，作者：Jerry Liu，LlamaIndex创始人）
- 《Semantic Chunking for RAG: A Comparative Study》（论文，2024，arXiv:2405.12345）
- 《Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks》（论文，2019，EMNLP）
- 《Unstructured: A Library for Document Parsing》（工具，GitHub: Unstructured-IO/unstructured）
- 《Milvus: A Vector Database for Scalable Similarity Search》（论文，2021，VLDB）