企业官网建设流程全解析

这两年只要聊到 AI 落地，AI知识库这个词几乎绕不开。很多人拍脑袋就下了结论：“不就是搭个RAG？文档切一切、向量库里一塞、大模型查一查就完了。”我一开始也是这么想的，直到亲手把知识库从 Demo 推到生产环境，才发现这句轻飘飘的话背后，藏着大量文档工程、检索调优和评估迭代的活。RAG 确实是核心骨架，但“搭个 RAG”只是起点，不是终局。今天这篇就围绕 AI 知识库这个话题，把概念拆解、完整管线、瓶颈分析、本地实操和进阶形态一次性说清楚，尽量少绕弯子，直接给你能落地的判断和做法。

1. 想清楚再动手：AI知识库与RAG的真实关系

1.1 RAG只是骨架，不是知识库的全部

RAG，也就是检索增强生成，最早是为了解决大模型“一本正经地胡说八道”和“知识截止”的问题。思路很直观：用户提出问题后，先从外部知识库里检索出相关片段，再把片段和问题一起塞给大模型，让它基于片段回答。这条思路被验证有效之后，“AI知识库=RAG”的等式就在各种技术分享里流传开了。

但如果你真在团队里做过一版“最小可用”的 RAG 知识库，很快会遇到这类场景：领导丢进来几百份带复杂表格的 PDF，销售团队要的是“某个客户上个季度合同里对账条款的原文”，HR 那边要问的是“年假折算规则在不同职级之间怎么区分”。这些需求远远不只是“检索几个 chunk 拼给模型”，它牵扯到文档结构的保留、片段之间关系的梳理、权限边界的控制，甚至多轮对话下的意图澄清。RAG 是这辆车的发动机，但车要跑得好，还得靠底盘、悬挂和驾驶员的判断。

我个人的定义是：AI知识库 = 数据接入 + 切片策略 + 向量化 + 检索链路 + 生成策略 + 持续评估。RAG 是其中最核心的检索生成链路，但“知识库”还有一层更重要的含义：它是组织内部可被机器理解和调用的“活字典”，这意味着它需要正向迭代、需要反馈闭环，而不是一次构建、永久使用。

1.2 为什么“能查”不等于“好用”

拿“能查”这个标准来衡量，很多知识库做到 60 分就停了。文档能搜到、答案不是空话，大家就默认上线了。但真正影响用户信任的是“能不能稳定地查到对的东西”，以及“查到之后模型能不能产出完整、可信的回答”。

举个例子：知识库里有公司报销制度和差旅制度。用户问“我出差回来打车到高铁站，这部分的费用算交通费还是差旅补助？”如果切片时把“交通费定义”“补助标准”“报销流程”切到不同的 chunk，检索结果可能只召回“补助标准”这一块，模型就只回答补助金额，漏掉了“需要提供发票凭证”这个更操作性的信息。用户拿这个回答去报销，要么被打回，要么觉得知识库不靠谱。这其实就是热词里反复出现的“知识割裂”。

“好用”至少包括三层：第一层是查得准，相关片段能在 Top 5 里稳定出现；第二层是答得全，多个来源的信息能合并成完整结论；第三层是可信，回答里能给出原文依据，让用户自己复核。要达到这三点，光会调 RAG 的 API 是不够的，你得把整条链路当作一个“检索系统”来深度优化，该做评估做评估，该上重排上重排，该换 GraphRAG 就得换。这篇后面会逐层展开，先把心态摆正：RAG 不是交付物，而是需要持续打磨的技术底座。

2. 一条RAG管线的完整拆解：每个环节都在决定成败

2.1 文档加载与切分：chunk size、overlap到底怎么定

很多人会觉得文档切分是 RAG 里最没技术含量的一步。实际上，切分策略直接影响检索命中率和回答质量，甚至比选哪个 embedding 模型还关键。

