企业官网建设流程全解析

做知识库这件事，我在过去三年里前前后后折腾过七八套方案：有装在笔记本上当玩具跑的桌面端，也有给几十人团队做内部问答的私有化集群。踩过的坑从“PDF解析出一堆乱码”到“上线三个月没人用”都有。2026年这个节点回头看，AI知识库这条赛道已经明显分层了——轻量工具卷的是“开箱即用”，企业级平台卷的是“权限、审计和可观测”。你要是一上来就拿着企业级的思路去解个人需求，纯属给自己找罪受；反过来，用桌面小工具去承接公司制度问答，早晚要出事。

这份清单我不打算写成产品发布会通稿，而是按“谁在用、解决什么问题、代价是什么”三个维度，把从轻量工具到企业级平台的代表产品捋一遍，顺带把几个高频难题讲透：AI知识库怎么解析Word和PDF、代码类知识库怎么积累、skills到底是个什么东西、Spring AI 加 RAG 怎么搭一条能跑通的最小问答链路。不管你是刚想给自己攒个第二大脑的个人用户，还是正在给团队做技术选型的负责人，都能在下面找到能直接抄的部分。

1. 先搞清楚知识库分层的底层逻辑

1.1 从“能问答”到“能干活”，产品形态被需求硬生生掰弯了

早期的AI知识库基本就是一个套壳：把文档丢进向量库，用户提问就检索几段塞进提示词，让模型总结一下。这个形态在2023年够用，因为当时的期待值本来就低，能答上来就算赢。问题出在真正落地的时候——用户问“这个流程走完要几天”，知识库里躺着三份不同年份的制度文件，模型检索到哪份全凭运气，答出来的数字今天一个样明天另一个样。这种不确定性一旦出现在报销、法务、运维这类场景，工具立刻失去信任。

于是2024到2026这两年，产品形态被需求掰弯成了两条路线。一条路线往“轻”里走，主打本地优先、单机可跑、文档拖进去就能问，代表就是各类桌面客户端和笔记软件内置的AI能力；另一条往“重”里走，把权限体系、版本管理、检索评估、调用审计这些企业IT部门才关心的东西做进产品，代价是部署复杂度和成本上去了。中间地带的产品活得最难受，既没有轻量工具的零门槛，又没有企业平台的治理能力，通常撑不过两年。

理解这个分层，你选型的时候就不会被“功能列表”忽悠。一个只有五个人的小团队，真正需要的可能是“把散落在飞书云文档里的周报和会议纪要串起来能问”，而不是一套要配三台服务器、还要专人维护的检索系统。

1.2 三类使用者的真实需求差异，比产品文档写的大得多

我把使用者粗分成三类，这三类的诉求几乎没有交集。第一类是个人用户，知识库内容以读书笔记、行业资料、个人文档为主，核心诉求是“找得到”和“不泄露”，对响应速度和并发毫无概念，最在意的是安装包多大、要不要显卡、会不会偷偷上传数据。第二类是小团队，通常十到五十人，内容集中在产品文档、客服话术、项目复盘，核心诉求是“答案一致”和“新人能自助”，最烦的是每次文档更新要手动重新导入。第三类是中大型组织，内容横跨制度、研发、售前售后，核心诉求变成了“谁能看什么”“改动有没有留痕”“出问题怎么定位”，性能和成本反而排在后面。

这三类需求的差异直接决定了技术选型。个人用户装个桌面端就完事，甚至连向量库都不需要，用本地关键词加小模型就够。小团队需要一个能定时同步、支持多人访问的服务，向量库选pgvector这种能跟业务库混用的最省事。中大型组织必须考虑多租户隔离、文档级权限继承、检索质量可量化，向量库往往要单独部署一套，检索链路里还得加一层重排。

提示：选型之前先写清楚“谁在什么场景下问什么问题”，这句话比任何功能对照表都管用。我见过太多团队照着评测榜单买工具，结果真实高频问题只有十几个，全被产品的高级功能覆盖不到。

