最近在给手头的知识库系统做第四轮重构内部代号就叫“文心X”。前几版都是直接调用现成的大模型接口做问答结果发现一个很明显的问题你问它内部文档里的东西它要么一本正经地编要么答非所问。后来把方案改成“先检索、再生成”整个系统变成了一台围绕检索数据库转的问答引擎。这篇先写数据接入、清洗、分块和索引构建这些最枯燥、但也最决定成败的部分。“文心X”这个代号没什么特别含义X是因为当时已经迭代到第四个内部版本干脆叫了这个名字。它本质上是一个面向私有文档库的检索增强问答系统核心就一句话不要相信大模型会记住你家的文档让它先查到证据再回答。系列分上下两篇上篇聊数据侧和索引侧下篇聊检索链路、重排和问答组装。如果你也在给团队搭私有知识库或者在做基于大模型的文档问答方案这篇可以当一份实操参考。1. 文心X的定位与整体设计思路1.1 它到底解决什么问题先说一个我实际遇到的场景。某公司内部有几千份技术文档、故障记录、项目总结散落在不同的文件服务器和协作平台上。员工提问“上次网络故障最后怎么解决的”用传统关键词搜索基本搜不到什么因为文档里写的可能是“链路闪断”“核心交换机重启”“光模块替换”跟“网络故障”这几个字对不上。关键词匹配解决不了同义改写这是传统检索系统最痛的点。直接把问题扔给大模型更不靠谱。模型训练数据里没有你公司的私有文档遇到这种问题只能凭“常识”编一个解决方案生成得倒是很像样但里面的设备型号、操作步骤全是幻觉。我统计过早期那版的错误回答有相当一部分是模型把互联网上某个相似案例套过来回答看着专业实际完全不可用。文心X就是为了解决这两个问题设计的用向量检索做语义匹配把“网络故障”关联到“链路闪断”对应的文档片段再用检回来的片段约束大模型让它只能在给定证据范围内做摘要和归纳答完还附带出处。这样既解决了检索的命中率又解决了生成的幻觉。1.2 为什么是“检索 生成”而不是其他方案有人可能会说直接把文档喂给大模型做长文本理解不就行了这个思路在小规模场景下确实可以但文档量一上来就崩。首先是上下文窗口有限几千份文档不可能全部塞进去其次是每次都把所有文本重新处理一遍成本和延迟都受不了最后是文档更新之后大模型的“记忆”不会自动跟着变你得重新处理全量数据。检索增强生成RAG的解法是把问题拆成两个阶段离线阶段把所有文档切成小块做向量化建立索引在线阶段拿到用户问题先从索引里捞出最相关的几十个块拼成一段上下文再让大模型基于这段上下文回答。这个架构的好处是文档更新只需要增量刷新索引不用动模型本身检索和生成两个环节各自可以独立优化出了问题也容易定位。我当时做完这个选型之后团队里还有人问为什么不在线直接检索整篇文档再丢给模型。实际测过之后发现整篇文档往往包含多个主题就算检索系统定位到了这篇文章文章里的无关篇幅也会把回答带偏。切成小块的另一个好处是定位精确可以直接告诉用户“答案来自哪一章哪一节的哪一段”。1.3 系统三层结构上篇做到哪一层文心X整体分成三层层级负责内容本篇是否覆盖数据层文档接入、解析、清洗、分块本篇覆盖索引层向量化、向量索引、倒排索引、元数据管理本篇覆盖应用层查询改写、双路召回、重排、问答组装下篇覆盖数据层的目标是产出干净的文本块索引层的目标是把文本块变成可检索的向量和结构化条目。我在原型阶段犯过一个错误就是把大量精力花在检索算法调参上后来发现效果瓶颈其实在数据层。文本块质量不行后面算法再精也救不回来。这也是我写这篇时决定把笔墨重点放在前面的原因很多东西看着琐碎却决定了整个系统的上限。2. 数据接入与清洗底层文本质量决定检索上限2.1 支持的数据源与解析方式文心X要接的数据源比较杂最常见的几种格式我都踩过一遍PDF要分清两种。文字版PDF可以直接提取文本保留每一页的边界这个边界信息后期很有用因为引用溯源时报的是页码扫描版PDF必须走OCR否则提取出来全是空文本。OCR本身不复杂但要做好每一页的文字块和页码对应否则分块后引用定位会错乱。Word文档的坑在于表格。文档里那些参数表、对照表如果按普通文本抽取表格的行列结构就丢了检索出来是一串莫名其妙的字符串。我的处理方式是把表格按行拆开每一行转成“字段名值”的格式比如“设备编号A-001所属机房一号机房最近巡检日期2024-06-12”这样既保留了语义对应关系也方便后面的模型理解。Markdown和HTML走的是同一套思路先解析出标题层级再剥离掉所有样式信息。标题层级我特意保留下来后面分块时可以按标题来切这是非常重要的一步后面会说。还有一种容易忽略的数据源是数据库导出的数据比如CSV文件。直接把一行行原样塞进去检索效果很糟糕因为模型不认识这种纯结构化的表达。我会把每一行通过模板转成自然语言句子比如“设备X部署在Y机房责任人Z最近一次维护时间是...”。转完再入库语义信息立刻清晰很多。2.2 清洗规则清单数据清洗这一步看着不起眼但它直接决定了后面所有环节的效果。我整理了一份清洗规则实测下来每一条都有对应的场景页眉页脚清理。页眉里的“第X页 共Y页”、公司名称、文档密级标识不是页面正文检索到之后只会形成噪音全部删掉。保留层级编号。像“3.2.1 故障处理流程”这样的编号不要删检索时用户可能直接问“3.2.1讲了什么”删了编号就丢了一个重要线索。超链接只保留链接文字。除非整个链接指向的就是答案本身比如内部工具地址否则没必要保留URL。去重。同一个文件在不同目录出现多份或者不同文件里有大段重复内容要用文件名的hash去重。不然检索结果里出现两条几乎一模一样的片段体验很差。统一编码和特殊字符。全角半角、中文引号、不间断空格这些不统一会影响分块和向量化的一致性建议清洗阶段就归一化。清洗规则不要一把梭。我试过很激进地把所有括号内容都删掉结果发现有些文档在括号里写的是重要备注比如“仅限XX版本”删掉之后检索结果缺失了版本条件回答就有误导性。清洗方案的取舍原则是删掉确定性的噪音对不确定的内容宁可保留。2.3 分块策略检索精度的核心变量分块是数据层最重要的一步也是我踩坑最多的地方。先说原理向量模型是对整个输入文本做编码如果一块内容里揉了好几个不相关的小节生成的向量就是这些语义的“平均脸”检索时跟任何一个细节都对不上。分块的目标就是让每一块语义尽量内聚是一个相对完整的叙述单元。常见的分块方式有三种分块方式优点缺点适用场景固定长度直接切实现简单块大小稳定容易切断句子和段落语义碎片化粗略验证阶段按段落切语义完整块长度差异大有的太短有的太长段落结构清晰的文档按标题层级递归切语义边界准确结构清晰实现复杂标题内超长段落仍需再切正式生产推荐我最终采用的是“按标题层级递归切超长段落再按句子边界补切”的混合方式。具体逻辑是先把文档按Markdown标题结构拆成若干大块每块如果超过设定阈值就在段落边界处继续拆段落也没边界的就找句号、分号这些句子结尾断开。块大小选多少我是以中文文本为主最终用了600字符左右作为目标块大小。这个数值不是拍脑袋定的而是做过几组对照实验。块太大单块内主题容易变杂检索召回精度下降块太小语义不完整模型回答时缺少上下文。600字符大概能覆盖一个操作步骤或一个事件描述的完整闭环效果最稳。重叠窗口的设计同样关键。我给每个块加了80到120字符的重叠即下一个块会从上一个块的末尾重叠一部分再开始。这么做是为了防止答案恰好落在两个块的交界处假设用户想知道的信息前半段在块A后半段在块B没有重叠的话两块都不完整检索匹配分数都会被拉低加了重叠之后这个交界处的信息至少会在其中一块里保持完整。分块逻辑写成伪代码大概是这样def split_with_overlap(text, chunk_size600, overlap120): # 伪代码按标题层级切出大块再在段落边界附近切成小块 blocks split_by_headings(text) chunks [] for block in blocks: if len(block) chunk_size: chunks.append(block) else: current block[: chunk_size] fallback split_at_sentence_boundary(current) chunks.append(fallback) # 保留 overlap 的长度作为下一个块的起始 next_start len(fallback) - overlap # 继续切剩余部分直到块被消费完 return chunks这里还有一个容易忽略的操作要点某些文档有特殊的逻辑单元比如代码按函数切比按行数切好合同按条款切比按段落切好。通用分块逻辑跑完一遍之后要针对高价值文档类型做定制分块规则这属于提高上限的投入普通文档用通用规则就够。3. 向量化Embedding选型与生产化细节3.1 模型选型的几个关键维度分块完成之后每一段文本都要转成向量这一步的核心是选Embedding模型。选型的时候我主要看四个维度按重要性排序第一是中文效果。很多模型在英文基准上表现不错但一到中文就走样。看评测不能只看公开的榜单最好自己准备几百条真实的领域问答对拿现有语料跑一遍看召回准确率这个叫“带自己的数据去面试”。第二是向量维度。维度越高能表达的信息理论上越丰富但存储和检索的开销也跟着涨。768维是我觉得性价比比较合适的档位再往上收益不明显。当时测过一个高维模型返回效果提升很小索引库容量却涨了将近一倍最后放弃了。第三是长文本支持。Embedding模型通常有最大输入长度限制我测试时特意盯了一下长chunk的截断行为。如果模型只支持512个token而我的块有600字符超出部分会被静默丢弃等于分好的信息被悄悄砍掉一角。解决办法有两个限制块大小或者换支持更长输入的模型这两个其实要同时考虑。第四是离线部署。数据不出内网是很多场景的硬约束所以我选型时直接排除了纯在线API的方案用能在内部环境部署的开源模型。跑推理的硬件不用太好CPU也能跑只是慢一些数据量大的时候GPU批处理优势明显这个后面说。3.2 向量化的流程与幂等设计向量化在工程上看起来简单做稳了却不容易。我的处理流程是文本标准化、批量推理、失败重试、幂等写入。文本标准化要放在向量化之前。全角半角统一、大小写统一、把多个换行压缩成单个。如果不做这一步同一段内容因为格式微调产生了不同的向量后续增量更新时就会出现一条文档对应多个重复向量的问题。批量推理是个性能关键点。逐个chunk调用模型慢而且浪费。正确的做法是把所有chunk攒成一个批次设定一个合理的batch_size一次推理处理几百条。batch_size太小利用率低太大容易撑爆显存。我在生产环境跑的时候先拿一小批数据测试显存占用趋势再逐步调大到一个刚好峰值安全的数值。失败重试是必不可少的。批量向量化过程中偶尔会遇到个别文本触发模型异常比如超长文本、特殊字符组合如果整个批次直接重跑前面的进度就白费了。我的做法是每一条记录一个chunk_id失败的那条记录下来批次结束后集中重试重试还失败的进死信队列看具体原因。幂等性是个容易被忽略的设计但很重要。所谓幂等就是同一个字符串任何时候向量化出来的向量必须一致。看起来是理所当然的事实际不行因为大多数模型在CPU和GPU环境下推理浮点累加顺序可能不同会导致极微小的差异。这个差异平时无所谓但如果你拿它做内容去重、做增量更新的依据就会出现重复插入。我的规避方式是全部推理固定在同一类设备上跑同时入库前用文本hash做一次主键去重。批量向量化的流程伪代码如下def vectorize_chunks(chunk_list, batch_size256): # 伪代码按批次向量化失败记录后重试 results [] pending chunk_list while pending: batch, pending take_first(pending, batch_size) try: vectors embed(batch) # 模型推理 results.extend(zip(batch, vectors)) except Exception: # 逐条重试定位异常文本 for item in batch: try_embed_again(item) return results3.3 ID与元数据设计向量化完成之后每条文本块就有了对应的向量和一个位置信息。这个位置信息在后续检索、引用溯源时极其重要我建议在入库之前就设计好主键和元数据不要等上线了再补。主键我用的是内容哈希而不是自增ID。具体规则是源文件ID 页码 块序号拿这个组合去算一个摘要值作为该chunk的唯一标识。这样做最大的好处是增量更新容易文档内容没变的部分hash不变不需要重新入库只有内容变了的那几块hash才会变只需要更新这几块就行。用自增ID的话每次文档更新你都不知道哪些块该删、哪些块该留只能全量重建。元数据字段我保留了这些源文件ID、文件名、文件路径、页码、标题路径比如“第三章 3.2节 3.2.1 故障处理流程”、业务域、入库时间、文档版本号。标题路径这个字段特别说明一下。它是按Markdown标题层级拼出来的回答的时候可以直接告诉用户“答案来自《XX手册》第三章第3.2节”可信度一下子提升很多。如果没有这个字段你只能给一个文档名和页码用户还要自己翻。业务域字段用来做查询时的过滤条件比如只搜索“运维文档”或者只搜索“项目总结”。这个对大型知识库特别有用检索的时候先用业务域缩小范围可以明显减少跨域噪音。4. 索引库构建与更新维护4.1 全量构建与增量构建索引库的构建分成全量构建和增量构建两种。全量构建用于首次接入或者某次数据结构发生重大变化时推倒重来增量构建用于日常文档更新核心逻辑是“只处理变化的部分”。我当时写了一个目录监听器按固定周期扫描文档目录用文件的修改时间加文件大小来快速判断哪些文档有更新。只有更新过的文档才会进入解析、清洗、分块、向量化、入库这条流水线其余文档直接跳过整个增量过程的耗时和文档变化量成正比而不是跟全库大小成正比。更新流程要特别注意一致性问题。一个文档被修改后旧chunk和新chunk不能同时出现在库里否则检索时会返回自相矛盾的结果。我的处理方式是先按源文件ID删除该文档对应的全部旧chunk再插入新chunk整个操作在同一个事务里执行这样要么旧的全部清掉新的全部进来要么什么都不变不会出现半新半旧的状态。全量构建流程伪代码如下def build_index(source_dir): # 伪代码全量构建索引 docs scan_files(source_dir) for doc in docs: content parse_and_clean(doc) chunks split_with_overlap(content) vectors vectorize_chunks(chunks) for chunk, vector in zip(chunks, vectors): upsert_chunk(chunk, vector)4.2 索引结构设计要点索引层的结构设计直接决定了上层的检索策略。文心X这里不是单跑向量检索而是用了“向量检索 倒排检索”双路召回所以索引库其实是两套索引同时维护。为什么还要保留一套传统的关键词索引因为向量检索在语义匹配上很强但对精确词和编号类查询往往不稳。比如用户问“错误码E-1024的意思”E-1024是个精确的代码向量检索可能会把它匹配到语义相近但实际不同的内容上而倒排索引一下子就能精确命中。两套索引的召回结果取并集再送进重排模块这是下篇的重点但索引结构必须在上篇就铺好。向量索引本身我也做了分区的设计。按业务域划分命名空间比如运维域、研发域、管理域各自独立检索时只查目标域。这样既提升了检索速度也避免了不同域内容互相污染。还有一个细节容易漏掉向量索引和倒排索引的文档删除要同步。如果向量库里没有这条chunk了但倒排索引里还有检索时就会返回一条“不存在”的结果。维护两套索引的增删一致性是索引层最常见的隐蔽bug来源。4.3 性能与容量估算索引库做到多大普通机器扛不扛得住这是很多人在动手前最关心的问题我直接给一个估算方式。单条向量的内存占用大概是向量维度 × 4字节再加上元数据的开销。以768维为例一条向量本身占约 768 × 4 3072字节约3KB。假设你的文档库有1万份文档平均每份切出50个chunk那就是50万条记录向量部分占用约 500000 × 3KB ≈ 1.5GB普通服务器的内存完全扛得住。考虑到元数据和索引结构再翻一倍也没问题。真正的大头往往在线下解析和向量化推理的时间而不是索引存储。图索引类算法的检索参数我特别强调一下虽然不点名具体实现但几个参数的含义是通用的负责控制索引图密度的参数加大可以提高召回精度但会拖慢查询构建参数控制索引质量离线构建时可以调大一些不影响在线延迟查询参数控制检索时的探索范围这个值直接和查询延迟挂钩调优时要在召回质量和响应时间之间找平衡。实际调的时候我建议先跑一遍离线评测确定好构建参数再在线上调节查询参数。我这边1万份文档的库全量构建耗时大概在个把小时级别大头在文档解析和向量推理索引构建本身很快。所以如果排查性能瓶颈别一上来就怀疑索引库先看数据解析流水线的日志。5. 避坑经验与上篇小结5.1 几个最想分享的坑第一个坑是分块重叠设计得太小。最开始我用固定长度切块没有加重叠窗口上线后收到反馈说有些问题的答案找不全。排查后发现是答案横跨两个chunk检索时两个chunk各自匹配分数都不高排在前面的都是“看着接近但答非所问”的内容。加了重叠之后这类问题明显减少跨界信息至少能在某一个块里保持完整。第二个坑是清洗规则过于激进。我一心想去掉文档里的杂讯把很多括号内容视为无用直接删除结果里面包含了版本适用条件、范围限定这些关键信息。后来检索系统回答出来的内容缺少这些限定条件被用户指出有误导性。从那以后清洗规则改成保守策略拿不准的内容一律保留。第三个坑是批量向量化时显存打爆。一开始图省事把全量chunk一次性丢进模型推理程序直接崩溃。后来改成小批次循环并在批次间观察显存曲线稳定之后再逐步加大batch_size。这个教训对任何跑模型推理的场景都适用先小步验证再大步生产。第四个坑是元数据字段没留全。早期版本只存了文档名和页码没有存标题路径和业务域上线后想定位某个回答的来源得在文档里翻半天。后面补上标题路径字段引用溯源一下子就清楚了。元数据设计要在一开始就想清楚后期补的话旧数据要全量重新处理一遍代价很大。5.2 给同样在搭检索数据库的朋友一句话回顾这一半的搭建过程我最大的体会是检索数据库的成败七成在数据侧三成在算法侧。把分块、清洗、元数据这些基础功夫做扎实后续的检索链路和问答效果会省很多事。很多项目看起来是模型效果不好、参数没调优扒开看其实是最底层那块文本块本身就是脏的、碎的。这次先码到这里整个数据接入和索引构建的部分已经说完了。下篇我再专门讲查询进来之后的事查询改写、双路召回、重排、上下文拼装和提示词设计那才是真正把检索数据库“用起来”的关键环节。
最近在给手头的知识库系统做第四轮重构内部代号就叫“文心X”。前几版都是直接调用现成的大模型接口做问答结果发现一个很明显的问题你问它内部文档里的东西它要么一本正经地编要么答非所问。后来把方案改成“先检索、再生成”整个系统变成了一台围绕检索数据库转的问答引擎。这篇先写数据接入、清洗、分块和索引构建这些最枯燥、但也最决定成败的部分。“文心X”这个代号没什么特别含义X是因为当时已经迭代到第四个内部版本干脆叫了这个名字。它本质上是一个面向私有文档库的检索增强问答系统核心就一句话不要相信大模型会记住你家的文档让它先查到证据再回答。系列分上下两篇上篇聊数据侧和索引侧下篇聊检索链路、重排和问答组装。如果你也在给团队搭私有知识库或者在做基于大模型的文档问答方案这篇可以当一份实操参考。1. 文心X的定位与整体设计思路1.1 它到底解决什么问题先说一个我实际遇到的场景。某公司内部有几千份技术文档、故障记录、项目总结散落在不同的文件服务器和协作平台上。员工提问“上次网络故障最后怎么解决的”用传统关键词搜索基本搜不到什么因为文档里写的可能是“链路闪断”“核心交换机重启”“光模块替换”跟“网络故障”这几个字对不上。关键词匹配解决不了同义改写这是传统检索系统最痛的点。直接把问题扔给大模型更不靠谱。模型训练数据里没有你公司的私有文档遇到这种问题只能凭“常识”编一个解决方案生成得倒是很像样但里面的设备型号、操作步骤全是幻觉。我统计过早期那版的错误回答有相当一部分是模型把互联网上某个相似案例套过来回答看着专业实际完全不可用。文心X就是为了解决这两个问题设计的用向量检索做语义匹配把“网络故障”关联到“链路闪断”对应的文档片段再用检回来的片段约束大模型让它只能在给定证据范围内做摘要和归纳答完还附带出处。这样既解决了检索的命中率又解决了生成的幻觉。1.2 为什么是“检索 生成”而不是其他方案有人可能会说直接把文档喂给大模型做长文本理解不就行了这个思路在小规模场景下确实可以但文档量一上来就崩。首先是上下文窗口有限几千份文档不可能全部塞进去其次是每次都把所有文本重新处理一遍成本和延迟都受不了最后是文档更新之后大模型的“记忆”不会自动跟着变你得重新处理全量数据。检索增强生成RAG的解法是把问题拆成两个阶段离线阶段把所有文档切成小块做向量化建立索引在线阶段拿到用户问题先从索引里捞出最相关的几十个块拼成一段上下文再让大模型基于这段上下文回答。这个架构的好处是文档更新只需要增量刷新索引不用动模型本身检索和生成两个环节各自可以独立优化出了问题也容易定位。我当时做完这个选型之后团队里还有人问为什么不在线直接检索整篇文档再丢给模型。实际测过之后发现整篇文档往往包含多个主题就算检索系统定位到了这篇文章文章里的无关篇幅也会把回答带偏。切成小块的另一个好处是定位精确可以直接告诉用户“答案来自哪一章哪一节的哪一段”。1.3 系统三层结构上篇做到哪一层文心X整体分成三层层级负责内容本篇是否覆盖数据层文档接入、解析、清洗、分块本篇覆盖索引层向量化、向量索引、倒排索引、元数据管理本篇覆盖应用层查询改写、双路召回、重排、问答组装下篇覆盖数据层的目标是产出干净的文本块索引层的目标是把文本块变成可检索的向量和结构化条目。我在原型阶段犯过一个错误就是把大量精力花在检索算法调参上后来发现效果瓶颈其实在数据层。文本块质量不行后面算法再精也救不回来。这也是我写这篇时决定把笔墨重点放在前面的原因很多东西看着琐碎却决定了整个系统的上限。2. 数据接入与清洗底层文本质量决定检索上限2.1 支持的数据源与解析方式文心X要接的数据源比较杂最常见的几种格式我都踩过一遍PDF要分清两种。文字版PDF可以直接提取文本保留每一页的边界这个边界信息后期很有用因为引用溯源时报的是页码扫描版PDF必须走OCR否则提取出来全是空文本。OCR本身不复杂但要做好每一页的文字块和页码对应否则分块后引用定位会错乱。Word文档的坑在于表格。文档里那些参数表、对照表如果按普通文本抽取表格的行列结构就丢了检索出来是一串莫名其妙的字符串。我的处理方式是把表格按行拆开每一行转成“字段名值”的格式比如“设备编号A-001所属机房一号机房最近巡检日期2024-06-12”这样既保留了语义对应关系也方便后面的模型理解。Markdown和HTML走的是同一套思路先解析出标题层级再剥离掉所有样式信息。标题层级我特意保留下来后面分块时可以按标题来切这是非常重要的一步后面会说。还有一种容易忽略的数据源是数据库导出的数据比如CSV文件。直接把一行行原样塞进去检索效果很糟糕因为模型不认识这种纯结构化的表达。我会把每一行通过模板转成自然语言句子比如“设备X部署在Y机房责任人Z最近一次维护时间是...”。转完再入库语义信息立刻清晰很多。2.2 清洗规则清单数据清洗这一步看着不起眼但它直接决定了后面所有环节的效果。我整理了一份清洗规则实测下来每一条都有对应的场景页眉页脚清理。页眉里的“第X页 共Y页”、公司名称、文档密级标识不是页面正文检索到之后只会形成噪音全部删掉。保留层级编号。像“3.2.1 故障处理流程”这样的编号不要删检索时用户可能直接问“3.2.1讲了什么”删了编号就丢了一个重要线索。超链接只保留链接文字。除非整个链接指向的就是答案本身比如内部工具地址否则没必要保留URL。去重。同一个文件在不同目录出现多份或者不同文件里有大段重复内容要用文件名的hash去重。不然检索结果里出现两条几乎一模一样的片段体验很差。统一编码和特殊字符。全角半角、中文引号、不间断空格这些不统一会影响分块和向量化的一致性建议清洗阶段就归一化。清洗规则不要一把梭。我试过很激进地把所有括号内容都删掉结果发现有些文档在括号里写的是重要备注比如“仅限XX版本”删掉之后检索结果缺失了版本条件回答就有误导性。清洗方案的取舍原则是删掉确定性的噪音对不确定的内容宁可保留。2.3 分块策略检索精度的核心变量分块是数据层最重要的一步也是我踩坑最多的地方。先说原理向量模型是对整个输入文本做编码如果一块内容里揉了好几个不相关的小节生成的向量就是这些语义的“平均脸”检索时跟任何一个细节都对不上。分块的目标就是让每一块语义尽量内聚是一个相对完整的叙述单元。常见的分块方式有三种分块方式优点缺点适用场景固定长度直接切实现简单块大小稳定容易切断句子和段落语义碎片化粗略验证阶段按段落切语义完整块长度差异大有的太短有的太长段落结构清晰的文档按标题层级递归切语义边界准确结构清晰实现复杂标题内超长段落仍需再切正式生产推荐我最终采用的是“按标题层级递归切超长段落再按句子边界补切”的混合方式。具体逻辑是先把文档按Markdown标题结构拆成若干大块每块如果超过设定阈值就在段落边界处继续拆段落也没边界的就找句号、分号这些句子结尾断开。块大小选多少我是以中文文本为主最终用了600字符左右作为目标块大小。这个数值不是拍脑袋定的而是做过几组对照实验。块太大单块内主题容易变杂检索召回精度下降块太小语义不完整模型回答时缺少上下文。600字符大概能覆盖一个操作步骤或一个事件描述的完整闭环效果最稳。重叠窗口的设计同样关键。我给每个块加了80到120字符的重叠即下一个块会从上一个块的末尾重叠一部分再开始。这么做是为了防止答案恰好落在两个块的交界处假设用户想知道的信息前半段在块A后半段在块B没有重叠的话两块都不完整检索匹配分数都会被拉低加了重叠之后这个交界处的信息至少会在其中一块里保持完整。分块逻辑写成伪代码大概是这样def split_with_overlap(text, chunk_size600, overlap120): # 伪代码按标题层级切出大块再在段落边界附近切成小块 blocks split_by_headings(text) chunks [] for block in blocks: if len(block) chunk_size: chunks.append(block) else: current block[: chunk_size] fallback split_at_sentence_boundary(current) chunks.append(fallback) # 保留 overlap 的长度作为下一个块的起始 next_start len(fallback) - overlap # 继续切剩余部分直到块被消费完 return chunks这里还有一个容易忽略的操作要点某些文档有特殊的逻辑单元比如代码按函数切比按行数切好合同按条款切比按段落切好。通用分块逻辑跑完一遍之后要针对高价值文档类型做定制分块规则这属于提高上限的投入普通文档用通用规则就够。3. 向量化Embedding选型与生产化细节3.1 模型选型的几个关键维度分块完成之后每一段文本都要转成向量这一步的核心是选Embedding模型。选型的时候我主要看四个维度按重要性排序第一是中文效果。很多模型在英文基准上表现不错但一到中文就走样。看评测不能只看公开的榜单最好自己准备几百条真实的领域问答对拿现有语料跑一遍看召回准确率这个叫“带自己的数据去面试”。第二是向量维度。维度越高能表达的信息理论上越丰富但存储和检索的开销也跟着涨。768维是我觉得性价比比较合适的档位再往上收益不明显。当时测过一个高维模型返回效果提升很小索引库容量却涨了将近一倍最后放弃了。第三是长文本支持。Embedding模型通常有最大输入长度限制我测试时特意盯了一下长chunk的截断行为。如果模型只支持512个token而我的块有600字符超出部分会被静默丢弃等于分好的信息被悄悄砍掉一角。解决办法有两个限制块大小或者换支持更长输入的模型这两个其实要同时考虑。第四是离线部署。数据不出内网是很多场景的硬约束所以我选型时直接排除了纯在线API的方案用能在内部环境部署的开源模型。跑推理的硬件不用太好CPU也能跑只是慢一些数据量大的时候GPU批处理优势明显这个后面说。3.2 向量化的流程与幂等设计向量化在工程上看起来简单做稳了却不容易。我的处理流程是文本标准化、批量推理、失败重试、幂等写入。文本标准化要放在向量化之前。全角半角统一、大小写统一、把多个换行压缩成单个。如果不做这一步同一段内容因为格式微调产生了不同的向量后续增量更新时就会出现一条文档对应多个重复向量的问题。批量推理是个性能关键点。逐个chunk调用模型慢而且浪费。正确的做法是把所有chunk攒成一个批次设定一个合理的batch_size一次推理处理几百条。batch_size太小利用率低太大容易撑爆显存。我在生产环境跑的时候先拿一小批数据测试显存占用趋势再逐步调大到一个刚好峰值安全的数值。失败重试是必不可少的。批量向量化过程中偶尔会遇到个别文本触发模型异常比如超长文本、特殊字符组合如果整个批次直接重跑前面的进度就白费了。我的做法是每一条记录一个chunk_id失败的那条记录下来批次结束后集中重试重试还失败的进死信队列看具体原因。幂等性是个容易被忽略的设计但很重要。所谓幂等就是同一个字符串任何时候向量化出来的向量必须一致。看起来是理所当然的事实际不行因为大多数模型在CPU和GPU环境下推理浮点累加顺序可能不同会导致极微小的差异。这个差异平时无所谓但如果你拿它做内容去重、做增量更新的依据就会出现重复插入。我的规避方式是全部推理固定在同一类设备上跑同时入库前用文本hash做一次主键去重。批量向量化的流程伪代码如下def vectorize_chunks(chunk_list, batch_size256): # 伪代码按批次向量化失败记录后重试 results [] pending chunk_list while pending: batch, pending take_first(pending, batch_size) try: vectors embed(batch) # 模型推理 results.extend(zip(batch, vectors)) except Exception: # 逐条重试定位异常文本 for item in batch: try_embed_again(item) return results3.3 ID与元数据设计向量化完成之后每条文本块就有了对应的向量和一个位置信息。这个位置信息在后续检索、引用溯源时极其重要我建议在入库之前就设计好主键和元数据不要等上线了再补。主键我用的是内容哈希而不是自增ID。具体规则是源文件ID 页码 块序号拿这个组合去算一个摘要值作为该chunk的唯一标识。这样做最大的好处是增量更新容易文档内容没变的部分hash不变不需要重新入库只有内容变了的那几块hash才会变只需要更新这几块就行。用自增ID的话每次文档更新你都不知道哪些块该删、哪些块该留只能全量重建。元数据字段我保留了这些源文件ID、文件名、文件路径、页码、标题路径比如“第三章 3.2节 3.2.1 故障处理流程”、业务域、入库时间、文档版本号。标题路径这个字段特别说明一下。它是按Markdown标题层级拼出来的回答的时候可以直接告诉用户“答案来自《XX手册》第三章第3.2节”可信度一下子提升很多。如果没有这个字段你只能给一个文档名和页码用户还要自己翻。业务域字段用来做查询时的过滤条件比如只搜索“运维文档”或者只搜索“项目总结”。这个对大型知识库特别有用检索的时候先用业务域缩小范围可以明显减少跨域噪音。4. 索引库构建与更新维护4.1 全量构建与增量构建索引库的构建分成全量构建和增量构建两种。全量构建用于首次接入或者某次数据结构发生重大变化时推倒重来增量构建用于日常文档更新核心逻辑是“只处理变化的部分”。我当时写了一个目录监听器按固定周期扫描文档目录用文件的修改时间加文件大小来快速判断哪些文档有更新。只有更新过的文档才会进入解析、清洗、分块、向量化、入库这条流水线其余文档直接跳过整个增量过程的耗时和文档变化量成正比而不是跟全库大小成正比。更新流程要特别注意一致性问题。一个文档被修改后旧chunk和新chunk不能同时出现在库里否则检索时会返回自相矛盾的结果。我的处理方式是先按源文件ID删除该文档对应的全部旧chunk再插入新chunk整个操作在同一个事务里执行这样要么旧的全部清掉新的全部进来要么什么都不变不会出现半新半旧的状态。全量构建流程伪代码如下def build_index(source_dir): # 伪代码全量构建索引 docs scan_files(source_dir) for doc in docs: content parse_and_clean(doc) chunks split_with_overlap(content) vectors vectorize_chunks(chunks) for chunk, vector in zip(chunks, vectors): upsert_chunk(chunk, vector)4.2 索引结构设计要点索引层的结构设计直接决定了上层的检索策略。文心X这里不是单跑向量检索而是用了“向量检索 倒排检索”双路召回所以索引库其实是两套索引同时维护。为什么还要保留一套传统的关键词索引因为向量检索在语义匹配上很强但对精确词和编号类查询往往不稳。比如用户问“错误码E-1024的意思”E-1024是个精确的代码向量检索可能会把它匹配到语义相近但实际不同的内容上而倒排索引一下子就能精确命中。两套索引的召回结果取并集再送进重排模块这是下篇的重点但索引结构必须在上篇就铺好。向量索引本身我也做了分区的设计。按业务域划分命名空间比如运维域、研发域、管理域各自独立检索时只查目标域。这样既提升了检索速度也避免了不同域内容互相污染。还有一个细节容易漏掉向量索引和倒排索引的文档删除要同步。如果向量库里没有这条chunk了但倒排索引里还有检索时就会返回一条“不存在”的结果。维护两套索引的增删一致性是索引层最常见的隐蔽bug来源。4.3 性能与容量估算索引库做到多大普通机器扛不扛得住这是很多人在动手前最关心的问题我直接给一个估算方式。单条向量的内存占用大概是向量维度 × 4字节再加上元数据的开销。以768维为例一条向量本身占约 768 × 4 3072字节约3KB。假设你的文档库有1万份文档平均每份切出50个chunk那就是50万条记录向量部分占用约 500000 × 3KB ≈ 1.5GB普通服务器的内存完全扛得住。考虑到元数据和索引结构再翻一倍也没问题。真正的大头往往在线下解析和向量化推理的时间而不是索引存储。图索引类算法的检索参数我特别强调一下虽然不点名具体实现但几个参数的含义是通用的负责控制索引图密度的参数加大可以提高召回精度但会拖慢查询构建参数控制索引质量离线构建时可以调大一些不影响在线延迟查询参数控制检索时的探索范围这个值直接和查询延迟挂钩调优时要在召回质量和响应时间之间找平衡。实际调的时候我建议先跑一遍离线评测确定好构建参数再在线上调节查询参数。我这边1万份文档的库全量构建耗时大概在个把小时级别大头在文档解析和向量推理索引构建本身很快。所以如果排查性能瓶颈别一上来就怀疑索引库先看数据解析流水线的日志。5. 避坑经验与上篇小结5.1 几个最想分享的坑第一个坑是分块重叠设计得太小。最开始我用固定长度切块没有加重叠窗口上线后收到反馈说有些问题的答案找不全。排查后发现是答案横跨两个chunk检索时两个chunk各自匹配分数都不高排在前面的都是“看着接近但答非所问”的内容。加了重叠之后这类问题明显减少跨界信息至少能在某一个块里保持完整。第二个坑是清洗规则过于激进。我一心想去掉文档里的杂讯把很多括号内容视为无用直接删除结果里面包含了版本适用条件、范围限定这些关键信息。后来检索系统回答出来的内容缺少这些限定条件被用户指出有误导性。从那以后清洗规则改成保守策略拿不准的内容一律保留。第三个坑是批量向量化时显存打爆。一开始图省事把全量chunk一次性丢进模型推理程序直接崩溃。后来改成小批次循环并在批次间观察显存曲线稳定之后再逐步加大batch_size。这个教训对任何跑模型推理的场景都适用先小步验证再大步生产。第四个坑是元数据字段没留全。早期版本只存了文档名和页码没有存标题路径和业务域上线后想定位某个回答的来源得在文档里翻半天。后面补上标题路径字段引用溯源一下子就清楚了。元数据设计要在一开始就想清楚后期补的话旧数据要全量重新处理一遍代价很大。5.2 给同样在搭检索数据库的朋友一句话回顾这一半的搭建过程我最大的体会是检索数据库的成败七成在数据侧三成在算法侧。把分块、清洗、元数据这些基础功夫做扎实后续的检索链路和问答效果会省很多事。很多项目看起来是模型效果不好、参数没调优扒开看其实是最底层那块文本块本身就是脏的、碎的。这次先码到这里整个数据接入和索引构建的部分已经说完了。下篇我再专门讲查询进来之后的事查询改写、双路召回、重排、上下文拼装和提示词设计那才是真正把检索数据库“用起来”的关键环节。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
