这两年找我打听本地知识库问答怎么落地的人明显变多了。场景几乎一模一样公司内网堆着几千份产品手册、制度文件、技术文档和历年会议纪要散落在共享盘各个角落搜索靠文件名找答案靠问老员工想上一套问一句就能定位到原文段落的问答系统但数据一条都不能出内网运维还得自己扛。这类需求落到具体形态上就是私有化部署一套本地知识库问答系统——把文档灌进去用检索增强生成的方式让模型基于原文回答答案带出处外网不通也能跑。为了方便叙述下文统一把这套模拟项目叫 Q-Base。这篇文章不讲概念科普只讲我从空白机器到服务可用这一路踩过的坑显存怎么算、切分参数怎么定、检索为什么召回不准、服务起不来先看哪里。刚接触这块的可以照着抄流程已经部署过但效果不理想的重点看第 4、5、6 章。1. 先把需求拆开私有化知识库问答到底在解决什么1.1 三个真实诉求决定了架构长什么样我接手这类项目的第一件事从来不是看机器配置而是把提需求的人拉到会议室问三个问题文档有多少、更新频率多高、答案允不允许编。这三个答案直接决定架构比任何技术选型文档都管用。第一个是数据边界。私有化部署的核心价值不是省钱而是数据不出内网。这意味着整条链路上的每一个组件——文档解析、向量化、检索、生成——都必须能在隔离环境里跑模型权重得提前离线备好依赖包得有内网源。我见过不少团队卡在这一步代码写完了发现模型下载不下来或者某个 Python 包在隔离环境里装不上硬生生拖了一周。第二个是更新频率。如果知识库半年才更新一次全量重建索引完全够用架构可以做得非常简单如果是每天新增几十份文档就必须设计增量更新和去重逻辑向量库要支持按文档 ID 删除否则旧版本内容会一直污染召回结果。这个差别在方案设计阶段就要定下来后期改代价很大。第三个最重要答案允不允许编。面向内部制度查询的场景不知道是完全可以接受甚至必须的答案但如果是客服对外场景答错的代价远高于答不出。前者可以在 prompt 里强约束只依据给定材料回答材料里没有就说没有后者则必须加重排和阈值卡控把低置信度的召回直接拦掉。这个决策直接影响第 5 章的调优方向。1.2 为什么不能直接调在线大模型接口每次讨论到这儿总有人问能不能文档解析和向量化放本地生成环节调在线接口技术上可行但绝大多数内网项目最后都否决了原因不复杂。一是数据出境问题。哪怕只把召回的几个片段发出去片段里也可能包含合同金额、客户名单、未公开的技术参数。一旦有人较真做审计这条链路就是过不去的。二是稳定性。内网环境往往没有稳定的外网出口就算有接口限流、超时、响应格式变动都会让线上服务莫名其妙挂掉排查起来极其被动。三是成本结构。按 token 计费看起来便宜但知识库场景的 prompt 特别长——每次问答要带 5 到 8 个召回片段加上系统提示和历史对话单次请求轻松上万 token日活一上来账单就很难看。所以最终方案还是全本地。代价是要自己扛硬件和推理性能但这部分成本是固定的、可预期的对内部系统来说反而更好做预算。1.3 六个模块组成的系统骨架Q-Base 这类系统的骨架其实很稳定拆开看就六层我把它们和对应的常见故障点放在一起你对照着看会更有感觉层级干什么常见故障解析层把 PDF/Word/Excel/PPT/图片转成纯文本扫描件无文字层、表格错行、编码乱码切分层把长文本切成带元数据的片段切太长召回不准切太碎丢上下文向量层文本转向量并建索引维度不匹配、索引重建慢、内存涨检索层向量召回 关键词召回 重排召回为空、排序错乱、阈值定错生成层拼 prompt 调本地模型输出答案显存溢出、超时、上下文截断应用层前端问答界面、文档管理、权限端口不通、上传大小限制、会话串号这六层里前两层最容易被低估。很多人以为部署难点在模型推理实际上线后效果不好八成问题出在解析和切分上——模型再强喂进去的是错乱的表格和断句它也答不对。1.4 一个容易被忽略的前置动作先做语料盘点正式动手前我建议花半天把要入库的文档过一遍按格式和状态分类统计。这一步不写代码但能省掉后面大量返工。具体做法是拉一个表统计每个格式有多少份、总大小多少、其中扫描件无文字层占多少、有没有加密、有没有超长文档单份超过 500 页的。这个统计的意义在于如果扫描件占比超过两成你就必须提前规划 OCR 环节而不是等用户上传后发现全是空白如果有大量 Excel就得决定表格是整表保留还是转成文本描述这两种处理方式对召回效果影响完全不同。我遇到过最典型的情况是一批老版 PDF用常规解析工具抽出来全是乱码原因是字体做了子集化嵌入。这类文档只能走 OCR 兜底事先不盘点上线当天就会炸。2. 硬件与环境的选型核算2.1 显存从参数规模倒推最省事显存是整个方案里最硬的约束算错了后面全是白搭。我用的估算方法很朴素先看模型参数规模再按精度折算权重占用最后加上上下文缓存和运行时开销。权重占用的折算关系是这样的FP16 精度下每个参数占 2 字节INT8 约 1 字节4bit 量化大约 0.5 到 0.7 字节取决于量化方案有没有保留部分高精度层。上下文缓存KV Cache跟并发数和上下文长度正相关粗略按权重的 20% 到 40% 预留。运行时还有框架本身的开销一般留 1 到 2 GB。按这个算法常见的几档配置大致是这样模型规模精度权重占用缓存与开销建议单卡显存7BFP16约 14 GB5 到 8 GB24 GB7B4bit约 5 GB3 到 4 GB12 GB14BFP16约 28 GB9 到 12 GB48 GB14B4bit约 10 GB5 到 7 GB24 GB32B4bit约 19 GB8 到 10 GB32 GB余量偏紧这里有个经验值标称 24 GB 的卡实际可用显存通常只有 23 GB 出头而且一旦接近上限推理框架会出现性能骤降甚至直接 OOM。所以我个人习惯是利用率不超过 85%也就是 24 GB 的卡按 20 GB 规划。这个保守设定在并发上来的时候能救命。另外别忘了向量模型和重排模型也要占显存。中文向量模型通常在一亿参数量级FP16 下两百多兆很小重排模型大致在几亿参数占一到两个 GB。这两块加起来不算大但如果你把它们和对话模型挤在同一张卡上就要从总额里扣掉。2.2 内存、存储与并发能力的估算显存之外内存和存储的账也要提前算不然跑起来会遇到莫名其妙的卡顿。内存主要被三样东西吃掉模型加载时的临时缓冲、向量库的索引常驻内存、以及文档解析时的文件缓冲。经验值是显存的 1.5 到 2 倍。比如单卡 24 GB 的机器建议至少配 64 GB 内存如果向量库选的是内存型索引并且数据量大128 GB 更稳妥。存储分两块算。原始文档按实际大小算但如果扫描件多要额外预留 OCR 产生的中间图片通常是原文件的 2 到 3 倍。向量数据按片段数算一个 1024 维的 float32 向量是 4 KB如果加 HNSW 索引索引本身还要再占 0.5 到 1 倍。举个例子10 万个片段大约需要 400 MB 原始向量加索引后 0.6 到 0.8 GB。这个量级其实很小绝大多数项目的瓶颈不在存储。并发能力要泼一盆冷水。单卡 24 GB 跑 7B 4bit 模型如果上下文控制在 8K 以内实际能撑住的并发问答大约在 2 到 5 路具体取决于输出长度——输出越长占用显卡的时间越久并发能力越低。内部系统几十个人的使用规模这个量级基本够用如果要面向几百人就得上多卡或者做请求排队。我的建议是在应用层加一个简单的队列超出并发上限的请求排队等待并给前端提示正在排队比直接超时体验好得多。2.3 软件栈的版本约束与踩坑点版本这块说多了都是泪。私有化环境最大的麻烦不是装不上而是装上了各种不兼容。容器运行时是基础建议用发行版自带的包管理器安装版本不要太新也不要太旧跟着官方文档的稳定版本来。GPU 驱动版本必须满足容器内 CUDA 运行时的最低要求这条是硬门槛——我遇到过驱动版本低了两个大版本容器起来后 GPU 完全不可见日志里只有一句语焉不详的报错排查了半天才发现是驱动问题。判断方法很简单起一个带 CUDA 的基础容器跑一下设备查询命令能列出来就说明链路通了。Python 环境建议用虚拟环境隔离别往系统 Python 里装。原因是向量库、推理框架、文档解析库这三个方向对依赖版本的要求经常打架比如解析库要某个版本的底层库推理框架要另一个版本混装必炸。我的做法是每个服务一个独立容器容器之间只通过 HTTP 通信把依赖冲突彻底隔离开。还有一个细节中文文档处理离不开字体。精简版基础镜像里通常没装中文字体PDF 转图片或者生成带中文的中间文件时会全是方块。这个坑我踩过不止一次建议在构建镜像时就装好常用中文字体别等出问题再补。3. 部署实操从空白机器到服务可用3.1 目录规划与端口分配动手前先把目录结构定好这个习惯能省掉后期很多麻烦。我习惯按数据、模型、配置、日志四分离的方式组织好处是备份和迁移的时候界限清晰不会把几十 GB 的模型权重和日志混在一起。/opt/qbase/ ├── models/ # 模型权重只读挂载 │ ├── chat/ # 对话模型 │ ├── embed/ # 向量模型 │ └── rerank/ # 重排模型 ├── data/ │ ├── uploads/ # 原始文档 │ ├── parsed/ # 解析后文本 │ └── vector/ # 向量库持久化目录 ├── config/ # 配置文件 └── logs/ # 各服务日志端口分配也要提前规划避免和机器上已有服务撞车。我的分配习惯是前端界面 8080主 API 服务 8000解析服务 8001向量库 6333模型推理服务 8002。定好之后写进配置所有服务通过内部网络名互相访问不要用 localhost——容器里的 localhost 指的是容器自己这是个新手常犯的错。3.2 模型权重的离线准备隔离环境拿不到外网模型权重只能提前准备好带进去。这一步的关键是在联网机器上把文件完整下载并校验再整体搬进去不要指望在目标机器上边下边装。要准备的权重有三类对话模型、向量模型、重排模型。对话模型体积最大7B 的 4bit 量化版本大约 4 到 5 GB向量模型和重排模型通常各几百兆到两 GB。全部加起来十几 GB 是常态用移动介质搬运时要留意文件系统对大文件的限制。搬运完成后一定要做完整性校验。我的做法是比对文件大小和哈希值任一项对不上就重新搬。这个步骤看着啰嗦但半路截断的权重文件在加载时往往只会报一个格式错误很难联想到是传输问题。另外提醒一句模型目录建议以只读方式挂载给容器。推理服务不需要写权限给它写权限反而增加了误删风险。3.3 配置文件与容器编排配置文件我倾向于用一份 YAML 集中管理把模型路径、端口、并发数、切分参数、检索参数全放进去各服务读同一份。这样调整参数不用改代码也方便做配置版本管理。下面是我常用的编排骨架做了简化重点是看结构services: api: image: qbase/api:1.0 ports: [8000:8000] volumes: - /opt/qbase/models:/models:ro - /opt/qbase/data:/data - /opt/qbase/config:/config:ro environment: - CHAT_MODEL_PATH/models/chat - EMBED_MODEL_PATH/models/embed - VECTOR_DB_URLhttp://vector:6333 - MAX_CONCURRENCY4 depends_on: [vector, infer] restart: unless-stopped infer: image: qbase/infer:1.0 ports: [8002:8002] volumes: - /opt/qbase/models:/models:ro environment: - GPU_MEMORY_UTILIZATION0.85 - MAX_MODEL_LEN8192 deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] vector: image: qbase/vector:1.0 ports: [6333:6333] volumes: - /opt/qbase/data/vector:/var/lib/vector restart: unless-stopped几个参数值得单独说。GPU_MEMORY_UTILIZATION就是我前面说的利用率上限设 0.85 是给突发请求留余量设 0.95 看着能用得更满实际一遇到长上下文就 OOM。MAX_MODEL_LEN是单次请求的最大上下文长度这个值决定了你能塞多少召回片段——设 8192 意味着 prompt 加输出总共不能超过 8K token超了会被截断截断的位置往往是召回材料的中后段表现出来就是答案只用了前面几份文档。3.4 起服务与健康检查的顺序启动顺序有讲究不能一把梭。我固定的顺序是向量库 → 推理服务 → 解析服务 → 主 API → 前端。先起向量库是因为主 API 启动时会尝试连接它建集合连不上会直接退出。推理服务其次因为它加载模型最慢7B 模型冷启动加上编译等一两分钟很正常让它在后台慢慢加载同时去起其他服务。主 API 要等前两个的健康检查都通过再起否则会反复重启。健康检查别只看容器状态是不是 running要看端口能不能通、接口能不能返回正常响应。我的习惯是主 API 起完后手动打一次健康接口再传一份最小的测试文档走完整流程——上传、解析、切分、向量化、检索、问答全链路跑通一遍确认没问题再去接真实数据。这个小文档我一般用两三页的产品说明格式简单但要包含一个表格因为表格是最容易出问题的结构。3.5 建库与首次问答验证服务全起来后第一件事是建知识库并灌入第一批文档。建议先用 20 到 50 份有代表性的文档做试点不要一上来就全量灌。原因是全量灌进去之后如果发现切分策略不对重建索引的时间成本很高试点阶段调整起来更快。首次问答验证要设计好测试问题不能随便问一句系统里有什么。我的测试集固定包含四类能直接在原文找到答案的事实型问题、需要跨两份文档综合的问题、原文里根本没有的问题、以及问法含糊的开放问题。这四类分别验证召回准确性、多文档融合能力、拒答能力和鲁棒性。第四类问题特别值得关注。用户真实提问往往很不规范比如问那个报销的流程——既没说是差旅报销还是费用报销也没说哪个版本。如果系统在这类问题上直接给出一个看似合理的答案风险比拒答大得多。我在 prompt 里通常加一条约束问题信息不足时先反问澄清而不是猜。4. 文档解析与切分召回率的地基4.1 解析层的格式坑与应对解析这一层的复杂度远超新人预期我按格式说几个高频问题。PDF 分两种。带文字层的 PDF 相对好处理但要注意排版顺序——双栏排版的文档常规解析器很容易把左右两栏的文字交错读出来结果就是句子全是断的。遇到这类文档可以开启版面分析或者干脆按区域切分后重排。不带文字层的扫描件必须走 OCR这里要提醒的是 OCR 对表格和手写体的识别率很低识别出来的内容如果不能人工校验宁可不入库——错误的内容比没有内容更危险。Word 和 PPT 相对友好但要注意批注和修订记录。有些文档的正文是干净的但修订记录里保留了大量删除内容解析器如果把这些也算进去向量库里就会存入一堆本该删掉的旧版本信息。Excel 是最麻烦的。整表直接转成文本几百行数据会变成一大坨没有语义的字符召回时基本命中不了但如果只取前几行又会丢失关键数据。我的处理方式是分两层表头和前若干行转成自然语言描述存入整表另外存档并在回答时提示完整数据见附表第 X 行。这样既保住了可检索性又没丢信息。这里有一条通用原则解析结果必须可追溯。每个片段都要能定位回原始文件的具体页码或段落编号用户点一下就能跳转到原文。这条不只是体验问题更是模型答错时的兜底手段——有了溯源用户能自己判断答案可不可信。4.2 切分策略与参数取值切分是整条链路里最需要经验的环节参数没有标准答案但有明确的调整方向。先说长度。片段太短比如一百字以内召回精度高但上下文不完整模型拿到的是半句话答出来也是残缺的片段太长比如一两千字向量会把太多主题平均掉导致检索时什么都像却什么都不准。我的经验区间是中文 400 到 600 字这个长度大约对应一到两个自然段既能容纳一个完整论述又不会混入太多主题。再说重叠。相邻片段之间要留重叠比例在 10% 到 15%也就是 400 字的片段留 40 到 60 字重叠。重叠的作用是防止一句话被拦腰截断——如果关键结论刚好跨在两个片段中间没有重叠就两边都召回不全。但重叠不能太高超过 25% 会导致重复内容大量入库检索时同一段话被召回好几次白白占掉宝贵的上下文预算。然后是切分单位。优先级应该是按文档结构切章、节、条款优先结构切不了再按段落切段落还太长才按句子长度硬切。硬切是最后手段因为它最容易破坏语义。我处理制度文件时特别注意这一点因为制度条款往往一条就是一个完整规则第 3.2 条被拆到两个片段里模型就可能给出错误结论。还有个细节是表格不能被拆开。一个表格跨页时解析出来往往是两段中间还夹着表头重复。这种情况要在解析阶段就做表格合并否则检索命中半张表答案必然是错的。4.3 元数据与权限设计片段入向量库时除了文本和向量还要带元数据。很多人只存一个文档 ID 就完事后面做权限和更新时就很痛苦。必要的元数据至少包括文档 ID、文档标题、所属目录或分类、页码或段落号、入库时间、文档版本。这几个字段支撑了三件事——溯源跳转、按范围过滤检索、增量更新时精确删除旧版本。权限这块要提前想。内部系统往往有部门隔离需求比如人事制度只对 HR 和管理层可见。实现方式不是靠 prompt 里说不要回答而是在检索阶段就加过滤条件把无权限的片段直接排除在候选之外。这个区别很重要靠 prompt 约束模型有可能被诱导绕过靠检索过滤数据根本没进上下文从根上就安全。5. 检索调优从能答到答得准5.1 向量模型的选型思路向量模型决定了语义相近这件事能不能被正确度量它的影响比对话模型更大。这一块的选型主要看三个维度。第一是中文能力。很多通用向量模型在英文基准上表现不错但中文的语序和表达习惯差异大尤其是长句和专业术语效果会明显打折。选择时优先看中文语义匹配的公开评测表现别只看总体排名。第二是维度。维度越高表达能力越强但存储和计算成本也上去了。1024 维是个比较平衡的选择768 维在资源紧张时也能用差距在我实测中不算大。要注意的是维度一旦定下来索引重建就得整体重来所以别随便换。第三是最大输入长度。向量模型能处理的文本长度必须覆盖你的片段长度如果模型只支持 512 token 而你的片段是 600 字超出的部分会被直接截断等于白切。这个细节很容易被忽略我在一个项目里就吃过亏——片段末尾的关键结论全部没进向量召回效果怎么调都上不去。还有一个实操建议向量模型一旦确定就别轻易换。换模型意味着全量重新向量化而且新旧向量不能混用必须整体重建索引。这个成本在文档量大时会非常可观。5.2 混合检索与重排的必要性纯向量检索有个天然短板对精确匹配不敏感。用户问一个具体的编号、型号、条款号向量检索可能召回一堆语义相近但编号不对的内容。所以工程上基本都用混合检索——向量召回负责语义相似关键词召回负责精确命中两路结果用倒数排名融合的方式合并。融合参数里有个关键值控制两路的权重配比。我的经验是关键词一路的权重在 0.3 左右比较合适太高会让语义匹配失效太低又起不到补精确匹配的作用。这个值需要按你的语料特点实测制度类文档可以调高一些技术文档可以调低。融合之后还要过一道重排。重排模型的作用是把召回结果按与问题的真实相关度重新排序它比向量相似度更精确但计算成本高所以只对前 20 到 30 条候选做重排最后取前 5 到 8 条送进生成模型。这道工序的效果提升非常明显我实测下来加了重排之后答案只用了次要文档、忽略了最相关文档的情况能减少一大半。代价是每次问答多几百毫秒延迟内部系统完全能接受。5.3 召回数量、阈值与上下文预算的平衡这里是最考验判断力的地方因为三个参数互相牵制。召回数量少了关键信息可能没被捞出来多了噪声会稀释模型的注意力还容易挤爆上下文。我通常把初始召回设为 20 到 30 条重排后保留 5 到 8 条这个区间在多数场景下比较稳。相似度阈值是过滤噪声的闸门但阈值的绝对值没有通用标准必须针对你选的向量模型实测标定。方法是拿一批已知答案的问题跑一遍看正确片段和无关片段的分值分布取两者之间的分界点。不同模型的分值尺度差异很大照搬别人的 0.8 大概率会全军覆没。上下文预算是硬约束。假设模型支持 8K token中文大致按 1 字 1 token 粗算那么 8192 token 里要扣掉系统提示约 300 到 500 token对话历史约 800 到 1500 token输出预留 800 到 1200 token剩下的才是能放召回材料的空间大约 5000 字。按每片段 500 字算最多放 10 条实际为了留余量我一般放 6 到 8 条。如果召回材料放不下绝对不能简单截断——截断的往往就是排在后面的次相关内容而正确答案可能恰好在里面。正确做法是在重排后按分数排序取前 N 条并且把每条都完整送进去宁可少放几条也不要放半条。6. 常见故障排查实录6.1 显存与模型加载类故障现象服务起来几分钟后自动退出日志显示显存不足。排查顺序是先看显卡当前占用确认是不是有残留进程没退干净再看配置里的利用率上限和最大上下文长度这两个值调大都会显著增加占用最后看并发数四路并发同时处理长上下文的峰值占用往往是最闲时的两倍以上。我遇到过最隐蔽的一次是模型加载成功、问答也正常但每隔几小时就崩一次。查下来是长文档上传时解析和向量化阶段也占用了显卡向量模型和对话模型同卡刚好和一波集中问答撞上瞬时超限。解决办法是把向量模型挪到 CPU 上跑——它的计算量小放 CPU 上慢一点但完全可接受把显卡整个让给对话模型。现象模型加载卡住不动日志没有明显报错。大概率是权重文件不完整或者路径挂载错了。先确认容器内能看到文件再核对文件大小。6.2 网络与端口类故障现象前端能打开但所有请求都超时。先在前端所在机器上直接请求后端的健康接口判断是后端挂了还是链路不通。如果后端容器内部请求正常、外部不通就是网络配置问题如果容器内部也不通就是服务本身没起来。一个高频错误是在配置里用 localhost 指向其他服务。容器内的 localhost 永远指向容器自己跨容器通信必须用编排文件里定义的服务名。这个问题在单机部署时特别容易犯因为本机跑脚本时用 localhost 是通的换成容器就断了。还有一个要注意的是跨域配置。前后端分离部署时如果后端没配允许的来源浏览器控制台会报跨域错误但接口本身是通的很多人会误以为是服务挂了。6.3 解析与编码类故障现象上传的中文文档解析出来全是问号或方块。这是编码问题。先确认文件本身是 UTF-8 还是 GBK再确认解析服务读文件的默认编码。我处理过一批老系统导出的文档全是 GBK 编码解析服务按 UTF-8 读中文全乱。解决办法是在解析前做编码探测按探测结果解码后再统一转成 UTF-8。现象PDF 解析出来是空的。八成是扫描件没有文字层。要确认是不是扫描件可以把页面渲染成图片看一眼。这类文档必须走 OCR没有别的捷径。现象表格内容错行、列错位。这是解析器对复杂表格结构识别不准。我的处理原则是结构规整的表格按行列重建跨页跨行合并的复杂表格直接转成图片存档同时在文本里写一段表格内容的自然语言摘要。宁可丢失一点精度也不要存入错乱数据。6.4 答非所问类故障这一类最需要耐心因为它不是坏了而是不够好。排查要分段定位先看召回结果里有没有正确答案所在的片段如果没有问题出在解析、切分或检索如果有但答案还是错的问题出在生成环节的 prompt 或上下文。召回为空或全是无关内容先检查切分长度片段过长是首要嫌疑再检查向量模型和片段长度是否匹配超长截断会让效果断崖式下跌最后检查知识库里是不是真的存在相关内容——有时候用户的问法和文档用词差异太大需要补充同义词或者调整关键词召回权重。召回了正确片段但答案引用错误多半是 prompt 约束不够。我会在系统提示里明确要求模型标注引用来源比如在结论后用括号注明依据的片段编号这样模型在生成时就不得不先确定依据编造的概率会明显下降。同一个问题时好时坏这种情况通常是生成参数不稳定。把温度调到接近 0让输出尽量确定同时固定上下文组装顺序排除随机性干扰。我把上面的问题整理成一张速查表出问题时按行对照现象首要怀疑快速验证方法服务自动退出显存超限查看崩溃前的显存峰值接口全超时容器间网络不通容器内直接请求目标服务中文全乱码文件编码非 UTF-8换一种编码重新解析对比解析结果为空扫描件无文字层渲染页面看图确认召回全无关切分过长或模型不匹配打印片段长度和向量维度答案忽略关键文档上下文截断或排序错误打印送进模型的完整 prompt同一问题结果飘忽生成温度过高温度设为 0 复测7. 上线之后的运维节奏7.1 日志与效果回归系统上线不是终点没有持续观测的知识库会慢慢退化。我固定看三类日志。第一类是问答日志重点记录问题、召回片段 ID、最终答案、用户反馈。这份数据是调优的唯一依据没有它所有优化都是拍脑袋。第二类是解析失败日志记录哪些文档解析出错、错在哪一步定期处理积压的失败文档。第三类是性能日志记录每次请求的耗时分解——解析、向量化、检索、重排、生成各占多少哪个环节慢就优化哪个。效果回归我建议建一个小型评测集从真实问答日志里挑 50 到 100 条有代表性的问题人工标注正确答案和依据片段。每次调整切分参数、换模型、改 prompt都跑一遍这个集子看命中率是涨了还是跌了。没有这个集子你永远不知道自己的优化到底是优化还是劣化——我就有过调完参数自我感觉良好、结果一跑评测集发现整体下降了 8 个点的经历。7.2 增量更新与版本回滚文档会不断新增和修订增量更新的设计要一开始就做好。新增好办解析、切分、向量化、入库走一遍正常流程即可。麻烦的是修订同一份文档更新后旧版本的片段必须从向量库里精确删除否则新旧内容会同时被召回模型可能拿旧规定回答新问题。删除的依据就是入库时存的文档 ID 加版本号这也是我前面强调元数据要带版本的原因。删除操作要有保护机制。我的做法是先按条件查询出待删除片段的数量确认无误再执行删除删完立刻做一次检索验证。批量操作的脚本一定要先在测试库上跑一遍向量库误删之后恢复起来非常麻烦。回滚能力同样重要。模型升级、参数调整都可能让效果变差能快速切回上一个可用版本是底线。实现方式很简单模型目录按版本分文件夹配置里指向当前版本回滚时改配置重启即可。多花几十 GB 磁盘换这个能力我觉得非常值得。最后分享一个我在多个项目里反复验证过的小经验这套系统上线初期用户最容易抱怨的不是回答质量而是不知道它能回答什么。所以在问答界面旁边放一组示例问题和可检索的文档范围说明比任何算法优化都更能提升实际使用率。系统好不好用第一周的用户体验决定了它能不能活下来。