企业官网建设流程全解析

去年有个客户找到我，说想把几百份项目文档做成一个能自动回答问题的内部工具。需求听上去很简单：员工问一句“某系统的部署要求是什么”，工具就给出准确答案。我一开始的想法也很简单，把文档丢给大模型不就行了吗？结果大家应该都能猜到，模型对这类私有内容的了解几乎为零，甚至还敢一本正经地编答案。踩过这个坑之后，我把方案换成了 RAG。RAG 的全称是检索增强生成（Retrieval-Augmented Generation），机制是先从知识库里把相关资料检索出来，再让模型基于这些资料组织回答。这个思路本质上是帮模型“开卷考试”，而不是让它闭卷硬猜。今天想聊的是开源 RAG 这条路径：它到底解决什么问题、核心组件怎么选、完整跑通一个项目要经历哪些环节，以及我在实际项目里记录下来的问题与处理技巧。适合想给企业做知识库、想用私有数据做大模型应用的开发者，也适合刚接触这个领域、想判断要不要投入的技术决策人。

1. 先想清楚：开源 RAG 到底在解决什么问题

1.1 大模型的两道坎：记忆边界与幻觉

大模型不是数据库，更不是企业内部档案员。它的所有知识都来自训练数据，训练数据的截止日期一过，它就“断片”。更重要的是，企业内部大量有价值的信息，比如合同条款、项目复盘、设备参数、历史变更记录，根本不在公开互联网上，模型自然不可能知道。所以你直接问一个没接任何外部资料的大模型“我们去年那条产线的故障处理流程是什么”，它要么说不知道，要么就开始编。这种编造在技术圈子里有个专门的名字叫“幻觉”，本质是模型用语言概率在填空，而不是在检索事实。

我把这个过程类比成单位里来了个新同事：表达能力很强，但入职当天没给他发任何制度文件和项目资料。你问他一个老问题，他又不能说自己不知道，于是只好靠零碎常识给你拼一个“看起来合理”的回答。RAG 要做的，就是给这位新同事发一个可随时翻查的资料夹，让他在回答前先查资料，再开口。

所以 RAG 的关键转换，是让模型从“记住一切”变成“查到哪里、答到哪里”。知识存放在外部知识库，模型只负责语言组织和逻辑推理。这个转换带来两个直接好处：第一，资料可以随时更新，模型不用重新训练；第二，回答可以追溯，每一句都最好能指向某份原始文档。对于知识密集、高频解答的行业来说，这两点极其关键。

1.2 为什么在这个场景下要强调“开源”

同样做 RAG，既可以调用商用大模型的服务，也可以完全基于开源组件搭建。两者的差异不只是价格。

商用方案最大的优势是省心，接口一调就能用，模型能力强，很多细节不用自己操心。但它有两个在私有场景下很致命的问题：第一，数据会离开你的网络边界，企业文档全部要传给外部接口，在合规和数据安全上基本过不了关；第二，链路不可控，检索用的向量模型、排序逻辑、提示词都被封装在别人服务里，你想调整召回策略、想看中间结果、想针对某个行业优化，往往无从下手。

开源方案走的是另一条路：文档解析、分块、向量化、检索、重排、生成、评估，每个环节几乎都有开源组件可以自由组合。整个系统可以部署在自己的服务器上，数据全程不出内网，成本也变成“一次性建设 + 按量运行的机器成本”，而不是按调用次数持续付费。缺点当然也有：没有好用的控制台帮你兜底，日志、监控、失败分析都要自己来做；模型能力确实赶不上顶级商用模型，尤其在长文本理解和复杂推理方面会吃力。

我给一个比较直接的判断：如果你的场景是内部知识库问答、私有文档检索，尤其数据敏感，那开源 RAG 是本值得押注的路线；如果只是做临时演示、对数据安全没要求，商用 API 也许更快。具体怎么选，取决于你手里最重的那块需求是什么。

2. 开源 RAG 的核心组件与选型思路

2.1 文档处理：被低估的第一道关

很多人搭建 RAG 时第一个兴奋点是“模型选谁”，但我在项目里的真实体会是，真正撑起效果的往往是文档处理那一步。知识库里的文件五花八门：Word 排版混乱、PDF 图文混排、扫描件根本就是图片、表格结构复杂，甚至同一份文档里标题层级都不统一。这些内容直接丢进文本块，检索质量会立刻出问题。

