企业官网建设流程全解析

1. RAG为什么突然火：先把问题说清楚

1.1 大模型的窘境：能聊天，却答不了你家的文档

检索增强生成（RAG）这个词，最近几乎每个做大模型应用的人都在聊。但我发现很多人把它当成一个"高级概念"，一上来就谈向量库、谈重排序，反而忽略了它到底在解决什么。我先讲一个非常常见的场景。

你训练或者调用一个大语言模型，问它"公司的加班调休流程是什么"，它能给你写出一段通顺的答案。但你拿公司真实制度文档去核对，会发现它编造了一个不存在的"线上申请-审批-备案"流程。原因很简单：大模型的知识来自它训练时见过的公开语料，它根本没见过你们公司的内部文档。这不是模型笨，而是它的知识边界摆在那里——训练数据有截止日期，公开语料没有你的私有信息，而且模型在不确定的时候倾向于"自圆其说"，这就是所谓的幻觉。

RAG的核心思路，就是把这个"记忆"问题从模型内部挪到模型外部。它不再试图让大模型记住所有知识，而是先问一个问题：答案可能出现在哪份文档里？找到对应的段落，再把它喂给大模型，让它基于这些材料作答。相当于给大模型开卷考试，而不是逼它闭卷死记硬背。

1.2 RAG的核心思想很简单：先检索，再生成

我见过一些新手把RAG理解成"给大模型接一个数据库"，这个理解方向对，但不全对。RAG不只是"把文档塞进系统"，它是一套完整的"检索-增强-生成"流水线。

拆开看就是三个动作：第一，把你的私有文档切分成小块，每一块转成向量存入向量数据库；第二，用户提问时，把问题也转成向量，去数据库里找语义上最接近的若干段落；第三，把找到的段落和用户问题拼在一起，交给大模型，让它根据这些段落生成答案。

这套流程的价值有几个层面。首先是知识实时更新，你不需要重新训练模型，换文档内容就换知识；其次是可追溯，大模型引用了哪一段，你可以明确展示给用户看；最后是可控制，你可以通过调整检索范围，让模型只聊你允许它聊的内容。实际落地时，我强烈建议你把RAG理解为"带检索功能的工程系统"，而不是某个单一工具。

1.3 RAG与微调不是二选一：一张对照表说清楚

很多人在选RAG还是微调时纠结很久。其实这两条路线解决的是不同层面的问题。微调是改变模型的"行为方式和表达能力"，RAG是改变模型的"信息来源"。

我列一个对比表，你一眼就能看出差别：

实践中最靠谱的做法是先用RAG跑通业务，如果发现某个细分场景的"表达能力"确实不够——比如模型不懂你所在领域的专业术语写法——再考虑对模型做轻量级微调，两者可以叠加使用，不是互斥关系。

2. 从文档到答案：RAG的完整工作链路拆解

2.1 索引阶段：预处理、切块、向量化与入库

RAG的第一步是建索引，也就是把原始文档变成可以被检索的形式。这一步做得不好，后面检索结果必然崩塌。我通常会拆成四个环节。

首先是文档加载与解析。PDF、Word、Markdown、网页都需要分别处理。这里有一个非常隐蔽的坑：很多PDF是扫描件，里面根本没有文字层，你需要先做OCR识别。否则你辛苦建立了索引，检索的时候却什么都查不到，因为段落内容是空白的。

其次是文本切块。大模型有上下文长度限制，而且塞入过多无关内容会稀释注意力，所以文档必须切成合适大小的块。切块策略直接影响检索命中率，我后面会专门展开讲，这里先记住一个原则：语义完整优先于长度整齐。

第三是向量化。把每一块文本通过嵌入模型转换成向量，比如得到几百上千维的数值数组。嵌入模型的质量决定了"语义相近"判断的准确度。大体上，好的嵌入模型能理解"奖金申请"和"绩效奖金发放流程"是相关的内容，差的模型可能只匹配到字面重复的句子。

第四是写入向量数据库。向量数据库负责存储这些向量，并在检索时按相似度快速返回结果。选型时重点关注检索速度、过滤能力、混合检索支持程度，不要只盯着排行榜上的性能数字。

2.2 检索阶段：从用户问题到候选文档

检索是整个RAG系统的命门。用户输入一个问题后，系统要做的第一件事不是让大模型回答，而是先做一次"找材料"的动作。

具体流程是：把用户问题用同一个嵌入模型向量化，然后在向量数据库里计算它与所有文档向量的相似度，通常是余弦相似度，取出最相似的Top-K个段落。这个过程中有几个关键变量：返回几个段落、相似度阈值是多少、需不需要对段落做元数据过滤。