1.3 关键词背后的技术栈，其实就那几块拼图

不管产品叫什么名字，一个AI知识库内部基本由四块拼图组成：文档加载与解析、文本切分与清洗、向量化与索引、检索增强与生成。轻量工具和企业平台的区别不在拼图本身，而在这四块拼图的工程化程度。解析环节，轻量工具可能只支持txt和md，企业平台要啃得动扫描件、多栏排版、带公式的PDF；切分环节，轻量工具用固定长度切，企业平台要按标题层级和语义边界切；向量化环节差异最小，因为大家用的都是那几个开源嵌入模型；检索增强环节差异最大，企业平台会加混合检索、重排、多路召回融合，轻量工具通常只有一路向量检索。

把这个拼图记住，你看任何产品的介绍都能快速判断它处在哪个段位。比如一个产品宣传“支持一百种文件格式”，那它的强项在解析层；宣传“检索准确率提升百分之四十”，那它的功夫花在检索增强层；宣传“三分钟部署”，那它大概率把前三块拼图都做了简化，用体验换门槛。

2. 轻量工具梯队：一个人也能当天跑起来的那批

2.1 桌面端本地知识库，主打数据不出机器

桌面端这一类是我最推荐新手入门的，原因是试错成本几乎为零。这类工具的形态高度相似：一个安装包，一个本地模型或者让你填API地址，一个文档导入区，然后在聊天框里提问。内容存在本机，向量索引也落在本地磁盘，断网也能用，隐私敏感的材料丢进去心里踏实。

代表形态有几个方向。一类是通用型的本地对话客户端，把模型接入、知识库、提示词模板全塞进一个图形界面，导入PDF和Word后自动走一遍解析和切分，你不需要懂任何参数。另一类是笔记软件长出来的AI能力，你的笔记本身就是知识库，AI直接在笔记库里检索，好处是内容天然有结构，坏处是格式支持受限于笔记软件本身。

这类工具的通病也很明确。第一是解析质量参差，尤其是PDF，遇到扫描件基本只能识别文字，表格结构大概率丢失。第二是切分策略固定，用户改不了，长文档经常被从句子中间劈开。第三是并发能力弱，一个人用没问题，两个人同时问就开始转圈。我的建议是把它们当“个人检索增强版搜索”来用，别指望它回答需要跨十几份文档推理的复杂问题。

2.2 笔记与协同文档自带的AI，胜在内容本来就整齐

如果你的知识本来就沉淀在协同文档里，那最有性价比的方案往往不是另起炉灶，而是直接用文档平台自带的AI能力。飞书云文档这类平台这几年在知识库方向投入不小，核心优势是它知道文档的层级结构：哪个是父页面、哪个是子页面、哪个是表格、哪个是代码块。这些结构信息对检索质量的影响，比换一个更强的嵌入模型还大。

具体来说，文档平台的AI能拿到普通解析器拿不到的东西。标题层级可以直接当切分边界，表格可以整块保留而不是被拆成散落的单元格文本，代码块可以单独走一套处理逻辑。用户在提问时，平台还能结合访问权限做过滤，你问的问题如果涉及你没权限看的文档，它压根不会检索到。这一点是外部工具很难做到的，因为外部工具同步文档时通常只能拿到一份扁平化的文本。

代价是绑定。内容一旦深度依赖某个平台的AI能力，迁移成本就会上去。我一般的做法是：日常协作用平台自带AI，核心资产同时在本地留一份纯文本或者Markdown备份，两边都跑，谁好用谁。

2.3 轻量工具选型对照，别只看功能数量

这张表我想强调一句：功能数量是最不值得看的指标。我见过一个轻量服务型产品支持二十种文件格式，结果PDF解析出来的文本顺序全是乱的，双栏排版被拼成一句话，实际可用性还不如只支持Markdown的工具。

2.4 实操：十分钟搭一个能吃Word和PDF的本地问答

