专题 · Deep Dive
把散在说明书、操作手册、故障处理和业务规范里的知识，变成一个能直接问、答案还能查到是哪份文档第几章的知识入口——先解决「知识从哪里来」，后面的业务查询和 Copilot 用的都是这一层。
给要在企业文档堆上做 RAG 问答的工程同学：不止讲三层怎么分，每一层都落到具体组件与参数——解析用什么、切到多长、向量多少维、召回几条、阈值怎么定。这套口径是通用的，换掉「无人机」三个字，任何企业知识库都能照着落地。
问一句能答，答了能翻回原文哪一章。
一条链平台先解决的是「能不能飞」。等真跑起来，卡点变成另一件事：一线不知道该怎么办。这一期的起点不是选什么技术，是答疑一天被打断几十次。
设备、航线、工单、巡检记录都在系统里。能做的事都有，出问题的是「这种情况该怎么办」这句话没人答得上——机型手册、操作规范、故障处理、业务规范分别躺在网盘、群文件和纸质扫描件里，同一个故障有两份版本不一致的处置说明。
「失联以后应该怎么处理」这句话在文档里没有原文对应，靠人翻目录、靠熟手指路。答疑集中在少数几个熟手身上，一天被打断几十次；更麻烦的是回答没有出处，同一个人今天一个说法明天一个说法，出了事没人能回查当时到底答了什么。
让 AI 替人操作平台之前，先解决「问一句能答、答了能翻回原文哪一章」。这一层不稳，后面每一步都不稳。
「文档多、检索难」不叫问题。拆开是三件事，每件事都有自己的出错方式；04 架构里那几层，就是照着这三件事摆的。
同一份内容有三种载体（Word / PDF / 扫描件）。PDF 还带目录页与页眉页脚，直接按页抽文本会把「保密声明」当成正文喂给模型。按字数一刀切又会把「前置条件」和「操作步骤」切成两块——答案少了前面那句限定，读起来照样通顺，照着做会炸机。
纯关键词搜不到同义说法（「失联」对「链路中断」）；纯向量搜不到型号、编号、代码这类必须精确命中的串。而向量、原文、元数据分开存，就得额外维护它们一致：每多引一个中间件，就多一套权限、备份、升级和对账。
答案没有出处，没人敢照着它去动设备——所以出处不是加分项，是这条链路能不能上生产的门槛。手里没有一批真实问题，也说不清这次改动是变好了还是碰巧对上了，调优最后就变成改改看。
三条，按顺序来：先让一线问得出答案，再让他们信这个答案，最后让我们自己改得动。
一线说的是机器在什么情况下报什么错，不是文档标题。要把这句大白话搜成对的内容，不能要求提问的人先搞懂文档是怎么分类的。
找不着依据就直接说找不着，别让模型编一段看着像的话。能指出哪份文档第几章，一线才敢照着做。
先攒一批真实问题当考卷。每次改完再考一遍，才知道是变好了还是变坏了。没有这张考卷，全靠感觉。
走一遍最能代表系统价值的路径。这条顺序同时也是排查效果问题的检查顺序——答案不对，就沿它往回找。
把分散文档变成可检索的知识：解析、切分、向量化，切的时候就把元数据带上。
切分不按字数砍，按标题、章节、段落和语义切，才保得住「这段属于哪台设备的哪一步」。设备型号、文档版本、章节这些元数据必须在入库时就挂上，否则检索层想按机型过滤时无从下手。
常见追问
上下文有限，越长越贵、越容易注意力稀释；一份手册里跟本次问题真正相关的往往只有几段。先检索再生成，才扛得住文档量。
版本作为元数据跟着片段入库，检索时按版本过滤；改版按文档粒度增量重索引，老版本标失效不物理删除。这也是知识治理要加强的第一项：型号、版本、业务分类管不住，召回就会拿到过期说法。
OCR 是文档属性，不是问题属性——同一页每次问都重转一遍，白付延迟和成本。离线转写成 Markdown 还能人工校对，图片不会自己变清晰，但文本可以一直复用。
每一格都给实名组件与具体参数。口径是通用的：换掉「无人机」三个字，任何一套企业文档知识库都能照着抄。
这些坑跟业务无关，换任何一套企业文档问答都会原样遇到。顺序照着链路走：文档解析 → 切成块 → 入库 → 定阈值 → 文档改版 → 调优。
最常见的第一坑。按页抽取会把一步操作从中间截断，而每页重复的页眉（机型名）和页脚（保密声明）会被当成正文向量化——于是「保密」两个字出现在几百个 Chunk 里，谁都能命中，谁都不该命中。
怎么改的有目录的 PDF 一律按目录抽段落；入库前按「跨页重复出现的短行」识别并剥离页眉页脚；表格单独抽块并打表标签。
图片型 PDF 用文本抽取器跑完，一页只出几个字符，但流程不报错——向量库里看起来「这份文档已入库」，实际是空的。用户问不到答案时，你以为是没召回，其实是根本没内容。
怎么改的入库时按页统计可提取字符数，低于阈值判定为图片页并生成待转写清单；把「空内容率」做成入库报告的第一行。
固定 500 字一刀切，最稳定的翻车方式是「前置条件被切到上一块」：答案里少了那句「仅限带 RTK 模块的机型」，读起来完全可信，实际会炸机。
怎么改的结构优先、长度兜底；表格与步骤整块不拆；用相邻节摘要补上下文；把「限定条件」类字段进元数据，让过滤而不是模型去守。
脏元数据比缺内容更难查：向量能命中，过滤却把它筛掉了，或者反过来把别的机型带进来。用户只看到「答非所问」，看不到是标注问题。
怎么改的入库即校验必填元数据，缺项的 Chunk 进治理队列不入库；上线前抽查 50 条 Chunk 的型号与版本对不对得上原文。
阈值定在 0.82 那天很准，换了 embedding 模型、或者手册改版重新切分之后，分数区间整体平移——要么全线拒答，要么全线放行，而且没人知道是哪天变的。
怎么改的阈值挂在 rerank 之后的分档上，用测试集标定；换模型或改切分策略时把「重标阈值」写进变更清单，不做就视为未回归。
手册出了 V3，向量库里 V2 还在，而且 V2 的措辞往往更「干净」，召回排名更高。用户拿到的是过期处置步骤，出处链接点进去还是老 PDF——看起来完全自洽。
怎么改的版本进元数据、检索默认当前版本；文档改版按文档粒度增量重建并标记旧版本失效；出处带版本号，让过期在答案里可见。
答不准就去改提示词，改完那三个问题确实对了——这是最省事的错觉，代价是另外三百个问题在你没看的地方退化了，而且没有回归集就发现不了。
怎么改的先建测试集再动手；沿 问题→召回→排序→上下文→答案 逐段定位，只改被指到的那一段；每轮改动跑全量回归。
第一次遇到编造答案的用户，之后每次结果都不会再核对出处——信任是一次性资产。而拒答率过高本身也是信号：说明知识库缺料，不是模型保守。
怎么改的拒答话术和出处展示先于功能上线；把拒答率当健康指标盯，超线就回到知识治理而不是调模型。
按一家 500 人规模公司的产品线文档估出来的参考基线——用来做容量规划、预期管理和「该配多大机器」的判断。
这些是推算值，不是实测值。上线前用 200–500 条真实问题量一遍，把这张表换成实测；换模型、换分块参数都要重量一遍。人力与周期：一个后端 + 一个业务方兼职文档治理，第一期（解析入库 + 混合检索 + 出处展示）3–4 周到内部可用。
这一期真正带得走的不是「RAG」这个词，是下面这三条判断。下次做任何知识库，它们都会再用到一次。
同一台大模型，切分质量决定上限：调提示词之前，先把块的结构、边界和元数据修对，收益大得多也稳得多。向量、全文、元数据放在同一个 Postgres 里，一条 SQL 就能组合召回；每多引一个中间件，都是要还的运维债。
能追溯才有人敢照着操作——出处机制是拒答之外的第二道信任防线，不是锦上添花的展示。别人给的相似度门槛，换个模型、换批语料就失效，必须用自己的题集标定，换模型即重标。
没有 200 道题，所有「感觉变好了」都是噪声，也挡不住改版回退。评测集是这套系统真正的护城河。
以后再设计知识库，我先问这三个问题。
决定要不要重索引机制，也决定切分粒度。
决定出处、拒答和阈值是不是硬要求。
决定能不能上线。
RAG 找知识，Agent 做决策，Tool 调业务。前者回答「失联以后怎么处理」，中者判断「先查这台设备的状态」，后者真正调用设备查询接口拿到电量、在线状态和任务状态。
不是独立的聊天机器人，而是建立在平台之上的智能入口。前期解决知识问题，之后把设备状态、任务信息、机场信息接进来，再靠 Agent 和 Tool Calling 让 AI 从回答走向调用平台能力——演进路线是 知识问答 → 业务查询 → Copilot → 业务执行。
不继续堆模型，按三个方向走：知识治理（版本、型号、业务分类这些元数据管住）、检索质量（混合检索、Rerank、问题拆解、上下文管理）、业务融合（把知识能力和 Agent、Tool 接起来，从回答问题走向帮用户完成任务）。
把分散在说明书、操作手册、业务文档和人员经验里的知识，变成自然语言可以直接访问的入口：以前是人找资料，现在是人问问题、系统找知识。同时它给后面的 Copilot 打了底——知识这一层站住了，业务查询和执行才有人接。
能，换的只是文档主题和元数据字段。链路与参数（结构优先切分、800 token 兜底、三路召回 + RRF + Rerank、阈值靠测试集标定、按文档粒度增量重索引）是通用的；把「设备型号」换成「产品线」「部门」，其余照抄。
一个 Postgres（pgvector + 中文分词）、一个 Embedding 模型、一个 rerank、一个对话模型，加上 200 条测试集就能跑通并量化。先跑通再谈架构：没有测试集之前，任何架构讨论都是空转。