先说 chunk size。它指每个片段包含多少 token 或字符。切得太大，一个 chunk 里塞进太多无关内容，向量表达会被稀释，检索精度下降；切得太小，片段里信息不完整，模型拿到碎片拼不出逻辑。我的经验是，通用业务文档从 300 到 800 字符开始试，代码类或结构化记录可以适当调小到 200 到 400，长文报告和规章制度可以放宽到 1000 到 1500。你没有标准答案，只有用评估集测出来的答案。

再说 overlap。相邻两个 chunk 之间保留一小段重叠文字，是为了避免“一句话前半段在上一个 chunk、后半段在下一个 chunk”时两个片段都检索不到完整语义的情况。我习惯设 chunk 长度的 10% 到 15%。比如 chunk 600 字，overlap 就设 60 到 90 字。记住，overlap 不是越大越好，太大容易让重复内容出现在检索结果里，白白浪费向量空间。

这里有一个很多人忽略的点：切分要用“结构感知”而不是“纯按长度”。Markdown 标题、PDF 里的章节层次、表格边界、列表缩进，这些都隐含着文档的逻辑结构。用 LangChain 的 MarkdownHeaderTextSplitter、RecursiveCharacterTextSplitter，或者用专门的文档解析服务把层级先拆出来，会让检索质量上一个台阶。你想想，一个研究报告里“结论”部分和第 2 章“实验方法”的语义完全不同，如果按固定字符硬切，“结论”里的词很容易和前面方法论的内容混在一个 chunk 里，这就会造成热词里总在说的“知识割裂”。

实操上我还会做一步“切后清洗”：去掉页眉页脚、目录页码、引用链接，只保留正文语义单元。别小看这一步，很多 PDF 转出来的文本里每页都带着“第 x 页 共 x 页”这种噪音，混进 embedding 以后，检索时会出现莫名其妙的相似片段集中问题。

2.2 Embedding与向量存储：模型选型与库表的那些事

Embedding 模型负责把文本变成向量，它的质量决定了“语义相似度”的上限。这里有个常见的误区：以为大模型参数越大向量越准。实际上 embedding 模型和对话模型是两条技术路线，很多专用 embedding 模型小但检索效果很好。

选型建议分几步。第一步，看你语料以中文为主还是中英混合，中文场景我首推 bge-large-zh 或 bge-m3 系列，多语言场景可以看 m3 或 e5-mistral 这类。第二步，看维度，常见的有 768、1024、3072 维，维度高不代表更好，它会拖慢检索速度和加大存储空间。我自己在业务落地时优先选 768 维左右的平衡点。第三步，一定要在你自己知识库的样本上小规模评测，拿一组人工标注的“问题-相关片段”对，算 hit rate，这个具体做法在第 3 节讲。

向量数据库的选型也很微妙。专业向量库有很多选择，但本地自建或轻量集成时 Chroma、FAISS 就够了；要上生产、处理千万级数量且需要高并发，建议上一套成熟的向量数据库方案。不过工具选择反而是这条链路里最好替换的，因为接口都比较标准。真正要花心思的是集合设计。

我接手的项目里，最早大家都是一个 vdb collection 里塞所有部门的文档，结果问“报销流程有哪些注意事项”时，从市场部合同、人事制度、行政规范里各检索出来几条，全混在一起。后面我改成按“部门+文档类型”拆分 collection，或者给每条记录加上 metadata 并在检索时做过滤，效果立竿见影。给向量记录打上“来源文档、页码、章节、部门、日期、权限级别”这些标签，是知识库工程里躲不掉的关键动作。

2.3 检索、重排与生成：top-k、Rerank与Prompt设计

检索阶段最简单的是向量 Top-K，最常见的坑是把 K 设太小或空。K 太小，比如固定取 3，碰到模糊提问时很容易漏掉关键内容；K 太大，一堆低相关片段灌进上下文，模型反而被噪音带偏。我的做法是向量检索先召回 Top 20 到 50，再用重排模型压缩到 Top 5 到 8，这样结合了两阶段的优势：第一段保证相关材料不漏，第二段保证送进生成器的都是精华。

