面试题 · 文档处理
搜索「检索」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
请详细说明在检索增强生成（RAG）系统中，从原始文档输入到向量索引构建的完整数据处理流程，包括文档清洗、文本分块、嵌入模型选择与向量化、向量存储及索引优化等关键步骤，并解释各环节的设计考量与常见实践。
核心目标：保留有效语义，消除格式干扰
| 策略 |
|---|
学习内容与项目面试，在同一条路上。
| 原理 |
|---|
| 适用场景 |
|---|
| 注意点 |
|---|
| 固定长度 | 按token/字符数切分，带重叠窗口 | 通用场景，实现简单 | 固定长度与重叠窗口都只作为候选配置，具体大小由文档结构、Embedding输入限制和同一评测集上的证据完整率、召回与成本共同决定 |
| 递归分块 | 先按段落/句子边界，再递归细分 | 结构清晰的文档 | 优先保证语义边界完整 |
| 语义分块 | 用Embedding相似度检测主题变化 | 长文档、多主题混合 | 计算成本高，可用聚类或BERTopic辅助 |
关键考量：块太小→上下文丢失；块太大→检索精度下降、Embedding稀释。实践中常组合使用，如先按标题分章节，再语义细分。
存储选型：
索引优化实践：
建立端到端评测：用真实query测试检索Top-K命中率，结合LLM评估生成质量，反向驱动分块策略、Embedding微调、索引参数调优。
建议先掌握RAG整体架构，再分步学习数据清洗、分块策略和嵌入原理，结合开源工具如LangChain和FAISS动手实践，加深理解。
场景切入
假设我们搞一个电商客服知识库，给用户上传了一堆PDF产品手册，你准备怎么把这些乱七八糟的PDF变成能让机器人快速检索的向量索引？从原始文件开始一步步说。
层层追问
RAG系统里，文档进来后你是怎么处理成向量的？……比如PDF里一堆页眉页脚、表格，怎么去掉噪声？……分块时你一般按什么逻辑切，切多大？为什么？
直球架构
请完整描述从原始文档到向量索引的构建流程，重点说文档清洗、分块策略、嵌入模型选型、向量存储和索引优化，每个环节讲讲你的设计考量和常见做法。
这道题问的是从原始文档到向量索引的完整 pipeline，其实本质是在问：怎么把非结构化的业务文档转成机器能高效检索的向量表示，同时保证精度、成本和实时性的平衡。我直接说下我通常怎么落地的。
先说文档清洗。这一步很多人容易忽略，但实际踩坑最多。比如处理企业 SOP 或合规文档，PDF 转文本经常带出页眉页脚、乱码、跨页断句，直接送进去[[分块]]，检索时就会匹配到 "版权所有" 这种噪声。先按文件类型选解析器：PDF用PDF解析/OCR工具，DOCX等受支持格式可用Pandoc；Pandoc原生不能把PDF当输入。保留章节、表格与来源，抽检版面和字段。这里有个坑：如果文档里有图片或图表，纯文本提取会丢掉关键信息，比如客服场景里的退款流程图，我可能会用[[多模态]]模型比如 [[OCR]] 或者 VLM 把图转成描述文本再拼回去。元数据也很重要，比如文档来源、时间戳，后面做过滤和 [[Rerank]] 时能用上。
接下来是分块。这个环节核心是平衡上下文长度和检索精度。固定长度分块最简单，但 chunk size 与重叠窗口都只能先作为候选变量。更稳妥的做法是结合文档结构提出几组配置，再用同一评测集比较证据完整率、召回、延迟和索引成本。遇到长文档或者多主题混合的内容，固定切分会把一句话砍成两半，或者把两个不相关的段落拼在一起。更实际的做法是组合策略：先按标题或段落边界粗分，保证语义完整，再对超长的块用递归分块细分。举个例子，处理商家满减政策文档，一个章节讲满减规则，另一个讲退款例外，按标题分就能天然隔开。过小的块可能缺上下文，过大的块可能混入多个主题或超出模型输入；没有通用50/1000 token门槛，“稀释”也不是小块的必然结果，应按证据完整率、召回和成本实测。具体参数我一般根据业务数据试跑，用 [[RAGAS]] 的 [[Context Precision]] 指标调优。
说下 Embedding 模型选型。可将BGE-M3或具体多语言E5型号列为候选；先核对语言、最大长度和query/document用法，再测目标任务，不沿用动态榜单口号。如果是垂直领域，比如法律合同，直接用通用模型可能效果不好，我会用领域数据微调，或者用 LLM 生成合成数据训练。部署时有个前提：模型推理延迟必须可控。如果 QPS 高，我会用 ONNX 转成 FP16 量化，batch 推理，或者用Product Quantization压缩向量编码存储；PQ不等于降低原向量维度。另外，如果文档包含图片和文字混合，比如产品说明书，可比较ColPali等视觉文档检索或具体Jina-CLIP型号。原始ColBERT是文本late interaction，不能仅凭ColBERT名称当作图文模型。
向量存储和索引这块，我习惯按规模选型。小数据量比如几百万以下，直接 [[Faiss]] Flat 做精确搜索，简单可靠。中等规模用 [[IVF]] 加 [[HNSW]]，平衡速度和召回。大规模比如上亿，会用 Milvus 或者 Pinecone。落地风险主要在增量更新：知识库频繁增删改时，直接重建索引成本高，但增量插入如果处理不好，召回会崩。我的做法是把更新分成新增、修改、删除三类。新增直接走 HNSW 的增量插入；删除不做原地删除，而是维护一个删除标记，后台异步重建索引。上线前会用固定 query 回放，对比 Recall@K 和延迟，通过才原子切换，不通过就回滚。
还有一个方向值得深入，就是[[混合检索]]。单纯用向量检索，遇到订单号、错误码这种精确匹配场景召回很差，因为 Embedding 对精确 token 不敏感。我会结合 [[BM25]] 做[[稀疏检索]]，然后用 Hybrid Search 融合分数，或者用 ColBERT 的 late interaction 做二阶段精排。这其实引出一个问题：稠密和稀疏向量怎么融合、权重怎么调，才能在不同业务场景下都稳定？
所以整体来看，我不会把这条 pipeline 看成固定流程，而是每次根据业务场景做取舍。比如客服退款场景，我更关注实时性和高召回，那分块就偏小、索引用 IVF 快查；如果是法律文档，更关注精度，那分块偏大、用 HNSW 加重排。关键是建立端到端评测闭环，用真实 query 跑一遍，看 Top-K 命中率和生成质量，反过来调分块和索引参数。