企业官网建设流程全解析

1. 先把RAG的"为什么"想清楚：进入架构设计前必须避开的三类坑

1.1 RAG到底解决什么问题，别被概念带偏

我在不少企业内部群看过同一种讨论：某部门主管说"我们想把公司几千份技术文档做成一个能对话的机器人"，底下人就开始查LangChain、查向量数据库、查大模型API，一周后给出一套看起来很复杂的架构图，然后项目就卡住了。这不是个例，而是RAG落地最常见的开局方式——先被概念推着走，再被问题追着改。

先说清楚，RAG（检索增强生成）解决的是一个非常具体的问题：大模型的知识截止时间、以及对私有知识的无知。模型本身不会知道你司内部某个系统的配置文件长什么样，也不会知道你内部明确的业务术语定义。RAG的思路就是：把外部知识先检索出来，再拼进提问上下文里，让模型"先看到答案再生成回答"。

所以RAG要解决的，本质是两个问题：召回来的东西是不是真的相关，以及召回来的内容能不能支撑模型给出正确回答。前者是检索层的事，后者是生成层的事。很多项目栽跟头，就是从头到尾只盯着"接个大模型API"和"建个向量库"，完全没把检索质量当作一个需要持续优化的工程问题来对待。

注意：RAG不是万能的。如果你要解决的问题是"让模型学会新领域的推理逻辑"或者"让模型稳定输出特定格式的统计分析"，RAG帮不了太多。RAG擅长的是"告诉模型它原本不知道的事实型内容"，这一点在立项时就要想清楚。

1.2 架构选型的核心判断：什么时候该上RAG，什么时候别凑热闹

我见过不止一个团队，在数据量只有几百条Excel记录的时候，就兴师动众上了完整的RAG架构。几百条数据，直接做关键词检索都够了；但一旦上了向量化、向量数据库、重排模型这一整套链路，带来的复杂度会反噬掉收益。这不叫技术选型，这叫给简单问题套复杂方案。

反过来，如果数据量到了几万甚至几十万条、文档格式杂乱、并且更新频繁，那确实需要一个正经的RAG架构。判断标准我一般看三条：

第一，数据是"查询密集型"还是"浏览型"。如果是用户要不断提问、需要精准命中某段内容，那就值得上RAG。第二，数据格式是否统一。全是Markdown或Word还好说，如果夹杂扫描件、表格、流程图，就要考虑OCR与结构化解析的投入。第三，答案是否接受"近似正确"。RAG本身做不到100%准确，如果你的业务场景要求每个回答都必须精确到某个合同条款原文，那RAG只能作为一个检索辅助，而不是直接给最终答案的渠道。

这么说吧，RAG架构的核心价值是"把不可控的模型生成，约束在可控的检索结果上"。但代价是：每一层组件都会引入自己的误差，分块切碎了上下文、向量召回漏掉了关键词、重排模型把高分内容排错……这些误差层层叠加，最终效果往往比单跑一个模型更难调。所以架构设计的第一原则不是炫技，而是用最少的组件达到可以接受的准确率，能一个向量库解决的问题，不上重排；能不拆微服务，就先单体跑通。

1.3 一个典型的企业级RAG架构长什么样

聊到架构，很多人第一反应是画一堆箭头和方块。我直接讲我在实际项目里用过、验证过的一套简化架构，分五层看，心里就有数了。

第一层是数据接入层。负责从内部系统里拉取文档源，可能是某个文档管理平台的导出接口，也可能是NAS里的共享目录。这一层的核心是"把数据变成统一的中间格式"，通常用纯文本或者Markdown来统一。第二层是处理与索引层。包括文档解析、清洗、分块、向量化，之后写入向量数据库，同时也会把原文和块索引存一份。第三层是检索层。用户提问进来之后，先做查询改写或意图判断，再去做向量检索、关键词检索，有可能两路结果做融合，再经过重排。第四层是生成层。把检索到的上下文块和原始问题一起拼成Prompt，送入大模型，生成最终回答。第五层是反馈与更新层。记录用户的点赞/点踩、记录哪些问题检索不到，定期触发重新索引。

这个五层结构并不复杂，但注意一个关键点：每一层都要有"可观测性"。我见过太多RAG项目，上线之后用户问"为什么这个回答是错的"，没人能说是哪一层出了问题。所以在架构设计阶段，就要在每层埋日志：谁调了检索、召回了哪些块、每块的相似度多少、最终进Prompt的内容是什么。没有这个，后面调优会非常痛苦。这一节先把架构轮廓放在这儿，接下来每一层组件怎么选、怎么配，我逐个拆开讲。