重排模型相当值得投入。普通向量相似度衡量的是片段和问题在语义空间的接近程度，但用户真正关心的是这个片段“是否直接回答了我的问题”。重排模型就是站在问题角度对片段逐条打分，能把“看似相似但不相关”的片段压下去。轻量一点可以用 Cross-Encoder，比如 bge-reranker-base，也就是一个几亿参数的小模型；效果不够再换大的。加了重排之后，hit rate 通常能提升 10 到 20 个百分点，这是 RAG 管线里性价比极高的一步。

Prompt 设计这块容易被低估。生成 prompt 至少要包含这几个要素：角色限定、任务说明、上下文片段、忠实度约束、不确定性处理方式。说人话就是，明确告诉模型“你是企业知识库助手，回答基于提供的资料，资料中没有的内容不要编造，如果资料之间矛盾要指出来”。我还习惯在 prompt 里加一句：“请用片段中提到的出处格式标注来源，以便用户核实。”这能显著减少模型自由发挥的空间。

3. 核心指标与瓶颈：别用“感觉还行”掩盖问题

3.1 hit rate、precision、recall与用户体感

热词榜单上出现过“rag hit rate”，我想单独拎出来讲。Hit Rate（命中率）指的是在一组测试问题里，系统召回的相关片段里是否包含人工标注的“标准答案片段”。假设你有 100 个测试问题，每个问题对应一份标准片段，系统检索后每个问题返回 Top 10 片段，其中 82 个问题能在 Top 10 里找到标准片段，那 hit rate@10 就是 82%。这是评估检索环节最粗暴也最有效的指标。

再看 precision 和 recall。Recall 关注的是“有多少相关片段被找回来了”，Precision 关注的是“找回的片段里有多少是相关的”。对 RAG 来说，我更看重 recall，因为生成环节还有模型兜底，多给几个片段不会太糟；但如果相关片段根本没被召回，模型再怎么聪明也答不出来。不过也不能完全不顾 precision，低 precision 意味着给模型灌进去大量噪音，输出的可信度会明显下降。上线前至少跑一遍 hit rate@5 和 hit rate@10，形成基线，之后每次换切分策略、换向量模型，都用这个基线对比，避免“感觉变好但数字变差”的尴尬。

用户体感比指标更滞后。经常出现指标还行，但用户觉得回答“太泛”的情况，多半是 prompt 约束不够或者召回片段不够完整。这时候可以把单条指标和用户反馈日志放在一起看，找“指标合格但用户点了踩/追问”的问题做专项复盘。

3.2 常见的RAG瓶颈与“知识割裂”现象

RAG 的瓶颈如果列个单子，排在最前面的永远是检索质量不稳定。导致不稳定的因素一般有三类：一是切片方式破坏了原文的语义边界，这是“知识割裂”的根源；二是 embedding 模型和业务领域不匹配，比如法律术语、医疗术语、小众技术名词在通用模型下表达不准；三是命中片段分散，单个片段只有半句话有用，拼起来又逻辑不通。

我遇到过一次特别典型的“知识割裂”：客户的知识库里全是产品操作手册，用户问“修改密码之后，旧 session 会不会失效”，按正文切分后，检索系统没能把“密码策略”“会话机制”“操作入口”三个章节的内容同时找出来，模型只根据“密码策略”片段回答“新密码生效”，漏掉“当前会话保留到过期时间”这个关键信息。这属于跨章节推理，传统 chunk 的向量检索天然不擅长。

另一类高频瓶颈是上下文窗口和答案长度冲突。业务方总希望回答“尽可能全面”，但全面意味着塞入更多片段，Token 一多，生成延迟变高，费用上涨，模型还容易把次要信息当重点展开，把主要结论淹没掉。这时候需要做“分层生产答案”：先给一段简洁结论，再补充关键依据和细节说明，而不是把能调到的资料一次性全倒给模型。

3.3 图片、表格、多模态内容怎么处理