文档处理要解决的第一件事，是“把文件变成干净的文本”。PDF 如果本身带文字层，可以直接抽取文本；如果是扫描件，就需要 OCR 识别。表格是个重灾区，直接把表格“拍平”成一串文本，行和列的对应关系会丢失，检索时会得到一堆语义不连贯的碎片。我做表格处理时的做法，是尽量保留 Markdown 表格结构，或者把表格转成自然语言描述句，比如“某设备工作温度范围是零下10摄氏度到50摄氏度，存储温度范围是零下20摄氏度到70摄氏度”。这种完整句式对后续检索和生成都友好很多。

清理文本时还要留意页眉页脚、水印、目录页、重复的版权声明。这些噪声不会帮模型回答问题，只会让检索结果变脏。还有一个容易忽略的细节是文档版本问题：同一份制度文件可能在多个文件夹里存在不同版本，如果不去重，同样的内容会被反复检索到，浪费上下文窗口，还容易给模型造成冲突信息。我的习惯是入库之前先做一轮“文档体检”，统计文档类型、字数、清晰度、重复率。这几个数据出来之后，后续要不要清洗、怎么分块，基本就有数了。

2.2 向量数据库怎么选：别一上来就上重型武器

向量数据库是 RAG 检索侧的货架，负责把文档向量存进去，再按相似度把最相关的片段找出来。开源生态里的选择很多，一些通用搜索引擎也内置了向量能力。我不建议一上来就追新，因为很多项目的数据规模其实就是几百个文档、几十万条片段，这个量级用单机方案就足够，不需要早期就搭集群。

选择时要关注几个硬指标：向量维度、距离度量、索引类型、过滤能力和资源占用。向量维度由嵌入模型决定，常见的是几百到一千多，维度越高，存储和内存占用越大；距离度量常用余弦相似度，适合文本场景；索引类型上，HNSW 在查询速度与精度之间的平衡比较好，配置也相对简单，适合大多数项目。另外，如果以后要支持按部门、按文档类型做过滤，就要确认方案是否支持原生的元数据过滤。

对中小型项目而言，最简单的组合往往是最稳的：数据量不大时，一个单机服务加合适的索引，一点问题都没有。真正要警惕的是“过早分布式”：一个五百万条以内的片段库，真不需要复杂的集群，栈越重，部署和排查成本越高。你自己评估的时候，可以列一张表：数据规模、预期并发、是否要求高可用、运维人力。这四项能回答，选型就不会跑偏。

2.3 嵌入模型与生成模型：搭配是门手艺

RAG 里有两个和模型相关的关键选择：一个负责把文本转化为向量，叫嵌入模型；另一个负责读资料生成回答，叫生成模型。

嵌入模型的职责，是让“语义相似的文本”在向量空间里靠得近，选型直接影响检索上限。给中文文档做项目，如果直接用英文优化的通用模型，检索效果通常不太好；换成在中文语料上训练过的嵌入模型，效果会有肉眼可见的差别。如果知识库扎根于某个垂直领域，比如医疗、法律、代码，最好再找对应领域的嵌入模型做评测对比。注意，查询文本和文档片段必须用同一个模型、同一种方式编码，否则相似度算是白算。

生成模型的选择同样要看场景。开源社区有很多可本地部署的生成模型，从几个 B 参数的小模型到几十 B 参数的大模型都有。小模型灵活、省资源，但复杂推理能力一般；大模型效果更好，但显存和推理延迟会成倍上升。我做项目时的取舍逻辑是：如果知识库本身只涉及固定业务、答案类型相对单一，一个中小尺寸的开源模型配合良好的检索结果，已经能满足绝大多数问题；如果问题偏开放、需要综合多份资料做推理，再考虑更大模型。一条不严谨但很有用的经验：很多 RAG 效果不好的项目，问题不在生成模型不够强，而在检索结果太差。检索回来的片段压根不相关，再强的模型也写不出正确答案。

3. 从零搭一套开源 RAG：完整实操过程

3.1 数据准备与分块策略

这一节讲实操，先说分块。为什么一定要分块？原因有两个：第一，嵌入模型和生成模型都有输入长度限制，很长的文档无法一次编码；第二，如果整篇几十页的文档都塞进上下文，模型不知道该看哪里，生成质量反而下降。所以要把文档切成“有独立含义的小片段”，每个片段未来就是一次检索的候选答案。

分块有三个关键参数：块大小、重叠长度、切分方式。块大小一般以“字符数”或“Token 数”来度量。块太小，一个完整知识点被截断，检索时信息碎片化；块太大，片段内容庞杂，检索精准度下降，还会浪费大模型的上下文长度。重叠的作用是让块与块之间有缓冲，避免某个概念恰好被切在边界上。常见组合是块大小 500 到 800 字符、重叠 100 到 150 字符，但这绝不是万能参数，要根据真实文档结构调整。

