完整题目
请详细阐述构建大模型知识库的完整流程，包括数据收集、清洗、向量化、索引构建等关键步骤。
本文目录
答案要点
- 数据收集策略与来源选择
- 数据清洗与质量评估方法
- Embedding模型选型与微调
- 向量索引结构选择（HNSW/IVF）
- 检索策略优化（重排序、混合检索）
- 知识库更新与维护机制
一、数据收集阶段
来源分类
- 结构化数据：数据库、API、Excel表格
- 非结构化数据：PDF、Word、网页、聊天记录
- 半结构化数据：Markdown、JSON、XML
关键原则
- 优先收集高频查询场景的数据
- 建立数据版本管理和溯源机制
二、数据清洗与预处理
核心步骤
- 格式统一：PDF转文本（处理扫描件需OCR）、HTML去标签
- 噪声过滤：去除页眉页脚、广告、重复内容
- 语义分段：
- 按主题或段落切分，长度作为候选变量，由文档结构、模型输入限制与评测结果决定
- 比较零重叠、短窗口与较长窗口，用同一评测集验证是否减少信息割裂
- 质量评分：用规则+小模型过滤低质量片段
三、向量化（Embedding）
模型选型
| 场景 | 推荐模型 |
|---|---|
| 通用中文 | BGE-M3、GTE、ERNIE |
| 垂直领域 | 领域数据微调后的模型 |
| 多语言 | E5-mistral、BGE-M3 |
优化技巧
- 对Query和Document分别设计Prompt前缀（如"为这个句子生成表示："）
- 领域微调：用对比学习（In-batch Negatives+Hard Negatives）提升相关性
四、索引构建
向量索引
- HNSW：高召回、内存占用大，适合百万级
- IVF-PQ：磁盘友好，适合亿级规模
- Milvus/Pinecone：托管方案，自动分片
增强索引
- 稀疏向量：BM25倒排索引，与稠密向量做混合检索
- 元数据过滤：按时间、来源、标签预过滤
五、检索与优化
检索流程
Query → Embedding → 向量召回Top-K → 重排序（Cross-Encoder） → 精排Top-N关键优化
- 查询改写：用LLM扩展同义词、纠错
- 多路召回：向量+关键词+图谱并行
- 重排序：轻量Cross-Encoder（如bge-reranker）提升相关性
六、持续维护
- 增量更新：新数据单独建索引，定期合并
- 失效检测：监控检索点击率，自动标记低质量片段
- 反馈闭环：收集用户点击/满意度，迭代Embedding模型
换一种问法，检查是否真正理解
场景切入
假设你们要给客服系统搭一个知识库，用户问“怎么退换货”，你得从一堆文档里找到答案。你先说说，从收集数据到能真正用，整个流程你会怎么做？
层层追问
建知识库第一步是拿数据吧，你一般从哪里找？……拿到之后怎么处理才能让检索效果好？……向量化你用什么模型？……索引怎么建才能查得快？
直球架构
请完整描述构建大模型知识库的流程，包括数据收集、清洗、向量化、索引构建这几个关键步骤，每个阶段你具体怎么做？
练习口述回答 · 约4分钟
- 知识库构建本质是检索质量工程
- 数据清洗的坑与语义切分
- Embedding选型与混合检索
- 索引结构与重排序取舍
- 维护与反馈闭环
这道题问的是知识库构建，但我觉得面试官真正想听的，是你知不知道一个知识库从数据到检索的完整链路里，哪些环节会出问题、怎么取舍。说白了，这不是一个搭积木的流程，而是一套检索质量工程。
先说数据收集。很多人一上来就想着把PDF、数据库、网页全塞进去，但真正落地的关键是优先收集高频查询场景的数据。比如做客服退款知识库，你先把退款流程、常见纠纷、政策规则吃透，而不是把整个公司ERP文档都丢进去。而且一定要做版本管理和溯源，不然改了一个政策，旧版本还在库里，检索出来就出事了。
接下来是清洗和切分。这一步的坑比想象中大。格式统一是基本功，PDF扫描件要[[OCR]]，HTML去标签。但最难的是噪声过滤，页眉页脚、广告、重复内容，这些不干掉，[[向量化]]之后全是噪声。还有语义切分，很多人用固定长度256token一刀切，但业务场景里一个完整退款流程可能跨好几个段落，切碎了检索召回就断章取义。我倾向先按主题或章节自然边界做语义切分，再把零重叠、短窗口与较长窗口作为候选，用同一评测集验证边界证据是否完整。另外，数据质量要有个门槛，用规则加小模型打分，分数太低的片段直接丢掉，不然就是垃圾进垃圾出。
然后说Embedding选型。通用场景用BGE-M3、GTE这些没问题，但垂直领域一定要微调。比如金融合规文档，很多专业术语和上下文，通用模型根本抓不住。微调用对比学习，加In-batch Negatives和Hard Negatives，让模型学会区分相似但不同的条款。这里有个关键点：Query和Document要加不同的Prompt前缀，比如查询是'为这个句子生成表示'，文档是'为这段文本生成表示'，这样向量空间更对齐。
索引构建，我一般不走极端。[[HNSW]]召回率高但吃内存，适合百万级；[[IVF-PQ]]磁盘友好，适合亿级。真正落地常常是**[[混合检索]]**，稠密向量加[[BM25]]稀疏向量，再配合元数据过滤，比如按时间、来源预过滤。比如搜索'2024年退款政策'，先按时间过滤出2024年的文档，再向量召回，效率和精度都高。
检索优化里，我特别看重**[[重排序]]**这一步。向量召回Top-K后，用轻量[[Cross-Encoder]]比如bge-reranker做精排，能显著提升相关性。但代价是延迟，所以得权衡。另外，查询改写也很有用，用户输入'退款怎么还没到'，LLM可以扩展成'退款到账时间、退款流程、退款进度查询'，提高召回率。
最后说维护。知识库不是建完就完了，数据会变、用户query会变。我一般做增量更新，新数据单独建索引，定期合并。但有个坑：删除操作不能原地动图索引，否则召回质量会崩。我倾向软删除加后台异步重建，用base加delta双索引，查询时合并。上线前用固定query回放，对比Recall@K和延迟，通过才原子切换。