企业官网建设流程全解析

做客服系统集成这些年，我一直被一个问题困扰：大模型很聪明，但也很会编。你把产品手册、售后条款、常见问题文档全丢给它，它回答用户问题时依然会“一本正经地胡说八道”——把不存在的功能说得有模有样，把价格报错还一脸自信。直到我用检索增强生成（RAG）重构了整个客服问答链路，这个“爱胡说的学霸”才终于老实下来。这篇文章就把RAG的原理、工程实现和我在真实项目里踩过的坑完整拆一遍。适合正在准备做知识库问答、客服机器人、企业内部文档助手的开发者参考，零基础或者已经跑通过一两个RAG小项目的人，都能从中拿到可复用的方案。

1. 为什么客服机器人会胡说八道

1.1 大模型的“自信式编造”

先说一个容易被忽视的事实：大模型本质上是一个“概率续写器”。它根据你给的上下文，逐字预测下一个最可能出现的词。这种机制决定了它天生没有“我知不知道”的判断能力——只要它能续写出通顺的句子，它就会继续写，哪怕内容根本不对。

客服场景里这个问题会被放大。用户问的是非常具体的业务问题：“这款路由器的保修期是多久？”“取消订单后多久退款？”“赠品漏发了怎么办？”这些问题的答案不在模型的训练数据里，或者训练数据里的信息早就过时了。可模型不会说“我不清楚”，它会根据相似的表述“脑补”出一个答案。这就是AI圈常说的“幻觉”，也是客服机器人上线后容易被投诉的头号原因。

1.2 开卷考试：RAG解决幻觉的基本思路

RAG（Retrieval-Augmented Generation，检索增强生成）的思路特别简单，你把它理解为“开卷考试”就行。传统大模型是闭卷考试：全靠脑子里记的东西回答，记错了或者没学过就编。RAG则是先给你一份参考资料，你再翻着资料答题——答案必须从资料里找依据，找不到就承认不知道。

具体到客服机器人身上，运作流程是这样的：

1. 提前把产品文档、FAQ、工单记录、操作手册全部拆成小段，向量化后存进知识库。
2. 用户提问时，先从知识库里检索出与问题最相关的几个片段。
3. 把用户问题加上这几个片段，一起塞进大模型的上下文。
4. 大模型再根据这些“指定参考资料”生成回答，并且可以要求它在回答中标注来源。

这个思路看起来简单，但工程落地时每一个环节都有讲究。知识库怎么拆？向量怎么算？检索怎么排？上下文的提示词怎么写？后面的章节我挨个说。

2. RAG核心链路拆解：索引、检索、生成

2.1 索引：把知识库变成可检索的“字典”

索引阶段是整个RAG的地基。你可以把原始文档想象成一本没有目录、没有页码的书，大模型根本没法快速找到某一句话。索引的目标就是把这本书变成一套带目录和关键词的卡片盒。

第一步是文本拆解，也叫chunking。很多人图省事直接按固定字数切，比如每500个字一刀切，结果切出来的片段语义被拦腰截断，检索效果惨不忍睹。比较靠谱的做法是优先按文档结构切：先按章节标题切，再按段落切，最后按句子切；如果单段过长，再用重叠窗口的方式切，让相邻片段保留一部分重叠内容。热词里有人问“有没有本地的RAG文本拆解工具”，这个问题我很有发言权：我最早也满世界找工具，后来发现最实用的反而是用开源库自己拼。LangChain的RecursiveCharacterTextSplitter、LlamaIndex的SentenceSplitter，或者干脆自己写几十行代码按“标题->段落->句子”的优先级递归切分，都比硬套现成工具灵活。工具本身不重要，拆解策略才是关键。

拆完块，下一步是向量化，也就是把每个文本片段转换成一串向量数字。这串数字可以理解成片段在“语义空间”里的坐标，语义相近的文本坐标距离也近。向量模型的选择对效果影响很大，我常用的是通用领域的embedding模型，比如BGE、GTE这类开源中文模型，尺寸不大、效果稳定。考虑到中文客服场景的口语化表达，如果预算允许，优先选针对中文优化的embedding模型，英文模型对中文长尾问题的检索效果会差不少。

向量化之后就得把向量存起来，这就轮到向量数据库上场。常见选择有Chroma、FAISS、Milvus、Qdrant这几种。我的建议是：原型阶段用Chroma或FAISS，安装轻、零运维、本地跑特别顺；生产环境数据量超过百万级再考虑Milvus或Qdrant。客服知识库大多也就几万到几十万段文本，从头用Chroma完全够用，别一上来就上重型组件。