我建议动手写代码前，先快速统计你自己的文档特征。如果文档有清晰的标题层级，按标题、按段落分块，效果会显著优于按固定长度硬切。比如在文档里按标题把内容拆成多个小节，每个小节内部再判断是否超长，超长了再智能切割。还有一种做法是按语义切分，本质是算相邻句子之间的相似度，相似度低时就是话题切换点。这类方法效果更好，但计算量更大。下面是最基础的分块示意，适合先跑通再优化：

# 固定长度分块示意 def chunk_text(text, chunk_size=600, overlap=120): chunks = [] start = 0 while start < len(text): end = start + chunk_size chunks.append(text[start:end]) start = end - overlap return chunks

真实项目里我会把分块逻辑包成一个更完整的模块，输入是已经解析好的文档结构，输出是带元数据的片段列表。每个片段至少包含：文本内容、来源文档名、标题、页码、片段序号。有了这些元数据，后面做引用、做过滤都会方便很多。

3.2 向量化与索引构建

分块完成之后，进入向量化环节。这一步要调用嵌入模型，把每个片段编码成向量，然后把向量连同元数据写入向量数据库。批量处理时有个细节：向模型推理服务发请求，不要一次把所有数据全部塞进去，分批处理，处理好一批写一批。否则要么内存撑爆，要么服务超时重试，日志乱成一片。我习惯用批量接口，每批 64 条左右，配合进度日志。

下面是一个示意性的入库流程：

# 向量化与入库示意 batch_size = 64 for i in range(0, len(chunks), batch_size): batch = chunks[i:i + batch_size] vectors = embed_texts([c["text"] for c in batch]) for chunk, vector in zip(batch, vectors): vector_db.upsert( id=chunk["chunk_id"], vector=vector, doc=chunk ) print(f"processed {i + len(batch)} / {len(chunks)}")

这里要注意，查询时使用的嵌入模型必须和入库时完全一致。我见过有人先用某个模型建库，后来换了一个更好的模型，却忘了重新向量化，结果检索效果惨不忍睹。换嵌入模型就代表整库重建，这个过程也应该写成脚本一键执行，避免人工操作遗漏。

还有一个建议：索引里一定要带上原始文本和元数据。很多向量库默认只存向量，但检索后你还要拿原文去拼上下文、展示引用，这时候没有原文就很被动。不要省这一点存储空间。

3.3 检索链路：召回与重排

检索是 RAG 效果的关键，也是最值得花时间调的部分。早年很多示例只做一种检索：把用户问题编码成向量，再从向量数据库里取 Top-K 个相似片段。这在简单场景下够用，但实际项目中很快就会遇到问题。

最典型的问题是“专有名词吃不住”。用户问“系统型号 ABC-123 的故障码 E-04 是什么意思”，向量模型很可能把 ABC-123 和 E-04 这两个关键串给稀释掉，返回一堆语义相近但根本不包含这两个编号的片段。这时候拼关键词检索就很有价值。我用的方案是混合检索：一路走向量检索，一路走关键词检索，比如基于 BM25 的传统检索算法，然后把两路结果合并。合并方式可以使用“倒数排名融合”（RRF），核心思想是看同一个片段在不同路结果里的排名位置，跨路排名都能进前列的，大概率是真正相关的。

混合检索拿到候选片段之后，还有一步推荐做：重排。向量检索看重语义相似，但它分不清一个片段是部分相关还是精确相关。重排模型则会对每个候选片段和用户问题做更精细的交互式打分，把最相关的排到最前。常见做法是先召回 Top-50，再重排取 Top-5 进入生成环节。多花一次模型推理的时间，换来的是生成质量明显提升，这笔账非常划算。

还有个容易忽略的细节：用户问题的“检索形态”，可能和知识库文档的“表述形态”不一致。比如文档里写“离线部署”，用户问“不联网能不能装”。这时候光靠向量相似度可能匹配不到满分。要么演进到查询改写，要么通过合理扩充分块内容来兜底，比如在分块片段里加入同义描述或关键词标签，提升召回面。

3.4 生成链路：让模型学会“看资料说话”

检索结果组织好之后，进入生成环节。生成链路的核心是提示词模板。一个合格的 RAG 提示词模板，至少要包含三部分：身份与任务说明、检索得到的上下文片段、明确的回答规则。

