企业官网建设流程全解析

做知识库问答，最怕的不是模型不够聪明，而是想找一个文档却怎么也搜不到。RAG知识库方案这些年之所以被大厂面试官普遍认可，核心就一句话：让模型先检索、再回答。今天我从文档处理讲到精准检索，把整套可落地的做法细讲一遍，照着做能少踩很多坑，也方便你拿去应付技术面试。

这套方案适合三种人：一是正在做企业知识库、私域问答系统的研发，二是准备大模型应用岗位面试、想补全RAG知识栈的人，三是刚接触RAG、不知道从文档到检索每一步具体怎么设计的新手。下面内容全部是我实际验证过的做法，不吹不黑，按着顺序推进就好。

1. RAG知识库到底在解决什么问题

1.1 先搞清楚边界：RAG不是万能药

很多人一上来就聊模型、聊向量库，其实没想清楚业务痛点。RAG知识库适合的场景非常明确：回答内容依赖特定私有文档，并且答案需要可溯源。比如企业规章制度问答、产品说明书客服、科研文献辅助阅读、内部系统操作手册。

不适合的场景也不少：需要多轮复杂推理的数学题、需要实时更新的行情数据、核心数据尚未结构化且存在大量敏感字段的场景，指望纯RAG硬扛基本都会翻车。面试官问你RAG的边界，就看你有没有这个意识。

一组容易混淆的概念要区分开：RAG（检索增强生成）、Fine-tuning（微调）和长上下文。长上下文模型可以一口气读完很多内容，但消耗大、响应慢、定位困难；微调改变的是模型行为和风格，不是给它塞知识库；RAG是在推理时动态获取相关资料，天然支持知识更新、权限控制、引用溯源。明白了边界，后面所有设计才有方向。

1.2 整体流程概览

一个完整的RAG知识库方案，大致分五个环节：

1. 文档接入与解析：把PDF、Word、Markdown、HTML、扫描件转成干净文本。
2. 文本切分：把长文档切成长度合适、语义完整的切片。
3. 向量化与索引：用Embedding模型把切片转成向量，写入向量数据库，同时建立关键词倒排索引。
4. 查询与召回：对用户查询做改写、路由，通过向量召回加关键词召回得到候选切片。
5. 重排与生成：用Reranker精排，把高相关切片拼进Prompt，由大模型生成带引用的答案。

这五步每一步都有大量细节，最能拉开方案差距的其实是前三步。后面我挨个讲。

2. 文档接入与解析：太多项目在这里翻车

2.1 先做输入类型摸底，再选解析器

上来就写代码是常见错误。我先做一次文档摸底，统计格式分布、页数、字体嵌入情况、是否有扫描页。不同格式的解析策略完全不同：

• Markdown / HTML / JSON：直接结构化提取，注意去掉导航、脚本、广告位。
• Word（docx）：可以用文档解析库直接读取段落，表格要单独提取，不要混进正文段落里。
• PDF：分两类处理。文本型PDF直接抽取文本与布局，扫描型PDF必须走OCR。
• 表格型文档：统一转成Markdown表格或键值对，别把单元格内容拼成没有语义的长句。

我见过一个项目把PDF表格直接解析成纯文本，结果召回时把表头和值拆得七零八落，用户问“上个月销售额”时模型只能答非所问。正确做法是每张表格保留表头关系，必要时转成JSON格式再入库。

2.2 清洗规则比想象中重要

很多人忽略清洗，结果检索阶段被脏数据坑惨。清洗规则我按优先级整理如下：

• 去除页眉页脚、页码、水印、导航文本，否则每个切片里都有重复片段。
• 统一全角半角，处理乱码字符，特别是从PDF复制出来的空格和曲线换行。
• 修正错误断行：PDF里经常一句话被拆成多行，需要按标点符号和语义合并。
• 去除无意义内容：广告、免责声明、版权声明、重复报错信息。
• 超链接转成标题加URL，不要直接丢链接原文。

清洗完之后要做一轮人工抽检，拿10到20个样本跟原文比对，确认没有被误删关键内容。这一步看似不性感，却直接影响后面所有环节的上限。

2.3 扫描件与特殊版式的处理

扫描版PDF必须走OCR，选型时优先考虑支持版面分析的工具，能识别标题、正文、表格区域的那种。做完OCR之后别急着入库，先跑一遍拼写纠正和行拼接，因为OCR结果里的断行比较乱。

遇到多栏排版，核心是保持阅读顺序，不能按物理坐标从左到右切，要从上到下按块阅读。数学公式我一般单独标记成文字表达式或图片占位符，不做强语义解析，因为公式向量化效果本来就差。代码片段则按语言保留缩进和注释，用专门的代码块切分策略。

3. 文本切分：最影响检索上限的环节

3.1 四种切分方式怎么选

• 固定长度切分：最简单，按字符数切，但容易切断语义。
• 递归字符切分：按段落、句子、标点逐级切，是通用场景最稳的选择。
• 结构化切分：按Markdown标题、HTML标签切分，适合有明确结构的文档。
• 语义切分：借助Embedding或模型判断语义边界，效果上限高，但成本高、速度慢。