只做向量检索有一个常见盲区：当用户问题里含有人名、编号、产品型号这类精确词汇时，向量检索不一定比得上传统的关键词检索。所以现在主流做法是混合检索——把向量检索和关键词检索结合起来，两路召回，再做融合排序。你可以把向量检索理解为"找意思相近的朋友"，关键词检索理解为"找名字相同的熟人"，两者互补才最稳。

2.3 重排序与生成：把相关上下文组装给大模型

召回出的段落里，往往第一名和第五名的质量差距很大。直接用Top-5拼进提示词，经常会把大模型的注意力带到沟里去。我建议在检索和生成之间加一道重排序环节。

重排序的原理是：用一个小型但高精度的打分模型，对召回段落逐条重新评分，把真正有用的内容排在前面，过滤掉实际上无关的段落。它比嵌入模型的匹配精度更高，代价是多一次推理调用。在预算允许的情况下，这一步对回答质量的提升非常明显，尤其是知识库内容庞杂的时候。

生成阶段的提示词组装也有讲究。我常用的模板逻辑是：先给模型设定角色——"你是一个客服助手，只能依据以下资料回答问题"；然后列出检索到的资料，每条带上来源编号；最后是用户问题，并强调"如果资料中没有答案，就回答不知道，不要编造"。不要小看这几句话，它直接决定模型会不会老老实实做"资料搬运工"。

3. 实操：三十分钟搭建一个私有文档问答RAG

3.1 需求定义与技术选型

说一千道一万，动手跑一遍比看十篇文章都管用。我当时接到的任务是做一个内部产品手册问答助手，不需要大模型开源部署，重点是快速验证流程。我选了最朴素的技术组合：开源的文本嵌入模型做向量化，本地向量数据库做存储和检索，再调用通用的对话大模型接口做生成，整个流程用Python串起来。

有人会问，为什么不自建大模型？对于企业内部问答来说，短时间内把模型质量和吞吐量调到可用水平，成本和精力都不划算。先调用成熟接口把RAG的逻辑跑通，将来要换本地模型，只需要替换生成接口那一层就行。这也是RAG架构的优点：模块之间耦合度很低。

3.2 核心代码：索引建库部分

索引阶段的核心代码，大致长这样：

from doc_loader import load_files # 读取各类文档 from text_splitter import split_chunks # 文本切块 from embed_model import EmbeddingModel # 嵌入模型封装 import vector_store # 向量数据库客户端 # 1. 加载文档 docs = load_files("./product_manual/") # 2. 切块：每块400字符，重叠80字符 chunks = [] for doc in docs: chunks.extend(split_chunks(doc.content, chunk_size=400, overlap=80)) # 3. 批量向量化 embedder = EmbeddingModel(model_name="chinese-embedding-model") vectors = embedder.embed_documents(chunks) # 4. 写入向量数据库，同时保存原始文本和元数据 for i, chunk in enumerate(chunks): vector_store.insert( vector=vectors[i], text=chunk.text, metadata={"source": chunk.source, "page": chunk.page} )

这里有几个细节新手容易忽略。切块时加重叠窗口，是为了避免一个完整语义被一刀切在两块中间；写入元数据，是为了将来可以按文档来源过滤检索范围。向量化时批量处理比逐条循环快得多，接口调用次数也能省一大截。

3.3 核心代码：检索与生成部分

检索和生成放在同一个请求处理函数里，流程如下：

def ask(question: str, top_k: int = 5): # 1. 问题向量化 q_vector = embedder.embed_documents([question])[0] # 2. 向量检索 hits = vector_store.search(q_vector, top_k=top_k) # 3. 重排序（可选）：用交叉编码器重新打分 reranked = reranker.rerank(question, hits) # 4. 拼接提示词 context = "\n\n".join( f"[{i+1}] 来源：{h.metadata['source']}\n{h.text}" for i, h in enumerate(reranked) ) prompt = f"""你是一个产品助手，只能根据下面提供的资料回答用户问题。 资料： {context} 用户问题：{question} 如果资料中没有相关信息，请明确回答"我没有找到相关资料"，不要编造。""" # 5. 调用大模型生成 answer = llm.chat(prompt) return answer, reranked

我跑通这个流程的第一感受是：RAG的系统结构确实不复杂，真正复杂的在于"里面的内容组织和参数调优"。比如Top_K到底取3还是取5，重排序模型该不该上，上下文拼多长才不会淹没重点，这些都是一步一步实验调出来的。

3.4 第一轮实验结果与暴露的问题

第一轮实验我测了20个问题，总体能用，但暴露了几个问题。第一，当文档里有大量相似术语时，向量检索召回的段落会重复雷同，比如五条结果里三条讲的是同一个功能的不同截图描述；第二，对于用户口语化的提问，比如"这功能咋开启"，直接做向量检索的效果不如把它改写成"功能开启步骤"这种祈使句；第三，模型偶尔会忽略资料里明确的答案，反而用自己的知识回答。