这里专门回答一个高频问题：RAG知识库能存储图片吗？能，但得分情况。传统的文本RAG处理不了图片内容，如果知识库里既有文字又有产品截图、流程图，最经济实用的方案是先用OCR把图片里的文字提取出来，把提取结果作为文本片段入库，图片本身只保留路径作为来源引用。如果需求是“用户上传一张故障照片，机器人根据图片判断问题”，那就要引入多模态embedding和多模态大模型，工程复杂度直接上一个台阶。客服场景里百分之八十的图片需求用OCR方案就能满足，没必要一上来就上多模态。

2.2 检索：召回与重排的配合

知识库建好了，用户的问题来了，接下来就是检索。最常见的检索方式是向量相似度检索：把用户问题也向量化，然后去向量数据库里找距离最近的Top K个片段。这个做法的优点是能理解同义表达，缺点是它不擅长精确匹配——用户问“SN码在哪里看”，如果知识库里写的是“序列号位于机身底部标签”，向量检索通常也能召回，但如果涉及产品型号这种高度精确的字符串，向量检索就可能翻车。

所以在工程实践里，我更推荐混合检索：向量检索负责语义召回，关键词检索（比如BM25算法）负责精确匹配，两者结果合并后再做去重和重排。重排这一步很多人会忽略，实际上它的性价比极高。首轮召回可以放宽到20到30个片段，然后用一个轻量级Rerank模型按相关度重新打分，只保留前5个。这样既保住了召回率，又保证了进入大模型上下文的片段质量。我自己实测下来，加了Rerank之后客服问答的准确率能提升百分之十以上，而且这些片段之间的噪声明显变少。

2.3 生成：把检索到的依据“喂”给大模型

检索结果拿到以后，最后一步是生成。这一步的关键不在模型本身，而在于提示词怎么设计。我的经验是提示词里必须明确三件事：第一，只允许依据给定的资料回答；第二，如果资料里没有答案，直接说“不知道”，禁止编造；第三，回答时尽量引用资料中的原话或关键数字。

举个例子，我在系统里有一段很基础的提示词模版：

你是一个客服机器人。请严格依据以下资料回答用户问题。 如果资料中没有相关信息，请直接回答“抱歉，这个问题我暂时无法确认”，不要自行猜测。 回答时尽量引用资料原话，回答结束后用【来源】标注依据的资料标题。 资料： {context} 用户问题： {question}

这里有三个容易被忽略的细节。一是上下文容量，片段越多模型越容易“看不过来”，一般塞进5到8个片段，每个片段控制在300到500字，整体不超过模型上下文窗口的三分之一；二是片段顺序，把相关性最高的片段放在最前面，模型对开头的注意力权重更高；三是防止“资料打架”，如果多个片段内容冲突，我要求模型以“最新更新日期”的资料为准，这个规则解决了很多客服场景里文档版本混乱导致的错误回答。

3. 工程实现：从零搭一个本地客服机器人

3.1 技术选型：框架、模型与向量库怎么搭配

聊完原理，直接进入实操。我先说选型结论，再说理由。

框架层面，Python生态首选LangChain或LlamaIndex；Java技术栈可以看LangChain4j。热词里有人提到LangChain4j Easy RAG，这个扩展确实很适合Java团队，它把加载文档、拆块、向量化、检索、生成这一整套流程封装成了几个可配置的组件，内部依赖也很薄，比从零写要省事很多。

模型层面，客服机器人大可不必追求最强模型，7B到14B规模的开源本地模型就够用。我常用的组合是：Ollama加载Qwen系列或Llama系列作为生成模型，用Ollama自带的embedding接口或单独跑一个GTE模型做向量化。整套系统可以完全跑在本地，不依赖任何外部API，这也正好契合热词里“ollama + 简易本地RAG知识库”的思路，对数据敏感的企业尤其友好。

向量库层面，原型用Chroma，数据量大再迁移到Milvus或Qdrant。存储层面，知识库的源文件建议用本地磁盘或对象存储统一管理，不要散落在各台机器上，否则后面做增量更新会非常痛苦。

3.2 零基础可复制的搭建步骤

下面这套流程我整理过很多次，照着做就能跑通一个本地客服机器人。假设你的文档是几个Markdown或PDF文件，目标是让机器人基于这些文档回答问题。

第一步，准备环境。安装Python 3.10以上版本，安装Ollama并把模型拉到本地，例如：

ollama pull qwen2.5:7b

再安装Python依赖：

pip install langchain chromadb sentence-transformers

这里插一句，模型拉取和依赖安装都比较常规，如果网络不稳定，优先检查本地环境是否已经具备离线安装包。断网环境下做好镜像源的本地缓存，能省很多折腾时间。

第二步，加载文档并按结构拆块。下面这段代码用LangChain的递归文本分割器，按章节和段落粒度切分：

from langchain_community.document_loaders import DirectoryLoader from langchain.text_splitter import RecursiveCharacterTextSplitter loader = DirectoryLoader("./docs", glob="**/*.md") documents = loader.load() splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=80, separators=["\n## ", "\n### ", "\n\n", "\n", "。", " "] ) chunks = splitter.split_documents(documents)