我的建议是默认走结构化加递归兜底。先看文档有没有天然标题结构，有就按标题块切；遇到长段落时再按句子递归切。

3.2 chunk size和overlap的确定方法

这里给一组我实践过多次的初始值：Embedding模型是768维时，普通业务文档建议chunk_size取500到800字符，overlap取50到100字符。但最终值必须按评估结果调，不要迷信固定值。

为什么需要overlap？因为句子之间有指代关系，比如前一段末尾说“这个方法”，后一段才有具体解释。没有重叠就会把上下文切断。切分之后我还会做一道后处理：切片尽量以句号或换行结尾，不要从句子中间硬切。

判断切分质量有一个很土但有效的方法：随机抽20个切片，自己读一遍，看每段是否表达了一个相对完整的意思。如果超过一半切片读起来没头没尾，就说明切小了或切歪了。

3.3 父子块与小标题索引

法规、技术文档这类层级很强的文本，我常用父子块方案：父块对应一个章节，子块对应段落，子块负责召回，父块负责拼接进上下文。这样既保证定位准确，又让模型能看到全局信息。

还有一种做法是给每个切片额外打标题标签，比如“第一章-安装说明”，检索之后先按标题粗筛，再在标题内做细排。对于层级感强的文档效果很显著。

4. 向量化与检索：从“能查到”到“查得准”

4.1 Embedding模型选择经验

选型前先明确几件事：需要中文支持还是多语言，文本切片的平均长度是多少，预算能接受多大模型。

中文场景建议优先考虑针对中文优化的Embedding模型，向量维度通常在768以上维度。英文场景可选范围更广。判断模型好不好，不要只看口碑，拿自己业务里的100条真实问题加对应文档跑一遍召回，直接看排序效果。

还有几个坑：一是切片太长时部分模型会截断，要先确认模型max_token限制；二是向量归一化问题，用余弦相似度时统一做归一化，避免后面索引精度出错；三是模型更新之后要重新embedding全量数据，线上库新旧向量混用会导致检索质量飘忽。

4.2 向量数据库选型与索引设计

选向量数据库主要看三件事：数据规模、实时写入频率、是否需要标量过滤。我整理过一张对比表，供参考：

索引和分片设计上，常见的选择是HNSW类索引。参数里M值影响内存和召回率，efConstruction影响构建速度，实际项目要按数据量压测。这里要格外关注“ID映射”问题，业务ID、向量ID、切片内容三者必须能互相反查，不然定位不到引用来源。

4.3 混合检索与Rerank

只用向量召回，同义改写常常会漏。比如用户问“薪资怎么算”，文档里写的是“工资核算”，向量相似度未必高。所以线上必须混合检索：向量召回负责语义泛化，BM25类关键词召回负责精确匹配，两者取并集或加权融合，再做精排。

精排阶段使用Reranker模型，输入是用户问题和候选切片，输出相关性分数。这里要注意，Reranker的耗时比向量检索高不少，候选集一般控制在50到200条，精排保留前5到10条。我的融合策略是先按分数归一化，再做加权求和，权重先取关键词0.3、向量0.7，然后根据线上反馈调节。

5. 完整查询链路与工程落地

5.1 查询改写与路由

用户输入“它怎么设置”这种带有指代的句子，直接拿去检索基本搜不到。我习惯在检索前加一步查询改写，把指代补全。代价是增加一次模型调用，但换来召回率提升。

更复杂的场景还要做路由，比如区分制度类问题、操作类问题、闲聊类问题。路由到不同知识库甚至不同处理逻辑，能避免“拿文档检索结果回闲聊”的尴尬。路由判断当前也可以用模型做，但简单规则可用时，尽量避免过度引入模型调用。

5.2 Prompt与上下文组织

上下文组织有两点容易踩坑。第一，候选切片顺序不能简单按相关分排列，而是按原文逻辑顺序排列，避免模型读到逻辑倒置的内容，生成时越说越乱。第二，上下文长度要控制在模型输入上限的50%到70%，留出生成空间，也避免长文本注意力分散。

Prompt结构我常这么写：

• 开头：说明身份和任务，限定只能基于资料回答。
• 中段：按编号列出切片内容，保留来源标题。
• 结尾：说明回答规则，包括不知道就承认、必须引用切片编号。

引用必须做到可溯源，这是RAG比裸模型天然更有优势的地方，千万别丢掉。

5.3 缓存、并发与流式输出

线上RAG服务除了效果，还要看稳定性和延迟。缓存策略上，相同或相似查询直接命中缓存结果，既能节省模型费用，又能把响应时间从秒级降到毫秒级。相似度缓存常用向量相似度作为判据，需要设置一个不太容易误伤的阈值。

并发控制上，模型网关要做连接池和限流，避免用户同时提问时把后端打满。长文档召回链路尽量做并行调用，查询改写、向量检索、关键词检索三路并发，能省掉不少耗时。流式输出对体验提升极大，首token延迟要重点监控，如果每次都要检索完再吐字，用户会以为系统卡住了。