这些问题让我意识到，RAG就像一个毛坯房，能住人，但要住得舒服，必须花大量时间打磨细节。接下来这部分，我想把最有价值的细节经验一次性说清楚。

4. 决定检索质量的六个细节，比选模型更重要

4.1 分块大小与重叠窗口的科学设置

分块策略是RAG里争议最多、影响最直接的一环。块太小，语义不完整，模型看不到前因后果；块太大，噪音太多，嵌入向量的语义被稀释，检索精度反而下降，同时生成的上下文也会被撑爆。

我测试过几组参数：256字符、512字符、1024字符，重叠窗口分别是0、50、100。结果在技术问答场景下，512字符加80字符重叠的效果最稳。这个数字不是通用的，如果你的文档是合同条款，一段可能只有几十个字，那就适合按条切分；如果是操作手册，步骤之间强关联，就适合稍大的块并带重叠。

核心原则是让每个块尽量是一个"独立可理解的语义单元"。可以在切分时做一些结构化处理，比如按Markdown标题分节，按表格的行边界分割，避免一个表格被拦腰切断。这个功夫花在索引阶段，受益的是整个后续流程。

4.2 嵌入模型怎么选型

嵌入模型决定了语义匹配的上限。目前选择大体分三类：闭源API模型、开源通用模型、面向中文或垂直领域微调过的模型。我的建议是不要只看评测榜单，要拿你自己的真实文档和问题来测。

换嵌入模型不是改一行配置那么简单，因为不同模型的向量维度不同，你需要重新对全部文档做索引。所以我一直建议：项目初期就多测两个模型，用同一批测试问题对比召回结果，选好后再大规模建库，不然后面返工的成本很高。

4.3 top-k与相似度阈值：召回多少合适

Top-K熟练的设置是新手最容易忽略的。取太少，可能漏掉正确答案；取太多，无关片段混进来，大模型容易被带偏。我做过一次实验，同一个问题在Top-3、Top-5、Top-10下的回答质量，Top-5明显好于Top-3和Top-10。原因不难理解：3条太容易漏相关内容，10条则引入了大量干扰文本。

除了数量，相似度阈值也要设置。向量检索本质上会返回"相对相似"的结果，哪怕所有文档都不相关，它也会给你个第一名。如果设定一个最低分，比如余弦相似度低于0.35的段落直接丢弃，就能有效避免模型在毫无依据的情况下硬答。阈值需要根据你的嵌入模型和文档特点实测得出，没有标准值。

另外，当召回结果为空或者全部低于阈值时，最优策略不是硬着头皮生成，而是让模型直接回答"知识库中没有相关信息"。很多时候，诚实说不知道，比一本正经地编答案更让用户信任。

4.4 查询改写和HyDE：让用户问题变得更可检索

用户的提问方式和文档的表述方式经常不在一个频道上。比如用户问"这玩意儿咋退款"，而文档里写的是"退款申请流程及退费标准"。直接用原问题去向量检索，匹配效果一般。这时候就要做查询改写。

最简单的改写方式是用大模型把口语化问题转成正式的、带动作对象的问题："如何申请退款？流程是什么？"进阶一点的做法是生成HyDE（假设性文档嵌入），也就是让大模型先根据问题写一个"假设的理想答案"，再用这个答案的向量去检索。因为理想答案的用词风格更接近目标文档，召回效果往往会好不少。

我实测中，查询改写对短查询、口语化查询的帮助最大。但注意不要过度改写，每次改写都会增加一次模型调用延迟，如果系统对响应时间要求很高，可以只对特定类型的问题触发改写。

4.5 提示词模板如何有效利用上下文

很多人的RAG效果不好，问题出在提示词上。他们把所有检索段落一股脑倒给模型，然后说"根据资料回答"，结果模型也不知道该优先信谁。

经验是，提示词里要明确三件事：角色、规则、证据优先级。我习惯先说"你是某文档问答助手，只能依据提供的资料作答"，再说明"当资料内部有冲突时，优先采用来源更权威或时间更新的段落"，最后规定"资料不包含答案时，必须承认不知道"。

还有一个小技巧：把每段资料加上编号，并要求模型在回答中用编号标注信息出处。比如"根据资料[2]，退款周期为3-5个工作日"。这样既方便用户核对，又能显著降低模型的自由发挥程度，因为它知道每个信息点都可以被追溯。

4.6 评估闭环：没有指标就没有优化