chunk_size设为500、overlap设为80是我在客服文档上反复试过的平衡点。500字大约是三四段对话或两三个FAQ的体量，足够模型理解上下文又不至于让片段本身包含太多无关信息。overlap的作用是避免某句话恰好被拦腰截断，让相邻块保留衔接信息。

第三步，向量化并写入向量库：

from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.vectorstores import Chroma embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5") vectorstore = Chroma.from_documents( documents=chunks, embedding=embeddings, persist_directory="./chroma_store" )

这里选的是BGE中文小模型，显存占用小，在客服语料上效果不错。向量库落盘到chroma_store目录，下次重启可以直接加载，不用重新向量化。

第四步，写检索和生成的完整链路：

from langchain_community.llms import Ollama from langchain.schema import SystemMessage, HumanMessage llm = Ollama(model="qwen2.5:7b", temperature=0.1) retriever = vectorstore.as_retriever(search_kwargs={"k": 5}) def answer(question: str) -> str: docs = retriever.invoke(question) context = "\n\n".join([doc.page_content for doc in docs]) messages = [ SystemMessage(content=( "你是一个客服机器人。请严格依据以下资料回答用户问题。" "如果资料中没有相关信息，请直接回答'抱歉，这个问题我暂时无法确认'。" "回答时尽量引用资料原话。\n\n资料：\n" + context )), HumanMessage(content="问题：" + question) ] return llm.invoke(messages)

temperature设成0.1，是为了让模型少一点“创造性”，多一点稳定性。客服回答不需要文采，只需要准确。

3.3 一次性建好知识库索引

实际项目中，知识库不是一次性建完就完事的。文档会更新，产品会迭代，FAQ会新增，所以索引必须支持增量更新。Chroma支持按文档ID添加和删除，我的习惯是给每个文档记录一个版本号或更新时间，启动时扫描源文件目录，发现文件变化就先删掉旧块再重新向量化，避免重复数据越积越多。

但增量更新有个容易踩的坑：如果文本拆解时chunk_overlap设计得不合理，同一个句子可能出现在两个块里，更新时只删了一个块，另一个块残留下来，检索时就会返回过期信息。解决办法是拆块时给每个块记录它在原文档中的起止位置，更新时按源文档ID连同所有子块一起清理。这个细节看起来小，不处理的话线上会偶发“机器人拿旧文档回答新问题”的诡异情况。

第4章 四个热词背后的进阶玩法

4.1 RAG的瓶颈，到底卡在哪

光把流程跑通不算完。我用了半年之后，才真正体会到热词里“RAG瓶颈”这四个字的分量。最典型的瓶颈有几个：

一是召回不完整。用户的问题表述和文档里的原话差别太大，向量检索召回的片段牛头不对马嘴，模型拿着无关资料自然答非所问。

二是片段之间缺乏全局关联。很多知识拆成一个个小块之后，彼此之间的逻辑关系就丢了。比如产品手册里说“开启自动续费后会产生扣费”，而退款政策里说“自动续费扣费后7天内可申请退款”，这两段信息分处不同章节，检索时可能只召回其中一段，模型就回答不了完整的判断。

三是上下文窗口限制。知识库里有十万个片段，但模型一次只能看五千字，能塞进去的非常有限，语义被压缩得厉害。

四是知识冲突。同一个问题的答案在不同文档里表述不一致，甚至新旧版本直接矛盾，模型不知道该听谁的。

这些瓶颈单靠调整提示词解决不了，必须从架构层面想办法。下一节我就说一种把知识之间的关系显式建模的方案。

4.2 从平面检索到本体与图谱

针对片段之间关联丢失的问题，业界的解法集中在“结构化知识”方向上。热词里提到的ontology RAG（本体RAG），本质上是先定义清楚领域里的核心概念、概念之间的层级关系、属性关系，再把文档内容和这些实体、关系对齐，最后检索时不仅查向量相似度，还会沿着知识图谱的关系边进行扩展检索。

拿客服场景举例：实体包括“产品”“订单”“退款”“保修政策”，关系包括“产品_属于_保修政策”“订单_发起_退款”“退款_依据_退款规则”。用户问“我上个月买的音箱坏了能换新吗”，传统RAG只检索“音箱”“坏了”“换新”这几个词附近的文本；GraphRAG或者ontology RAG则能通过“音箱—保修政策—换新规则”这条关系路径，把保修年限、换新条件、申请流程整串关联信息都带出来。

这种方案的代价是构建成本高，需要人工或半自动地整理领域本体。我的建议是：当你的知识库超过一万个文档、且文档之间交叉引用复杂时，再考虑引入图谱；如果只是几百篇FAQ，先别过度设计，保证基础的拆块和混合检索质量更重要。