拿最常见的组合举例：本地跑一个嵌入模型，向量库用文件型的，前端用现成的客户端。下面是我自己在用的流程，改一下路径就能复现。

第一步，准备文档目录，把Word和PDF按主题分文件夹。这一步别偷懒，分类清晰能让后面的检索过滤省很多事。

第二步，装解析依赖。Python环境下：

pip install pymupdf python-docx langchain-text-splitters sentence-transformers

第三步，把PDF和Word统一转成纯文本，带上来源元数据：

import fitz from docx import Document from pathlib import Path def load_pdf(path): doc = fitz.open(path) pages = [] for i, page in enumerate(doc): pages.append({"text": page.get_text("text"), "page": i + 1}) return pages def load_docx(path): d = Document(path) parts = [p.text for p in d.paragraphs if p.text.strip()] for table in d.tables: for row in table.rows: parts.append(" | ".join(c.text.strip() for c in row.cells)) return [{"text": "\n".join(parts), "page": 1}] def build_corpus(root): items = [] for p in Path(root).rglob("*"): if p.suffix.lower() == ".pdf": chunks = load_pdf(p) elif p.suffix.lower() in (".docx", ".doc"): chunks = load_docx(p) else: continue for c in chunks: items.append({"text": c["text"], "source": p.name, "page": c["page"]}) return items

第四步，切分。这里用带重叠的递归切分，中文场景下分隔符要额外加上中文标点：

from langchain_text_splitters import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=600, chunk_overlap=120, separators=["\n\n", "\n", "。", "；", "，", " ", ""], length_function=len, )

chunk_size=600这个数不是拍脑袋定的。中文一个汉字大约对应一到两个token，600字大概落在800到1200token之间，正好是主流嵌入模型有效语义窗口的舒适区。chunk_overlap=120取的是切分长度的百分之二十，目的是防止关键信息正好被切断在边界上。这两个参数我试过512/64和1000/200，前者召回太碎，后者噪声太多，600/120最均衡。

第五步，向量化并落盘，然后接一个聊天界面提问。这一步各客户端都有现成入口，把上面的语料喂进去即可。

注意：Word里的批注、修订记录、页眉页脚通常会被解析器一并抓出来，变成噪声。导入前用脚本清一遍，或者干脆导出成纯净版再入库，检索准确率的提升立竿见影。

3. 文档解析这道坎：AI知识库到底怎么啃Word和PDF

3.1 PDF难在三六九等，不是难在“格式”

很多人以为PDF解析难是因为格式复杂，其实真正的问题是PDF压根没有“段落”这个概念。它内部是一堆带坐标的字符绘制指令，你看到的段落是人眼根据位置脑补出来的。所以解析器必须反过来推算：哪些字符在同一行、行间距多少算分段、两栏排版怎么读顺序。这个推算的质量，直接决定后续检索的上限。

我把常见的PDF分成三档。第一档是原生电子版，文字可选可复制，元数据完整，这类用常规解析器就能拿到不错的结果，主要问题是表格和多栏。第二档是扫描件，本质是图片，必须走OCR，识别错误率取决于清晰度和字体。第三档最麻烦，是混排文档，部分页面是原生文字、部分是扫描图片，还夹杂公式和图表，需要逐页判断类型再分派处理。

选解析方案之前，先抽样看几页你的真实文档。如果全是第一档，PyMuPDF这类库足够；如果有扫描件，就得引入OCR能力，MinerU、PaddleOCR这类方案在中文场景下表现比较稳；如果文档里有大量表格和公式，那基本只能上专门的文档解析模型，通用库会丢结构。

3.2 解析链路的完整拆解：加载、清洗、切分、向量化

一条完整的入库链路有四步，每一步都有独立的失败模式，排查的时候要分开看，别一锅炖。

加载这一步的目标是“把字节流变成带元数据的文本块”。元数据至少包含来源文件名、页码、章节路径，后面做引用溯源和权限过滤全靠它。很多人跳过元数据，结果答案答错的时候根本查不出引用了哪一段，这在企业场景里是致命的。