2. 组件逐个拆解：从文档加载到检索重排的选型与参数明细

2.1 文档加载与解析：不解决乱码和表格，后面全是白搭

RAG落地的第一步不是选模型，而是把"原始文档变成干净文本"。听起来简单，做起来却最耗时间。我接手过一套内部知识库，里面PDF、Word、Excel、PPT都有，PDF里还有大量扫描页。最开始我图省事，直接调了个现成PDF解析库抽取文本，结果好好的文档一抽出来全是乱码，公式、表格结构全部丢失。

这里要先说一个经验：解析质量直接决定检索上限。如果文本抽取阶段就把表格拆成碎片、把公式丢掉，后面无论向量模型多好、重排多准，都救不回来。所以文档加载这块，我现在的做法是按格式分级处理。

PDF分两类处理：数字版PDF直接用解析库抽取文本，扫描版PDF必须先过OCR。使用OCR会增加成本和时间，但面对扫描件就绕不开。Word文档优先用docx格式，碰到老式.doc先用工具批量转成docx再解析。Excel表格不能简单按单元格抽取，要尽量按"行列语义"转成Markdown表格或键值对文本。PPT则是按页提取文字并标注页码，方便后续回答问题知道出处。

一个好的文档解析，最终应该输出带结构信息的内容——比如标题层级、表格结构、段落顺序。不要小看这些元信息，它们决定了后续分块的语义完整性。我的建议是：解析完一批文档后，先随机抽查20个片段，确认没有乱码和明显错乱，再进入下一步。这一步你投入的时间，后面会几十倍地省回来。

2.2 分块策略：chunk size怎么定，为什么要配合检索效果看

分块是RAG里最容易被轻视、又最能拉开效果差距的环节。chunk太大，向量化时语义会被稀释，检索出来的片段不够聚焦；chunk太小，单个块承载的信息量不足，模型回答时缺少上下文。我常用的起点是：中文场景下，chunk size取400~600个字符（约200~300个token），overlap设50~100个字符。

这里要说一下overlap的作用。文本在切分时，相邻的块之间需要保留一定的重复内容，避免一句话被拦腰截断导致语义断裂。比如"虽然今天下雨，但是活动照常进行"这句话，如果正好从中间切开成"虽然今天下雨"和"但是活动照常进行"，单独看后半个块就不知道是"但是什么照常进行"。overlap就是给这种边界情况一个缓冲。

但overlap不是越大越好。过大的overlap会引入大量重复内容，检索时多个块相似度高，返回结果冗余。我踩过的一个坑是：为了追求完整度把chunk size调到了1200字符，结果一个块里包含了好几个主题，向量化之后主题互相干扰，检索出来的块看着相关，但具体答案所在的句子被淹没在一大段叙述里。后来我把chunk调小到500左右，配合overlap=100，明显感觉到回答的"命中率"高了。

分块方式我也提一下：不要上来就用固定字符切分，建议优先用递归字符切分（RecursiveCharacterTextSplitter），按"\n\n"、"\n"、句号、逗号这样的优先级逐级切分。这样可以尽量保段落和句子的完整性。如果你的文档有明确的Markdown标题结构，最好按标题层级切分，让每个块对应一个语义完整的章节片段。这块没有绝对最优参数，建议搭好管线后，把不同的chunk参数跑一遍离线评测，用"检索命中率"和"回答准确率"两个指标来定。

2.3 向量化模型与向量数据库：决定"相似"怎么算

向量化模型选型，是RAG项目里技术含量最高、也最容易被忽视的决策。我见过有人直接调大模型厂商的Embedding接口，效果不好就换一个，换来换去没个准。选Embedding模型，核心看三点：对中文的支持度、向量维度、语义理解上限。

国内做企业文档，中文占比高，优先选在中文语料上训练过的Embedding模型。我在多个项目里对比过，通用领域的中文Embedding模型在检索命中率上明显优于直接用英文为主模型的零样本效果。向量维度影响的是存储成本和检索速度：256维和768维相比，存储差3倍，但效果在中小数据集上差距不大。不要无脑选大维度，先按数据量和业务要求算一下成本。