我常用的模板结构大致是这样：

你是一名知识库问答助手。请基于以下资料回答问题。 【资料片段】 {context} 【用户问题】 {question} 回答要求： 1. 优先使用资料中的信息作答，不要补充资料之外的内容。 2. 如果资料中没有答案，直接回复“根据现有资料无法回答”，不要编造。 3. 回答末尾列出信息对应的资料编号。

这里容易被忽略的，是“如果资料中没有答案”这一条。不加这句话，模型倾向于从自己的“知识库存”里找补，一找补，幻觉就来了。加了你还要在程序里做兜底：如果检索后相关度分数过低，或者返回片段为空，就明确告诉用户“没有找到相关资料”，不要硬着头皮让模型答题。

上下文组织也有讲究。我建议把 Top-K 个片段按相关度从高到低拼接，在上下文里给每个片段加一个编号和一个明确的来源标签，比如文档名、页码。这样不仅方便模型引用，也方便最后把回答里的来源解析出来提供给用户。如果上下文太长，宁可减少片段数量，也不要让模型淹没在无关信息里。

3.5 一版比较稳的开源组合参考

这里给出一个目前实践下来比较稳的“最小可用组合”。它绝不是唯一答案，但适合作为起点：

按这套配置，哪怕个人服务器也能跑通一个演示级系统。数据量上来之后，再把重排、混合检索、监控逐步加进去。不要一开始就把系统搞成微服务网格，很多项目都是死在了过度设计上。

4. 常见问题与排查实录

4.1 答非所问：问题很可能在检索，而不是在生成

用户反馈“回答完全不在点子上”时，我第一步不是调提示词，而是去看检索结果。把用户问题输入系统，把召回的 Top-5 片段原样打印出来，人工看一遍这些片段到底相不相关。如果片段本身就不相关，那再好的生成模型也只能“无中生有”；如果片段相关但答案不好，那才是生成链路的问题。这个排查顺序基本百试百灵。

有一次排查到最后，发现是问题问得很口语化，而文档里都是书面术语，纯向量检索匹配不到。解决办法很简单：加了关键词混合检索，顺便在索引片段里补充了一些同义词标签，效果立刻提升。所以我会在项目里配置一个“诊断模式”，一键输出“用户问题 + 召回结果 + 重排结果 + 最终回答”。这个模式在排障时节省了大量时间。

4.2 分块总调不好：从固定长度换成按结构分块

有段时间我老跟分块参数较劲，块大小从 300 调到 1000，始终觉得这里缺一块、那里太碎。后来发现问题的本质不在参数，而在切分方式。固定长度按字符数硬切，一份文档里完整的小节被拦腰截断是常态，切出来的块头尾各说各话，检索时自然匹配不准。

换成按文档结构切分之后，问题得到了本质改善。凡是带标题的文档，以标题为单位聚合内容，标题相近的内容天然在一个块里。对于没有结构的长文，我采用“从句段边界处切分 + 保留段落锚点”的策略，而不是简单按字符切。分块之后可以做一轮抽检：随机挑一些测试问题，确认它们的标准答案确实能落到某个块里。这个验证的意义在于，如果分块阶段已经把答案拆碎了，后面再怎么优化都救不回来。

4.3 幻觉还是存在：提示词约束加引用校验双管齐下

即便加了严格的提示词，模型偶尔还是会自由发挥，尤其是在资料不充分、问题很开放的时候。应对幻觉不能只靠提示词，更要在数据层和逻辑层做设计。

我的做法，是把“引用校验”变成独立环节。回答生成之后，要求模型在回答的关键句后标注引用的片段编号。程序随后校验：这些编号是否存在？被引用的片段里是否真的有对应内容？如果答案是模型自己脑补的，它很难给出一个真实片段来支撑，校验环节就能拦下来。这样一来，即使偶尔答错，也能让用户知道错误来自哪里，而不是让模型含糊带过。系统还可以定义低置信度规则：检索相关度低于阈值时，直接采用保守回答模板，不让生成模型自由发挥。

4.4 部署与成本：把账算清楚再动手

开源 RAG 的部署成本经常被低估，这里算一笔实际的账。一个中小型知识库，向量化全量文档可能需要几十分钟到一小时，这是一次性成本；之后每新增一个文档，只需增量向量化。运行期成本的大头在生成模型的推理：模型越大，显存占用越高，并发能力越弱。如果你用 8B 到 14B 规模的中小模型，一块消费级显卡就能跑，但吞吐有限；想要高并发，就要考虑多卡、批量推理或者部署优化框架。