清洗这一步的目标是“去掉噪声、保留结构”。要去的东西包括页眉页脚、重复的免责声明、目录页码、孤立的水印文字。要保留的东西包括标题层级、列表序号、表格结构。这一步没有通用方案，必须针对自己的文档写规则，我一般会先dump出一份原始解析结果，人工翻二十页找规律，再写正则。

切分这一步的目标是“让每个块自包含”。理想状态下，一个块脱离原文也能被读懂，因为它带着完整的小节标题和上下文。实现方式有两种：一种是按语义边界切，比如按标题层级先分大节，大节超长再按段落切；另一种是按固定长度加重叠切。前者质量高但实现麻烦，后者简单但对长文档不友好。我的做法是混合：先用标题做一级切分，一级块超过阈值再用固定长度二次切分，同时把标题路径拼在每个子块的开头。

向量化这一步相对标准化，选一个中文表现好的嵌入模型即可。需要注意的是维度和成本的权衡：维度越高表达能力越强，但存储和检索开销也越大。1024维在多数中文场景下是性价比比较好的选择。

3.3 切分参数怎么定，附一份可直接用的对照表

这份表是我踩坑之后总结的，重点在最后一列。制度规范类如果不保留条款编号，模型回答“依据第几条”时就只能胡编；技术文档如果不把代码块单独成块，代码容易被切碎导致语义全丢；客服话术如果把问题和答案分开切，检索到的永远是半个回合。

还有一个容易被忽略的点：块长度要跟你的检索条数配合。如果一次只召回3条，块太小会导致信息不全，块太大又会引入噪声。我通常的做法是先按上表定块长度，然后把召回条数设成5到8条，最后根据实测效果微调，别一次把两个变量同时改，否则你根本不知道是谁起的作用。

3.4 表格、扫描件、多栏排版，三个老大难的处理技巧

先说表格。通用解析器处理表格基本两种结果：要么整张丢，要么拆成一行行的文本，表头信息全没了。可行的做法是解析时检测表格区域，把表格转成Markdown格式再入库，这样行列关系能保留。如果表格特别多，就在每个表格前补一句“下表为某某数据”，让检索时有上下文可抓。

再说扫描件。OCR的准确率对结果影响巨大，我的经验是：预处理比换引擎更值钱。把图片先做一遍二值化和倾斜校正，识别率能提明显一截。另外扫描件识别完一定要做后处理，把常见的形近字错误列表拿出来做替换，比如数字和字母混淆的情况。

最后说多栏排版。这是PDF解析最容易翻车的地方，因为解析器按坐标排序，很容易把左栏和右栏的文字交错拼在一起，读起来像天书。判断方法很简单：解析完随便找一页看文本顺序，如果段落之间语义跳跃，基本就是多栏问题。解决思路是先做版面分析，识别出分栏边界，再按栏分别提取文本，最后拼接。这一步如果自己实现成本高，用带版面分析能力的解析工具会省很多事。

提示：不管用什么解析方案，都建议保留一份原始文件和一份解析结果的对照。我习惯把解析后的文本按页码存成单独文件，出问题时能快速定位是解析错了还是检索错了，这个习惯帮我省过无数次返工。

4. 企业级平台：真正的门槛在治理不在检索

4.1 企业级选型的六个硬指标

个人工具看体验，企业平台看治理。我评估一个平台能不能进企业环境，主要盯六个指标，缺一个都会在后期变成麻烦。

第一是权限继承。知识库的权限必须能跟现有文档系统的权限对齐，用户在文档系统看不到的文件，在知识库问答里也不能被检索到。这个能力如果靠知识库自己维护一套权限表，迟早会跟源头数据不一致。

第二是多租户隔离。不同部门之间的数据要能隔离，至少检索层要隔离，不然售前问出来的答案被研发看到就是事故。