RAG系统最怕"感觉还不错"，因为感觉会骗人。我强烈建议从第一天就建立评估集：准备30到100个真实问题，标注期望答案和答案对应的资料段落，每次修改系统后都跑一遍，看召回准确率和回答完整性是变好还是变差。

评估指标可以分两层。检索层看召回率（正确答案是否出现在返回结果中）和排序质量；生成层看回答是否忠于资料、是否包含关键信息点。人工评估成本高，可以用大模型间互评的方式做初筛，但是最终结论一定要抽样人工复核。

有了评估闭环，你才能回答"这次该分块策略到底好不好""换嵌入模型值不值"这类问题。否则，你可能只是在靠运气调参。

5. 从Demo走向生产：那些踩过才懂的坑

5.1 藏在扫描件里的"文字"：PDF解析与OCR

上线第一个版本时，我遇到一个非常尴尬的故障：用户上传了一份盖章扫描的PDF合同，检索结果为空。检查索引库才发现，这个PDF的每一页都是图片，根本没有文本层。解析器返回的正文是空字符串，索引阶段直接跳过了这些文件。

这个问题在真实的企业文档里非常普遍。解决方案是引入OCR环节：先识别图片中的文字，再做切块和向量化。OCR模型选型上要关注中文识别准确率和表格结构还原能力。处理完OCR文本之后，还有一个隐性收益：很多图片版文档里包含"历史文件"字样，OCR出来后你就能用元数据标注，防止模型引用过期内容。

5.2 表格和长文被切碎后，检索结果惨不忍睹

RAG系统对表格数据的处理是个经典大坑。一个包含多列的表格，被通用切分器切成几块之后，每块可能就剩下孤零零的一列数据，模型根本看不懂上下文。

我现在的处理方式是：解析文档时检测表格结构，把整张表格作为独立块保存，同时在块内保留表头字段说明。如果表格太大，就按逻辑行组切分，并在每个子块中重复带上表头信息。这样模型既能看懂列的含义，检索时也能返回完整的表格片段。

长文档也是类似问题。一个60页的技术白皮书，如果按固定长度切分成几十个块，它们之间没有任何章节层级关系，检索到的内容就是"碎片里的碎片"。更合理的做法是保留文档的标题层级，把父级标题拼进每个块的文本里，就像给每个碎片贴上"归属标签"，检索和生成的质量会有明显提升。

5.3 检索知识与大模型先验知识打架时怎么办

生产中还有一个非常常见的现象：文档里写的结论，与大模型在训练中学到的通用常识不一致。比如你们公司的报销上限是5000元，但大模型在公开语料里常见到的是"很多企业报销上限为2000元"。这时候模型可能无视文档，直接给出2000元的答案。

我的处理办法有三层。第一层，在提示词中提高资料优先级，写清楚"当资料与常识冲突时，一律以资料为准"；第二层，对高风险问题强制要求模型在回答末尾附上引用段落编号，没有引用就不能作答；第三层，在生成后加一道校验逻辑，检测答案中的关键数字、日期是否在检索资料中出现过，如果完全没出现过则标记为疑似幻觉。

这套组合不能说100%消除幻觉，但确实把"一本正经说错话"的概率压到了很低的水平。

5.4 性能、成本与安全：上线之前要做的功课

最后说生产环境的现实问题。RAG上线之后，每一项能力都有代价。嵌入模型调用要钱和时间，重排序增加延迟，大模型生成按token计费，用户的每个问题都是多条链路叠加消耗。

我建议做三层优化。第一层是缓存：完全相同的问题直接复用历史答案，相似问题可以用向量匹配命中缓存；第二层是分级模型：简单问题用小模型生成，复杂问题才调用大模型；第三层是对检索上下文做精简：重排序后只取真正相关的前两三条，而不是无脑塞入五条。

安全方面同样不能马虎。至少要做两件事：一是对上传文档做权限管理，不同用户只能检索到他有权限看的资料；二是给输出内容加敏感信息过滤，防止模型把某些不该外传的内部信息泄露出去。这两条在金融、医疗、法律等场景里是硬要求，前期不做，后期整改起来非常痛苦。

我自己从最初跑通Demo到现在，最大的体会是：RAG不是一个"搭完就完事"的功能，而是一个需要持续调优的工程系统。文档会变，提问方式会变，模型会换，评估集也在扩充。但核心方法论始终稳定——把知识放进可检索的文档里，用可靠的流程控制模型的输出范围，剩下的就是一个个细节较真。如果你现在正准备做一个知识问答类应用，我的建议很直接：先把一个最小RAG流程跑通，再用真实文档去做几十个评估问题，然后对着暴露出来的问题逐一优化。这个过程走完，你再看任何RAG文章，都能一眼分辨出哪些是干货，哪些是空谈。