向量数据库的选型，很多新手上来就纠结是选开源的还是商业的。我的判断很简单：数据量在百万级以下、并发不高，完全可以用轻量方案；数据量大、需要水平扩展和高并发查询，再考虑上专业向量数据库。注意，向量数据库的选型不只看查询性能，还要看它是否支持元数据过滤、混合检索（向量+关键词）、以及增量更新。企业场景里，文档经常更新，如果向量库不支持按文档ID删除旧向量再写入新向量，那你每次更新只能重建全量索引，代价很高。

另外提醒一点：向量数据库检索默认返回的是"向量相似度"，但相似度分数不等于业务准确率。不同模型算出来的分数分布差异很大，有的模型相关内容的分数集中在0.8以上，有的集中在0.4附近。所以不要在代码里写死一个"相似度>0.7就是相关"的阈值，一定要先对实际数据做一次分布统计，再定阈值。这个话题后面第4章会专门展开。

2.4 检索与重排：关键词与向量混合检索，以及为什么要做二阶段

纯向量检索有个明显的短板：它擅长理解"语义相近"，但不擅长精确匹配专业术语和编号。比如检索"接口错误码1042"，向量检索可能找到一堆关于"接口错误"的内容，却找不到文本里确实包含"1042"的片段。这时候就需要关键词检索兜底，最常见的是BM25算法。把向量检索和BM25做结果融合，可以显著提升召回率。

融合这块我建议用简单有效的方式：两路检索各取Top K个结果，去重后按分数加权合并。权重怎么设？我的经验是，如果文档里专业术语、编号多，BM25结果权重可以给到0.4~0.5；如果是自然语言问答为主，向量结果权重更高。别一上来就上很重的学习排序模型，先用固定权重跑通，再根据线上效果微调。

再聊重排，这是RAG管线里"性价比很高"的一环。向量召回阶段为了召回率，通常会多召回一些结果（比如Top 50），但很多结果其实不太相关。重排模型的作用是把这50条精排成Top 5~10，把最相关的内容排在前面。我用过的重排模型效果差距蛮大，好的重排模型能把准确率提升5~10个百分点，而且不影响召回。代价是多了一次模型推理，增加几毫秒到几十毫秒延迟，企业场景完全可接受。

重排后还要注意一个问题：送入大模型的上下文不要贪多。我见过有人把重排后Top 10的块全部拼进Prompt，结果生成时模型注意力被不相关内容干扰，反而答错了。我的做法是：重排后只取Top 3~5个块，控制总上下文在1500~2500字左右，给大模型精简、相关、不冗余的上下文。这一步对回答质量的提升，比重排模型本身还明显。

3. 实操落地：从零搭一个企业文档问答系统的具体步骤

3.1 最小可用版本的技术栈选型

纸上谈兵聊完了，直接给一套能跑起来的技术栈。这套选型的原则是：组件尽量少、替换成本低、每一步都可观测。我用的组合是：文档解析用常见的PDF和DOCX解析库，分块用递归字符切分器，向量化用开源的Embedding模型（如基于中文语料训练的bge系列），向量数据库先用轻量的FAISS顶着，检索阶段做向量+BM25混合，重排用开源的reranker模型，生成端接大模型API。

这个组合的优势是：全部组件本地可跑，不需要一开始就上分布式系统；FAISS作为向量库，虽然不支持复杂部署，但做技术验证完全够用；后续上了量，把FAISS替换成更专业的向量数据库，只改几十行代码。对于企业小白程序员，这个"先从单机跑通再演进"的路径是最稳妥的。

提示：如果你所在企业有严格的数据合规要求，不允许把文档内容发送到外部API，那么Embedding和重排模型都要选择本地部署的开源模型，大模型生成端也要考虑本地部署或私有化版本。技术栈选型前，先把合规边界划清楚。

3.2 一步步搭建RAG管线：从文档解析到Prompt拼接的代码流程

下面是一段简化但完整的RAG管线示例，我用Python写，不依赖重量级框架，方便你看清楚每一层在干什么。