第三是变更留痕。谁在什么时候导入了什么文档、谁问了什么问题、系统引用了哪些片段，这些都要能查。合规场景下这是硬要求。

第四是检索质量可量化。平台得提供评估能力，让你能拿一批标准问题跑一遍，看到命中率和准确率的变化，否则优化全靠感觉。

第五是可观测性。响应延迟、失败率、token消耗这些指标要能看到，线上出问题才能定位。

第六是数据脱敏。敏感字段在入库前要能被识别和替换，尤其是当知识库要对接外部模型的时候。

这六条听起来像老生常谈，但真正落到选型时，能同时满足的产品并不多。很多平台在演示环境里检索效果惊艳，一接入真实权限体系就各种漏。

4.2 代表平台横向对照，按场景挑不按排名挑

挑平台的时候，我建议按“你的内容在哪、你的用户是谁、你的运维能力如何”三个问题依次筛。内容已经在某个协同平台，优先用内置能力；用户在内部且对数据敏感，优先私有化；运维只有一两个人，就别选自建方案，否则三个月后系统没人管。

4.3 私有化部署的成本账，先算清楚再动手

私有化部署的隐性成本比大多数人预估的高。我把主要开销列一下，给准备立项的人一个参照。算力方面，嵌入模型和重排模型如果自己跑，一张中端显卡能扛住小规模并发，但检索高峰期延迟会明显上升；如果调用外部API，成本随调用量线性增长，得估算日均问答量。存储方面，向量索引的体积大约是原始文本的几倍，加上原文和解析中间产物，一百GB原始文档可能要预留三到五百GB。人力方面，这是最容易被低估的，解析规则的维护、模型的定期评估、版本升级，基本需要半个到一个人力长期投入。

我的建议是分两步走：先用轻量方案做一个小范围试点，把高频问题收集起来，验证价值；确认有价值之后再上企业平台，而且优先选能平滑迁移的，避免第二次从零开始。

5. 代码知识库怎么积累，给研发团队的一套打法

5.1 代码库和文档库的本质差异在哪

拿文档库的思路做代码知识库，基本都会失败。原因有三点。代码的语义单元不是段落而是符号，一个函数、一个类、一个接口才是完整单元，按固定长度切代码会切出一堆无法编译的碎片。代码的更新频率远高于文档，一次提交可能改动几十个文件，知识库如果跟不上就会给出过期答案。代码的价值密度不均匀，有些文件是自动生成的，有些是历史遗留，真正值得进知识库的可能只占一部分。

所以代码知识库的第一步不是选工具，而是定范围。我一般建议先纳入三类内容：核心模块的接口定义和调用示例、高频问题的排查记录、架构决策的说明文档。自动生成的代码和历史归档代码先排除，等主线跑通再说。

5.2 积累策略：从提交记录到评审评论，哪里有信息就捞哪里

代码知识库最大的价值来源其实不是代码本身，而是围绕代码产生的那些文本。提交信息里往往写着“为什么这么改”，这是代码里看不到的；代码评审评论里常常藏着踩坑经验，比如“这里不能这么写，某个场景下会死锁”；问题跟踪系统里的讨论，记录了一个bug从发现到修复的完整推理链。这三类内容如果能被收集进知识库，回答“这个模块为什么这么设计”这类问题的质量会高一个档次。

具体做法上，我建议按下面的顺序推进。先把提交信息和关联的问题单编号建立起映射，这样检索时能从代码定位到讨论。再把评审评论按文件路径聚合，附在对应模块的说明后面。最后补一份人工维护的架构说明，把散落的信息串成线。这三步做完，你会发现知识库已经能回答相当一部分新人问题了。

代码本身的处理，关键是按符号切而不是按行切。用语法解析工具把源文件拆成函数、类、接口级别的单元，每个单元带上文件路径、所属包、依赖的接口名。这样检索“怎么调用某个服务”的时候，能精准定位到示例代码而不是整段文件。