6. 评估体系：没有量化就无法持续优化

6.1 用业务真实问题搭建评估集

我见过很多团队上线RAG后不做评估，全靠感觉调参，这是最危险的做法。正确的第一步是建立评估集，数量不用太多，100条高质量问题可以覆盖大多数场景。每一条包含三部分：用户问题、对应参考答案、命中的参考文档段落。

评估集来源有两个渠道：线上真实用户日志去掉敏感信息后归纳，以及业务方提供的典型问题清单。注意覆盖度，简单查询、模糊查询、跨文档问题、否定表达问题都要有。

6.2 线上可观测与回归流程

每次修改切分策略、换Embedding模型、调召回参数，都要在评估集上跑回归。我通常记录三个维度的指标：

• 检索质量：召回率、命中率、MRR。
• 生成质量：忠实度、答案相关性、引用准确率。
• 系统性能：延迟、首token时长、超时率、成本。

忠实度尤其重要，它的含义是答案是否严格基于检索到的上下文，没有编造。我实际排查时经常发现，模型会自作主张补一些常识性内容，看起来合理但知识库里根本没有，这类问题必须通过Prompt约束和检索质量双重压制。

6.3 一个简易的召回率统计脚本

回归测试时，我习惯用一个简单脚本读取测试集，对每个问题跑一遍召回，再判断命中的文档段落是否在召回候选里。核心逻辑大致如下：

def calculate_hit_rate(test_cases, retriever, k=5): hit = 0 total = 0 for case in test_cases: query = case["query"] ground_truth = case["reference_passage"] # 预期命中的切片ID candidates = retriever.retrieve(query, top_k=k) candidate_ids = [c["chunk_id"] for c in candidates] if ground_truth in candidate_ids: hit += 1 total += 1 return hit / total

这个脚本虽然简单，但比肉眼抽查靠谱得多。每次调参之后跑一遍，数据摆出来，问题在哪里一目了然。

7. 面试高频追问与加分思路

7.1 面试官常追的六个问题

这套方案拿到面试里，有几个追问我几乎每次都会被问到，提前准备好会有优势。

问：chunk大小是越大越好吗？
答法：不是。切片越大，语义越完整，但向量化后主题容易被稀释，召回精度下降，且塞给模型的内容变多、成本变高。具体大小必须结合业务文本长度、Embedding模型能力、评估集结果确定。

问：向量检索和关键词检索怎么融合？
答法：先分别归一化分数，再做加权求和，或使用RRF（倒数排名融合）。权重不是拍脑袋，要通过实验在评估集上调。

问：Embedding模型怎么选？
答法：先看语言支持、效果和成本，再用业务数据做离线召回评测。不要轻信排行榜，自己跑100条真实问题的召回率最关键。

问：切片都召回不准确怎么办？
答法：从三个环节排查，查文档解析是否丢内容，查切分是否切断了语义，查查询改写是否补全了用户意图。

问：回答出现幻觉怎么办？
答法：先看检索到的上下文里是否缺失关键信息，再看Prompt是否明确不允许猜测，最后检查引用机制。

问：知识库更新后线上检索延迟怎么处理？
答法：增量更新切片与索引，而不是每次全量重建；配合版本管理，旧版本继续服务直到新版本验证通过。

7.2 加分的小细节

想拿高分，光把流程背熟还不够。主动聊评估集和回归机制，会让面试官觉得你有工程素养。

我还会刻意提两个细节。一是文档权限：知识库每个切片要带上可见范围标签，检索时过滤权限，避免越权访问。二是数据回流：把线上“答得不好”的问题收集起来，定期补充到评估集和知识库中，形成闭环。这两点能体现你真的上过线，而不只是看过文档。

8. 实操中要避开的几个坑

• 不要一股脑把全部文档入库，先按高频问题圈定首批范围，跑通再扩，不然后续清洗成本爆炸。
• 不要只看MRR或命中率单一指标，召回率提升但答案不忠实，说明上下文组织或Prompt还有问题。
• 不要在评估集缺失的情况下盲目调参，我之前调过一轮参数，表面线上反馈变好，评估集上一跑发现掉点，白白浪费两周时间。
• 不要忽视版本管理，Embedding模型、切分参数、知识库内容都要能回滚。
• 不要把引用信息丢给模型自由发挥，要在Prompt里强制要求对应切片编号，前端才能展示来源。

我在实际项目里最深的一个体会是，RAG知识库真正的分水岭不在模型，而是在于你有没有一套可量化的评估机制。有评估集，你做任何改动都有依据；没有评估集，所有优化都是玄学。

最后分享一个小技巧：把每天线上用户提问后“未点击任何引用”的日志单独存一份，每周筛一次，这些大概率就是知识库的空档区。把这些query聚合归类，就能持续指导文档补充和切分优化，让知识库越跑越聪明。这套方法本身，也是面试时一个不错的实战亮点。