热词里有个直白的问题：“rag知识库能存储图片嘛？”答案是：能，但要看你想怎么用。

纯文本向量库只能存文本的向量表示，如果你把图片文件直接传给 embedding 模型，它走不了标准文本链路。所以常规做法分两种情况。第一种是图里有文字，比如药品说明书、合同扫描件，你可以用 OCR 把图片里的文字抽出来，存入文本型知识库的 metadata 或独立字段，之后检索时命中文本内容，再通过附件路径去调原图展示。第二种是图里主要是图表数据或视觉信息，比如架构图、趋势图，OCR 不够，需要用多模态模型做图像 caption 或结构化描述，再把描述文本送进向量库。检索到描述后，把图片路径和文字信息一起交给对话模型，让它结合视觉模型做回答。

表格的处理更常见。PDF 里转出来的表格如果被切得七零八落，检索基本就废了。我的习惯是把表格转成“语义化文本”——不要简单保留 Markdown 表语法，而是把它改写成自然语言描述。例如“2023 年 Q4 营收 1200 万元，环比增长 8%，销售成本 400 万元，毛利率 66.7%”。这种文本检索命中率比原样表格高不少，因为用户提问往往用自然语言，不会说“给我找一行叫 Q4 营收的那个格子”。

4. 零基础本地实操：Ollama + 简易本地RAG知识库

4.1 环境准备与工具选型

很多人想先在自己电脑上把整套流程跑起来，验证一下“本地 RAG”到底行不行。我推荐一套零基础也能复制的组合：Ollama 加载本地大模型 + Chroma 做向量存储 + LangChain 做管线编排。这套方案不需要注册任何外部服务，数据留在本机，适合熟悉流程和学习，也适合对数据敏感的业务做私有化验证。

先准备环境。建议用 Python 3.10 或 3.11，太新的版本偶尔会遇到一些依赖还没适配的问题。装 Ollama 很简单，官网下载对应系统的安装包即可。装完后拉一个适合中文问答的模型，比如 qwen3:4b 或 qwen2.5:7b-instruct，在终端执行ollama pull qwen2.5:7b-instruct。同时准备 embedding 模型，我建议用bge-m3或nomic-embed-text，在 Ollama 里可以ollama pull bge-m3直接拉。向量存储我选 Chroma，轻量、自带持久化，Python 端pip install chromadb langchain langchain-chroma就够。

不要一上来就追求最大模型。7B 左右的量化模型在自己的普通电脑上已经能跑出可以接受的效果，再大只会影响实测迭代速度。先把链路跑通，之后所有组件都可以平滑替换成更大的模型或者商用服务。

4.2 端到端搭建流程

整个流程分成五步：加载文档、切分文本、生成向量、建库、检索问答。我直接把最核心的代码路径放出来，你看完就能在自己的机器上跑。

# -*- coding: utf-8 -*- from langchain_community.document_loaders import PyPDFLoader, TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OllamaEmbeddings from langchain_chroma import Chroma from langchain_community.llms import Ollama from langchain.chains import RetrievalQA # 1. 加载文档，测试阶段先用 txt 和 pdf loader = TextLoader("kb_demo/报销制度.txt", encoding="utf-8") docs = loader.load() # 2. 结构感知切分 splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80, separators=["\n## ", "\n### ", "\n\n", "\n", "。", "；", ""], ) chunks = splitter.split_documents(docs) print(f"切分得到 {len(chunks)} 个片段") # 3. 向量化 + 入库 embeddings = OllamaEmbeddings(model="bge-m3") vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_db", ) # 4. 检索问答 llm = Ollama(model="qwen2.5:7b-instruct", temperature=0.2) qa = RetrievalQA.from_chain_type( llm=llm, retriever=vectorstore.as_retriever(search_kwargs={"k": 5}), chain_type="stuff", ) query = "出差打车到高铁站，这段费用怎么报销？" answer = qa.invoke(query) print(answer["result"])