import os from pathlib import Path # 1. 文档加载与解析 def load_documents(file_paths): docs = [] for fp in file_paths: if fp.endswith(".pdf"): # 这里以常见PDF解析库为例，抽取文本 import pdfplumber with pdfplumber.open(fp) as pdf: text = "\n".join(page.extract_text() for page in pdf.pages if page.extract_text()) elif fp.endswith(".docx"): import docx doc = docx.Document(fp) text = "\n".join(p.text for p in doc.paragraphs if p.text) else: text = Path(fp).read_text(encoding="utf-8") docs.append({"source": fp, "text": text}) return docs # 2. 分块 from langchain.text_splitter import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=100, separators=["\n\n", "\n", "。", "；", "，", " ", ""] ) chunks = [] for doc in load_documents(["./docs/example.pdf"]): for i, chunk in enumerate(splitter.split_text(doc["text"])): chunks.append({"source": doc["source"], "chunk_index": i, "text": chunk}) # 3. 向量化 from sentence_transformers import SentenceTransformer embed_model = SentenceTransformer("BAAI/bge-small-zh-v1.5") chunk_vectors = embed_model.encode([c["text"] for c in chunks], normalize_embeddings=True) # 4. 写入向量库 import faiss import numpy as np dim = chunk_vectors.shape[1] index = faiss.IndexFlatIP(dim) # 内积检索，配合归一化向量等价于余弦相似度 index.add(chunk_vectors.astype(np.float32)) # 5. 检索 def retrieve(query, top_k=20): query_vec = embed_model.encode([query], normalize_embeddings=True).astype(np.float32) scores, ids = index.search(query_vec, top_k) return [chunks[i] for i in ids[0]], scores[0] # 6. 重排 from transformers import AutoModelForSequenceClassification, AutoTokenizer rerank_model = AutoModelForSequenceClassification.from_pretrained("BAAI/bge-reranker-base") rerank_tokenizer = AutoTokenizer.from_pretrained("BAAI/bge-reranker-base") def rerank(query, candidates): pairs = [[query, c["text"]] for c in candidates] inputs = rerank_tokenizer(pairs, padding=True, truncation=True, return_tensors="pt", max_length=512) scores = rerank_model(**inputs).logits.view(-1).detach().numpy() order = np.argsort(-scores)[:5] return [candidates[i] for i in order] # 7. 拼接Prompt并调用生成模型 def build_prompt(query, contexts): ctx_text = "\n\n---\n\n".join(f"[来源: {c['source']}]\n{c['text']}" for c in contexts) return f"请根据以下资料回答问题，如果资料中没有相关内容，请明确说明未知。\n\n资料：\n{ctx_text}\n\n问题：{query}\n\n回答："

这个流程已经能跑，但注意两个细节。第一，normalize_embeddings=True这个参数很关键，因为FAISS的IndexFlatIP计算的是内积，归一化之后才等价于余弦相似度。如果忘了归一化，检索分数会受向量长度影响，排序结果失真。第二，重排模型的输入长度有限制，这里设置了max_length=512，所以分块大小不能超过这个token上限，这也是chunk size不能设太大的另一个原因。

3.3 参数怎么调：从召回率、准确率到最终回答质量

管线跑通只是第一步，真正花时间的调参阶段。我先说一套可复用的调参顺序：先调分块参数，再调检索策略，最后调Prompt。这个顺序不能乱，因为每一层都会影响后面。

调分块参数时，准备一组有代表性的问题集（20~50个就够了），离线把每个问题对应到正确的内容块。然后用不同chunk size、overlap组合跑一遍检索，看Top 5命中率。命中率低于60%，说明分块或Embedding选型有问题，先别急着调后面的。这块调好了，再上重排，观察"Top 5命中率→Top 3命中率"的提升幅度。如果重排后Top 3命中率几乎没变，说明重排模型没有起到精排作用，或者候选集质量太差，模型也排不出好东西。

最后调Prompt。这里有个原则：Prompt里要有"规矩"和"出处"。比如"如果资料中没有相关内容，请明确说明未知"，这句话能有效减少模型胡编乱造。再比如要求模型在回答后标注引用的来源编号，方便用户核验。不要小看这个设计，它直接影响用户对系统的信任度。我在实际项目里加了一句"回答时请优先使用资料中的原文表述"，结果回答的"幻觉率"肉眼可见地下降了。

注意：线上评估不能只看回答顺不顺。我见过很多RAG项目，演示demo效果好，一上真实流量就崩，原因就是demo用的问题和真实用户问题差异太大。建议上线前做一次小范围真实用户测试，把用户真实问题记录下来补充到评估集里，这个评估集会成为后续迭代最重要的资产。

4. 常见问题与排查技巧实录

4.1 检索结果相关但回答不对：先查Prompt，再查上下文结构

最让人头疼的问题是：检索出来的内容明明是对的，但模型回答是错的。我排查过几次之后总结出规律，90%的情况是Prompt设计或上下文结构的问题。

一种典型情况是上下文里同时存在多个相似片段，模型看了一堆信息之后"不知道听谁的"，就自己脑补了一个综合答案。解决办法是把Prompt改成"优先参考第一个片段"或者"如果片段之间存在冲突，请指出冲突"。