4.3 从单轮问答到RAG智能体

热词里的“RAG智能体”也值得展开说。最早的RAG是单轮问答：问一个问题，检索一轮，回答一次。但真实的客服对话从来不是单轮的，用户会追问、会澄清、会换个角度再问。

RAG智能体的思路是：把检索工具化，让大模型自己决定什么时候检索、检索几次、怎么组合不同来源的信息。比如用户先问“路由器怎么设置”，模型检索出设置步骤，用户再问“那DDNS在哪里填”，模型需要先判断上一个答案里是否已经涉及DDNS，如果没有就再检索一轮，而不是直接拿上一轮的上下文硬答。

实现上，LangChain里用Agent结合Tool来搭，LangChain4j也有类似的原生支持。核心是把“知识库检索”定义成一个Tool，让模型在推理循环里按需调用。但这里必须强调：智能体式RAG对提示词和评估的要求远高于普通RAG，模型一旦在没有把握的情况下错误调用工具，反而可能把简单的问题复杂化。我在生产环境里的做法是：默认走单轮快速检索，只有在用户问题里出现“那”“然后”“具体呢”这类追问词时，才切换成多轮检索的智能体模式。

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

5.1 检索不到答案，怎么排查

这是被问得最多的问题。排查路径我一般按三步走：

第一步，直接把用户问题拿去检索，看看返回的Top 5片段里到底有没有正确答案。这一步可以绕过生成模型，单独暴露检索环节的问题。如果片段里没有正确答案，那就是索引或检索的问题，继续第二步。

第二步，检查chunk是否把关键信息切碎了。比如一段FAQ被切成两半，答案句被劈开，检索时匹配到的只有半句话。对策是调整chunk_overlap，或者改用按语义段落切分。

第三步，检查问题表述和文档用词是否差异过大。如果用户说“退货”，文档里写的是“退款申请”，向量模型可能没能拉近这两个语义。对策是补充同义词表，或者在检索前加一步“问题改写”，把口语问法改写成文档风格。

5.2 回答总是结巴、答非所问，怎么办

如果检索到的片段没问题，但生成出来的回答质量差，问题多半出在提示词和上下文组织上。我遇到最多的情况是塞进去的片段太多，模型注意力被稀释，反而抓不住重点。把k从10降到5，把每个片段用“标题：内容”的格式拼接，效果立竿见影。

还有一个隐藏问题：资料里的表述和用户问题的语体不一致。文档写的都是书面语，用户提问是口语，模型夹在中间就容易生成一段“半文半白”的尴尬回答。我的解决办法是在提示词里加一句“用口语化的中文，简短直接地回答用户”，然后用一批真实客服会话做回归测试，把提示词调到满意为止。

5.3 本地部署还要注意什么

本地RAG系统看着轻量，真要稳定跑起来，有几个点一定要提前规划。硬件方面，7B模型要流畅运行，16G内存起步，有条件的加一块8G以上显存的显卡，推理速度和体验完全是两个级别；没有GPU也能跑CPU版本，只是响应时间会慢不少。存储方面，向量库索引文件建议单独放一个磁盘目录，方便备份和迁移，别和日志混在一起。安全方面，本地部署的模型如果要在内网开放给其他同事使用，记得在服务入口加一层简单的鉴权，防止接口被滥用。Ollama自带的API本身没有鉴权机制，我习惯在前面挂一层轻量的网关来做控制。

5.4 一个容易被忽略的小细节：知识库的更新节奏

最后分享一个我踩过不止一次坑的教训：知识库更新不能只加新内容，还要定期清理已经废弃的旧文档。客服知识库最大的特点就是版本迭代快，上个月的政策文件这个月可能已经失效。如果你只做增量添加，不做过期资源清理，检索系统会逐渐被历史垃圾信息淹没，回答准确率会肉眼可见地下滑。

我的做法是每个月做一次文档盘点：把源文件目录里超过有效期或者被新文档取代的文件标记为废弃，在向量库里删除对应的块，然后重新跑一轮核心问题的回归测试。这个流程很笨，但确实能保证系统在长期运行中不“腐化”。做客服机器人，不是把RAG跑通就算完，能稳定地、不出错地服务用户一整年，才算真正的落地。

我个人在实际操作中的体会是：RAG项目的成败，百分之七十取决于数据工程，而不是模型选型。模型可以换、参数可以调，但知识库的拆块质量、检索的可靠性、提示词与真实业务场景的贴合度，这些都需要一版一版地打磨。别指望搭完第一天就完美，把线上用户的真实提问积累下来，隔一段时间回来看看机器人在哪些问题上翻了车，然后针对性调整拆块方式和提示词，这个循环本身才是RAG项目里最值钱的部分。