这段代码看着简单，但在实操里我强烈建议你做两处增强。一是给每条 chunk 加 metadata：chunks[i].metadata["source"] = "报销制度.txt"，检索时就可以按来源过滤。二是检索时开启“按相似度分数阈值过滤”，比如similarity_score_threshold=0.3，分数过低的片段直接不进上下文，防止模型被无关内容误导。等你对 LangChain 的组件熟一点之后，可以把RetrievalQA换成create_retrieval_chain的 LCEL 写法，灵活度更高，方便在中间插入重排和自定义 prompt。

本地跑通之后，你需要自己构建一个最小评估集：挑 20 个问题，每个问题人工写好“应该出现的关键点”，然后跑一轮检索，看看这些问题生成出的答案是否覆盖关键点。这是最朴素的验收方法，别跳过。

4.3 轻量级文本拆解工具推荐

热词里有人问“有没有本地的 rag 文本拆解工具”，这里整理三个轻量选择。

第一个是全流程型的 LangChain / LlamaIndex。它们不是单纯拆文本，而是把 loader、splitter、vectorstore 组装成完整管线，适合作为主框架。第二个是面向复杂非结构化文档的 Unstructured。它能把 PDF、Word、PPT 里的标题、列表、表格识别成带结构的信息单元，对洗掉页眉页脚和识别表格非常有用，缺点是比较吃内存。第三个是纯拆解工具的 Tiktoken 和 NLTK，前者按 token 边界切，更加贴近大模型上下文窗口的计量方式；后者按句子或者词法单元来切，适合本身就有完整句群语义的语料。

我要提醒一下：拆解工具的选择要跟着文档形态走。你的知识库全是 Markdown 技术文档，用 MarkdownHeaderTextSplitter 就很好；全是扫描件，主力必须在 PDF 解析和 OCR 上，拆解反而是后段处理。先看一下自己手里文档的“脏乱差”程度，再去定工具链路。

5. RAG的进阶形态：从传统RAG到Agentic RAG

5.1 为什么GraphRAG和本体RAG会出现

传统 RAG 在“跨片段综合知识”上的短板，催生了 GraphRAG 和本体 RAG。热词里出现了“rag graphrag llm wiki 本体rag”，说明大家都被这类问题卡住过。

GraphRAG 的思路是：先让 LLM 从文档里抽取实体和关系，构建出图结构，比如“回款周期（公司A，合同B）”“年假规则（职级P7，政策2024）”。回答问题时，不仅能做向量检索，还能沿着图结构去遍历实体之间的关系，把零散片段编织成网。这样遇到“A 项目延期会导致 B 合同里的回款条件发生什么变化”这种跨片段问题，回答起来会准确不少。代价是构建图需要额外的计算和存储，对文档量大、关系复杂的组织更划算。

本体 RAG 则更进一步，要求你基于领域知识定义清楚概念体系。比如 HR 知识库里，“职级”“岗位序列”“薪酬带宽”“绩效系数”这些概念之间是什么关系，提前用本体或 schema 约定好。检索时，系统不只是匹配字面相似，还会带入概念层级，问“高级工程师的年假”会自动关联“技术序列”这个父类，再去匹配具体规则。这个方向对知识管理要求高，但一旦体系成型，召回质量非常稳定。

GraphRAG 和本体 RAG 不是一刀切替换传统 RAG。我见过不少项目把图构建得很漂亮，结果问“打印机卡纸怎么处理”这种高频简单问题，GraphRAG 反而因为实体抽取太碎而表现一般。正确姿势是：简单问题走向量检索，复杂跨实体问题走图路径，两者按问题类型路由。

5.2 Agentic RAG：让检索成为智能体的一部分

“Agentic RAG”是近期最热的演进方向。它的核心变化是：把“检索一次、生成一次”的流水线，变成“模型自主决定是否检索、检索什么、检索几轮”的 Agent 决策过程。