5.3 skills落地：把知识库封装成可调用的能力包

skills这个概念今年被提得很多，本质是把“某类任务的处理流程加所需知识”打包成一个可复用的单元。放到知识库场景里，它的价值在于把检索从“每次现场拼提示词”变成“调用一个已经调好的技能”。

一个典型的技能包通常包含三部分：一份说明文件，写清楚这个技能解决什么问题、需要哪些输入、输出什么格式；一组示例问答，用来做少样本提示；一份专属的知识片段集合，跟通用知识库分开存。这样当用户触发某类任务时，系统直接加载对应的技能包，检索范围被限定在相关片段里，准确率和速度都会好很多。

我实际用下来的感受是：技能包最适合那些流程固定、术语密集的场景，比如财务口径解释、故障定级标准、接口参数校验规则。反过来，开放式的研究型问题不适合做成技能，因为边界太模糊，限定检索范围反而会漏掉关键信息。

6. Spring AI 加 RAG 的一条最小可跑链路

6.1 技术栈与依赖，先说清楚为什么选这套

选Spring AI做RAG，主要理由是它跟现有Java技术栈的融合度高。多数企业后端的业务系统本来就在Spring生态里，引入一个检索问答能力，如果还要单独维护一套Python服务，运维复杂度会翻倍。Spring AI把模型调用、向量存储、检索增强这几块做成了统一的抽象，切换模型供应商时改动量很小。

核心依赖大致是这些：

<dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-model-openai</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-starter-vector-store-pgvector</artifactId> </dependency> <dependency> <groupId>org.springframework.ai</groupId> <artifactId>spring-ai-tika-document-reader</artifactId> </dependency>

选pgvector而不是独立向量库，是因为业务数据本来就在PostgreSQL里，向量和结构化数据放一起，做权限过滤和联合查询时能直接写SQL，省掉一层跨系统同步。数据量在千万级向量以内，这个选择都很稳。

配置项：

spring: ai: openai: api-key: ${API_KEY} embedding: options: model: text-embedding-3-small vectorstore: pgvector: index-type: hnsw distance-type: cosine_distance dimensions: 1536

hnsw索引在数据量增长后检索延迟明显优于默认的暴力检索，代价是建索引时间和内存占用高一些。cosine_distance适合文本语义相似度，别用欧氏距离，文本向量的模长差异会影响结果。

6.2 关键实现：加载、切分、入库、检索四步

向量库配置：

@Bean VectorStore vectorStore(JdbcTemplate jdbcTemplate, EmbeddingModel embeddingModel) { return PgVectorStore.builder(jdbcTemplate, embeddingModel) .dimensions(1536) .distanceType(PgVectorStore.PgDistanceType.COSINE_DISTANCE) .indexType(PgVectorStore.PgIndexType.HNSW) .build(); }

文档入库，注意切分参数要跟前面讲的一致：

public void ingest(Resource resource, String docId) { var reader = new TikaDocumentReader(resource); List<Document> raw = reader.get(); var splitter = new TokenTextSplitter(600, 120, 5, 10000, true); List<Document> chunks = splitter.apply(raw); for (int i = 0; i < chunks.size(); i++) { chunks.get(i).getMetadata().put("doc_id", docId); chunks.get(i).getMetadata().put("chunk_index", i); } vectorStore.add(chunks); }

TokenTextSplitter的五个参数依次是最小块大小、重叠大小、最小块字符数下限、最大块字符数上限、是否保留分隔符。第三和第四个参数用来过滤掉过短的碎片和异常超长的块，实际调参时这两个值能挡掉不少脏数据。

问答部分，用检索增强的顾问组件把检索逻辑挂到对话客户端上：

ChatClient chatClient = ChatClient.builder(chatModel) .defaultAdvisors(QuestionAnswerAdvisor.builder(vectorStore) .searchRequest(SearchRequest.builder() .topK(6) .similarityThreshold(0.45) .filterExpression("doc_id == 'handbook'") .build()) .build()) .build(); String answer = chatClient.prompt() .user("出差住宿的报销上限是多少？") .call() .content();