另一种情况是上下文中包含了检索不太相关的内容，模型被无关内容带偏。我发现很多人把重排后的Top 5全塞进Prompt，但Top 5里可能只有3个是真正有用的。建议在代码里加一步：设置一个相关度下限，不达标的片段不进Prompt。宁可给模型少一点上下文，也不要给它带噪声的上下文。

第三种情况是关于"出处"的。模型引用了一个检索片段里没有的细节，看起来是幻觉。解决的办法是强制要求模型在回答中引用片段编号，比如"根据[来源B]的内容……"。这样一旦引用出错，你也能定位是检索问题还是生成问题，而不是笼统地归为"RAG效果不好"。

4.2 相似度阈值怎么定：为什么我推荐"看分布而不是看值"

前文提到不要写死相似度阈值，这里展开讲。假设你用的Embedding模型计算出的分数集中在0.4到0.9之间，如果阈值设0.7，会过滤掉大量实际相关的查询；如果设0.5，又会放进很多噪声。根本原因是：不同Embedding模型的分数分布差异极大，而且同一模型在不同数据领域下的分布也可能不同。

我的做法是：上线前跑一批真实问题，把检索结果按分数从高到低排列，人工标出"哪些结果是相关的"，然后观察相关和不相关的分数分界点。这个分界点就是你的动态阈值基础。但用户的问题五花八门，固定的阈值很难覆盖所有情况，所以我更推荐的做法是：不设硬阈值，而是用一个"分段策略"。

比如Top 5结果里，第一名的分数明显高（比第二名高0.1以上），说明模型很确定，可以信任；如果第一名和第二名分数接近，说明有歧义，要把两个候选都送进Prompt让模型自行判断；如果前5名分数普遍低且差距不大，说明库里可能根本没有相关内容，干脆直接回答"没有找到相关资料"而不是硬答。这套策略比单一阈值稳健得多，它能根据每轮查询的具体分数分布做自适应判断。

4.3 一套可以"抄作业"的问题排查顺序

RAG排错最怕没有顺序，东查一下西查一下。我把我自己的排查顺序整理成了一张表，遇到问题就从第一行开始逐项确认。

这套顺序的逻辑是：从数据源到生成端，逐层排查，任何一层出问题都会导致最终效果不对。不要一上来就怀疑大模型不行，大部分RAG项目的效果问题，根因都在数据层和检索层。

再补一个独家小技巧：给每个检索片段打上"来源+块ID"的元数据标签。排查时，把一个错误回答反推到它引用的片段，你就能立刻知道是哪个来源的哪一段内容出了问题，然后直接去修原文或者调整分块策略。没有这套标签，排查效率至少慢一倍。

4.4 一个容易被忽略的更新策略问题

企业文档是持续更新的，RAG系统上线不是终点，而是维护期的开始。我见过不少项目上线后没人管文档更新，三个月后系统回答的还是旧版本的内容。这个问题要从一开始就设计好更新机制。

最基础的做法是定一个更新周期：每周或每月全量重建一遍索引。这个方案简单但成本高，数据量大时重建时间长。更优的做法是增量更新：文档变更时，重新解析变更的文档，删除向量库里对应的旧块，再写入新块。但这里有个前提：你的分块必须能追踪到每个块的来源文件。所以索引里必须存"文档ID+版本号+块索引"，否则增量更新时根本不知道哪些向量该删。

另外要注意，文档更新后，用户之前检索到的旧版本内容还留在对话历史里，这属于产品层面的问题（要不要提示用户内容已过期）。技术上能做的，是在检索阶段带着文档的"更新时间"元数据，重排时稍稍倾向于新版本的文档。这种细节不会写进教科书，但实际项目里经常遇到，提前考虑能省掉上线后很多运维的麻烦。

收个尾，不做总结，只分享一下我个人在实际项目里的体会。RAG落地这件事，最大的障碍从来不是技术门槛，而是"以为搭完架构就结束了"的心态。我见过太多团队把时间花在换向量数据库、换大模型上，却不愿意花一个下午去人工标注50条测试数据、去逐个检查解析出来的文本质量。AI项目的效果，很大程度取决于你"喂"给它的数据和约束条件，RAG尤其如此。如果你刚起步，我建议先按这篇文章跑通一遍最小闭环，然后用一周时间持续调参和积累问题集，再回头看我说的这些排查技巧，你会感受更深。这条路上没有银弹，但有方法可循，按部就班地来，就不会被坑得太惨。