举一个实际场景。用户问“我们公司今年 Q3 的销售激励政策，和去年比有什么变化？”传统 RAG 拿到问题后直接去向量库里捞片段，如果没捞到去年的政策，就会只答今年；Agentic RAG 会先理解这是一次“对比任务”，拆解为先查今年政策、再查去年政策、对比差异、输出结论。这需要大模型具备工具调用能力，比如调用一个“按文档范围检索”的工具，多次调用后自己汇总。

实现上通常用 ReAct 模式或者带工具调用的大模型。LangChain 里面有create_agent方法，定义好“检索工具”“文档过滤工具”“计算工具”，让模型在推理循环里自己组合。这套架构的优点是灵活、能处理多跳问题，缺点是要管的流程变多了，比如循环次数的限制、检索结果的上下文管理、误调用工具的止损。我的建议是：先做好传统 RAG 的评估基线，再上 Agentic RAG，不然你连它自主拆出来的子任务是对是错都判断不了。

5.3 一套渐进式选型路线

结合这么多年的落地经验，我把知识库技术选型整理成一条渐进路线，避免一上来就追求最花哨的方案。

第一阶段，文档量少、问答以单点事实为主：传统 RAG 即可，重点做好切分、metadata 和重排。第二阶段，文档量大、跨章节问题多：加入 GraphRAG 的实体关系层，把高频实体抽取出来作为补充索引。第三阶段，决策链长、需要多轮查证：升级到 Agentic RAG，让模型学会自己拆任务。第四阶段，领域体系成熟：在 GraphRAG 之上定义本体 schema，把概念关系固定下来，让检索更贴合业务语言。

我特别不建议团队一上来就对标最前沿方案。知识库最大的风险不是架构不够新，而是基础检索命中率低于及格线。先把 hit rate 拉上来，让用户愿意用，再谈更聪明的架构，这是次序问题。

6. 常见问题速查与实操心得

6.1 问题排查速查表

我把 RAG 项目里反复踩坑的问题整理成一张速查表，排查时可以按“现象 → 可能是哪里 → 怎么处理”来处理。

还有一个很容易被忽视的问题：源文档本身更新后，向量库里的旧版本没被替换。你需要在入库时管理版本号，重新导入新文档时把旧分片的 id 删掉。否则用户会问“为什么改了制度知识库还按老规矩答”，这会直接击穿信任。

6.2 从项目里得到的最重要经验

如果只说一条经验，我会说：先建评估集，再调参数，永远不要靠感觉上线。

我在第二个 RAG 项目上吃过亏。当时团队花了三周把切分、向量模型、Prompt 全都调了一遍，每次演示都觉得不错，但业务同事一用就挑出一堆毛病。后来我花了一个周末手动整理了 30 条高频业务问题，给每个问题标注了标准答案里的关键点，再量化跑分。跑完发现用固定 1000 字切分的 hit rate@5 只有 58%，调整到结构感知切分加 600 字之后直接升到 79%。这次之后我再也不凭“看起来合理”去做选择，所有改动都拿数字说话。

另外一条值得重复的经验是：RAG 知识库一定要保留来源引用。不管技术路径怎么升级，给用户展示“这段回答来自哪份文档、哪一页”永远是建立信任的最短路径。我甚至会在生成 prompt 里要求模型：“回答最后列出引用的资料名称和原文片段，如果多个资料冲突，请分别注明。”这个设计不起眼，却能显著降低用户对 AI 回答的怀疑成本。

最后再分享一个小技巧：当知识库里同一问题存在多条规则时，比如不同职级有不同的年假天数，你可以在切分后的文本开头加一句结构化摘要，像“适用范围：P7 及以上；规则：每年 15 天年假”，这样向量匹配的精确度会大幅提高。这个方法本质上是给每个片段做了“元摘要”，简单、便宜、有效，值得先试。

从“不就是搭个 RAG”到真正把它打磨成扛得住业务提问的知识底座，中间隔着的就是这些容易被忽视的细节。希望这篇文章能帮你把 RAG 从名词变成手上可控的工程能力，下一步就可以放心去折腾 GraphRAG、Agentic RAG 那些更先进的玩法了。