这里三个参数值得解释。topK=6是召回条数，取太小信息不全，取太大噪声多，6是我在文档类场景下实测比较稳的值。similarityThreshold=0.45是相似度阈值，低于这个分数的片段直接丢弃，宁可答“资料里没找到”也不要拿不相关内容凑数。filterExpression是元数据过滤，这里按文档编号限定范围，企业场景里换成部门或者权限标签就能实现数据隔离。

6.3 效果评估和参数调优，别靠感觉

上线前一定要建一个小评估集。做法很简单：从真实问题里挑三十到五十条，人工标注每条应该引用哪个文档的哪一段，然后跑一遍看命中率。这个集合建一次能反复用，每次改参数或者换模型都跑一次，你才能知道改动到底是变好还是变坏。

调优的顺序我建议是这样的。先看召回条数够不够，如果标准答案所在的片段压根没被召回来，说明是切分或者嵌入的问题，调阈值和提示词都没用。再看召回顺序对不对，正确答案排在第五位而模型只看了前三条，那就加一层重排，把相关度高的提到前面。最后才调提示词，让模型更严格地依据检索内容作答，明确要求“资料中没有提及的内容不要编造”。这个顺序很重要，很多人在提示词上反复打磨，却不知道问题出在根本没召回。

7. 常见问题与排查速查

7.1 检索不到答案的六种原因，按概率从高到低排

这张表里最值得说的是第三行。纯向量检索对专有名词、型号、编号这类信息的匹配能力天然偏弱，因为嵌入模型关注的是语义而不是字面。解决办法是加一路基于关键词的检索，两路结果做融合。融合算法用倒数排序融合就够，不需要多复杂，效果比单路明显。

7.2 答非所问和胡编乱造的排查顺序

模型编造答案，八成不是模型的问题。排查顺序建议是：先看检索内容里有没有正确答案，如果没有，那是检索的锅，回去调切分和召回；如果有但模型没用，那是提示词的锅，明确要求基于给定资料作答并标注引用来源；如果检索内容本身就有矛盾，那是数据治理的锅，得先解决文档版本冲突。

我在实际项目里遇到最多的是第三种。同一个制度有两个版本同时在库里，模型一会儿引用新版一会儿引用旧版。解决方式是在元数据里加生效日期和版本号，检索时按日期过滤只保留有效版本，或者在提示词里明确优先级规则。

还有一个小技巧：让模型在回答时输出引用的块编号，前端把这些编号映射回原文链接。这样用户能自己核实，信任度会高很多，同时也方便你排查问题。

7.3 性能和成本问题的几个实操经验

响应慢通常卡在两个地方：嵌入计算和模型生成。嵌入可以批量处理并缓存，同一段文本不要重复算。生成阶段的延迟主要取决于输出长度，如果能接受摘要式回答，在提示词里限制字数能明显加快。检索阶段如果用了重排模型，注意它是串行调用的，召回条数越多延迟越高，topK别设太大。

成本控制上，我一般会做三件事。第一，对高频问题做结果缓存，相同或高度相似的问题直接返回缓存答案。第二，对小模型能答好的问题路由到小模型，只有复杂问题才用大模型。第三，定期清理向量库里的过期文档，很多成本是陈年垃圾数据带来的。

注意：缓存要设置合理的失效时间，并在知识库内容更新时主动清理相关缓存，否则会出现文档已经改了但用户拿到的还是旧答案的情况，这种问题极难排查，因为复现不了。

最后分享一个我自己的小习惯：每次知识库上线前，我会找三个完全不了解业务的人来问二十分钟问题，把他们的提问原封不动记录下来。这批问题往往比内部同事想出来的更贴近真实使用场景，因为内部人知道系统能答什么，会不自觉地绕开难点。这份记录后来成了我最有价值的评估集，比任何自动化测试都管用。