另一种路线是混合形态：检索与编排全部本地化，生成模型调用在线 API。这样数据仍然不需要进知识库，推理成本也按需发生，适合量还没起来的起步阶段。我的建议是，不要为了“纯开源”而硬扛全部推理，先看业务规模，小步起步，跑通了再决定是否把生成也搬到本地。成本要算三块：机器成本、维护成本、模型调优成本，缺一不可。

5. 评估与进阶优化：从“能跑”到“好用”

5.1 别靠感觉评估：建立指标和验证集

RAG 项目很容易陷入“看起来还行”的错觉。今天试几个问题觉得不错，明天换一批问题可能立刻露馅。我建议尽早建立一套评估机制：先准备几十条典型问题，涵盖“容易回答的”“需要检索多个片段的”“资料里根本没答案的”三类，每条问题附带一个参考答案或判定规则。以后每改一次分块策略、换一次模型、调一次提示词，都把这套问题集完整跑一遍，对比新旧结果。

在指标层面，开源的 RAG 评估框架通常会给出几个量化的评分维度，例如忠实度、答案相关性、上下文相关性、检索召回率。忠实度衡量回答多大程度上忠于检索到的资料，是防幻觉的关键指标；答案相关性衡量回答是否切题；上下文相关性衡量检索到的片段本身与问题的匹配度。日常使用中，我把“上下文相关性”和“忠实度”作为最优先观察的两项，因为前者代表检索，后者代表生成。两项都高了，整体表现大概率不会差。

5.2 进阶优化：查询改写、多路召回、Agent 化

基础链路跑稳之后，如果还想继续提升，可以按下面顺序尝试优化。第一层是查询改写：把用户问题先交给一个轻量模型，改写成更适合检索的表达式。比如用户问“上次那个演示环境后来是怎么搭起来的”，改写为“演示环境搭建步骤”，向量召回会精准很多。第二层是多路召回：在向量检索、关键词检索之外，再加索引路径，例如同义词扩展、实体匹配，把多个召回结果统一合并后重排。第三层是 Agent 化：让系统具备“先检索、再判断、再检索”的能力，一个复杂问题被拆成多个子问题，分别检索再汇总，这就是所谓多跳检索的雏形。

要提醒的是，这些优化都有代价：查询改写多一次模型调用，多路召回带来更多存储和调试复杂度，Agent 化更是会把链路可靠性问题成倍放大。所以我的建议是，当基础链路的评估指标已经不太容易提升时，再考虑这些高级玩法。很多项目的瓶颈根本不是检索能力，而是数据清洗和分块，先把这两件事做到位，性价比最高。

5.3 一份可以直接照着做的调优清单

最后给一份基于实战整理的检查清单。按顺序排查，能节省大量玄学调参的时间：

1. 文档解析后的文本是否干净？有没有把表格拍平、夹带页眉页脚？
2. 分块是否按文档结构优先？一个完整知识点是否常被切断？
3. 入库时用的嵌入模型，和查询时用的嵌入模型是否一致？
4. 检索是否混合了关键词路径？专有名词、型号、编号能否命中？
5. 召回 Top-5 后有没有做重排？重排模型和嵌入模型是否分开？
6. 提示词是否明确要求“资料没有答案就直说”？
7. 返回上下文时，是否带了文档名、页码等来源信息？
8. 有没有一套固定验证集，每次改动后回归对比？
9. 查询侧是否处理了口语化表达？要不要加查询改写？
10. 有没有监控日志，能追踪每次问答的召回片段和最终答案？

把这份清单过一遍，大多数“RAG 效果不好”的问题，都能定位到具体环节。而且你会发现，最终被修正最多的往往不是模型，而是数据和检索链路。

我从头到尾踩下来，最大的感受是，RAG 的工程本质其实更接近数据工程问题。模型是放大器：检索到的资料好，模型能给一个漂亮回答；检索到的资料烂，模型只会放大错误。很多刚接触开源项目的人，一开始都在对比用哪家模型，后来慢慢都会把更多精力放到文档清洗、分块设计和检索评估上。最后分享一个小技巧：在评估阶段，我会专门准备一些“资料里根本没有答案”的刁钻问题，这类问题最能暴露幻觉。如果一个系统面对无答案问题时也能老实承认“不知道”，那它在正常答题时的可信度就会高很多。开源 RAG 这条路看起来很热闹，但真正跑完一个项目之后就会发现，热闹之外，把它一点一点调稳的过程，才是最值得沉淀的东西。