很多做RAG的朋友都有同一种感觉看了不少教程分块、向量化、召回、排序每个环节都门儿清可一上真实业务数据效果就是不对劲。要么检索结果牛头不对马嘴要么答案引用了完全无关的片段要么新增一批文档后旧知识全被冲乱。折腾到最后问题往往不在某个算法调得不好而是整个数据管道从一开始就没理顺。RAG的名字取得太有迷惑性了——Retrieval Augmented Generation看起来重点是检索和生成但真正决定项目生死的是检索之前那半条链路。从源文档进入系统的那一刻起清洗规则、解析方式、分块粒度、向量化策略、索引结构、元数据设计每一层都在悄然影响最终回答质量。这篇文章就围绕RAG数据管道的全流程展开讲讲我在实际项目中踩过的坑、反复验证过的方案以及从普通知识库到Agentic RAG时管道要做什么样的演变。适合正在搭建或优化RAG系统、尤其是被检索质量困扰的工程师和项目负责人参考。1. 先聊聊为什么很多RAG项目挂在数据进出的那一刻大家习惯把注意力放在分块和向量化上因为它们最像“技术活”有参数可调、有论文可查。但数据管道的前两公里——数据的进入、识别、清洗、归一化——往往才是决定成败的地方。我见过不少项目分块策略是从某篇热门博客抄的向量模型选了当时榜单第一的结果检索准确率依然惨不忍睹最后定位根因时发现源文档本身有一半是扫描PDF里抽出来的乱码表格被解析成了天书英文双引号和中文引号混在一起导致语义完全错乱。分块算法再好也救不了垃圾进、垃圾出。1.1 源数据盘点接数据之前先摸清家底落地RAG的第一步不是选模型而是对现有文档资产做一次彻底盘点。这一步在几乎所有公开教程里都被一笔带过但实际项目中至少占掉三分之一的工期。你需要弄清楚几个问题公司里有多少种格式的文档每种格式的质量如何有没有统一的知识管理平台文档是结构化数据库里的字段还是散落在共享盘上的Word和PDF这些文档的更新频率是多少是由哪个部门维护的我做过的几个项目里最常见的存量文档类型无非是这几类PDF又细分为扫描件、Word转印件、专业排版软件导出件、Office文档主要是Word和PPT、网页导出的HTML/PDF、以及各种纯文本或多Markdown形式的开发文档。最难处理的永远是扫描版PDF和复杂排版的PPT前者需要OCR后者需要版面分析这已经不是单纯调库能解决的事需要引入文档解析模型。摸清家底之后你就得为每一类源文档制定进入管道的策略。这里没有万能方案但有一个原则值得坚持能拿到源文件就绝不用导出件能拿到结构化数据就绝不用人肉排版后的PDF。很多企业内部知识库最初是从各种渠道导出的PDF而原始Word或数据库里的字段反而更容易解析和保留结构。如果有可能推动源端直接输出JSON或Markdown格式这对后续整个管道都是巨大的降维打击。1.2 解析与清洗格式地狱里的分层处理方案源数据盘点完成后进入实际的解析清洗环节。这一层的技术选型直接决定了后续分块和向量化的上限。我的做法是把解析分成三个层次轻量级格式、重量级格式、极端格式。轻量级格式包括纯文本、Markdown、JSON、CSV直接用语言自带的能力或简单正则就能处理。Markdown还需要保留标题层级关系这关系到后面基于结构的分块。重量级格式包括Word、PPT以及由Word或PPT转出的PDF这类文件用成熟的文档解析库通常能还原大部分结构。最复杂的极端格式是扫描版PDF、多栏排版、图文混排的复杂文档这需要OCR加版面分析组合拳。这里必须多说一句清洗不是简单的去噪而是在保留语义的前提下做归一化。常见的清洗动作包括全文统一编码UTF-8、统一标点符号把中文全角引号替换成标准形式消除英文引号的转义歧义、去掉页眉页脚和水印这些内容一旦进入向量库就会造成大量假匹配、超链接转文字否则向量化时链接文本会成为噪音。有一个看起来简单但极其容易被忽视的细节空格的半角全角统一。中文文本里夹着的全角空格在向量化时会被模型当成一个独立的token参与注意力计算明明语义相同的一句话因为空格差异导致向量偏差很大检索时明明有相关内容却召不回来。1.3 数据血缘与版本管理知识库维护最少被提起的部分数据管道里最容易被忽略、但长期维护时最重要的一环是血缘追踪和版本管理。知识库不是一次性建完就万事大吉的它是像代码仓库一样需要持续演进的东西。每一条进入知识库的数据都该记录它的来源文件、入库时间、清洗规则版本、分块策略版本、向量化模型版本。为什么要记录这些因为RAG出了问题需要回溯。当你发现最近几天的检索准确率明显下降时第一反应应该是查数据管道而不是重新调向量模型。到底是新入库的文档引入了噪音还是分块参数被无意中改过又或者某一批旧文档被重新清洗时改变了原有语义如果连数据血缘都没有排查只能靠猜。版本管理还有一个更实际的作用当你要迁移向量数据库或者升级向量化模型时可以精确知道哪些文档需要重新向量化而不是把整个知识库推倒重来。这里我建议参考代码仓库的管理思路每个文档在进入知识库时都带一个元数据字段记录其内容哈希值。管道检测到哈希值变化时才将该文档送入重新解析和向量化的流程。这样新增、修改、删除都能精确控制避免全量重建带来的高昂成本。这个思路在数据量小的时候看不出优势但数据量一旦上到百万级文档增量更新带来的成本节省是数量级的。2. 分块不是切豆腐不同文本形态下的切分策略与取舍分块是RAG里被讨论得最多的环节也是被误解得最深的环节。很多教程直接把文本按固定字数硬切比如512个字符一刀切然后告诉你这就是分块了。这种切法在Demo阶段看不出问题因为测试集中文段短、主题鲜明随便怎么切都能召回。但真实业务文档动辄几十页同一页里可能讲了好几个独立概念固定窗口硬切会把这些概念拦腰砍断造成索引片段信息不完整。我看过热词里有“分块矩阵求逆”和“分块矩阵相乘 节约计算量 动态规划”有趣的是RAG的分块思路和矩阵分块有异曲同工之妙——都是把大问题拆成小问题但拆分的边界必须选在计算或语义的天然接缝处。矩阵分块会沿着行列的天然结构切文本分块也应该沿着段落、标题、列表这类语义边界切而不是拿把大刀按长度硬剁。2.1 固定窗口为什么还会流行简单性和可复现性的博弈不可否认固定窗口分块Fixed-size Chunking依然是很多开源框架的默认实现。它的优势在于极度简单定一个块大小、一个重叠量分块结果完全可预测可复现测试时出问题容易排查。这在大规模并行处理时非常友好因为分块逻辑完全确定可以轻松做分布式。但固定窗口的缺点同样突出。它完全不理解文档结构同一句话可能被从中间截断上一段末尾的结论和下一段开头的新主题被强行装进同一个块导致向量表示被稀释。更隐蔽的问题是固定大小往往不等同于固定语义量一段充满专有名词和密集逻辑的技术文档和一段举例说明的水文200个字符包含的信息量天差地别但固定分块给它们的权重完全一样。我的结论是固定窗口可以作为基线方案Baseline用于快速跑通Pipeline、验证模型选型但绝不应该作为线上最终方案。它就像是压力测试中的对照组没有它你无法衡量更复杂分块策略到底带来了多少提升但你不能永远活在对照组里。2.2 基于结构与语义的分块实战组合拳在真实项目里我通常使用一套组合策略。第一优先级是利用文档本身的结构信息Markdown的标题层级、Word的标题样式、PDF的书签和目录这些天然就是完美的分块边界。先用结构解析把文档切成长度适中的一级片段比如一个章节或一个大节然后在片段内部检查长度是否超限。一级片段仍然过长怎么办这时进入第二优先级语义切分。利用段落边界、句子边界进行二次切分尽量在语义完整的基础上控制块大小。第三优先级才是兜底的固定窗口只用于那些完全没有结构、也找不到句子边界的极端文本。这套策略的本质是结构优先语义兜底固定窗口是最后的退路。实践中还有一个经常被忽略的配置块重叠Chunk Overlap。我见过不少教程直接抄了个0重叠或10%重叠的参数完全不去思考重叠是为了解决什么问题。重叠的目的只有一个弥补切分时可能丢失的上下文。句子与句子之间的语义依赖往往跨越切分边界适当重叠可以减少这种割裂。但重叠不是越多越好过度重叠会让相邻块的相似度极高检索时出现大量重复片段反而淹没了真正需要召回的语义。我的经验是10%到15%的重叠率是多数场景的起点之后根据检索评测结果微调。还有一类特殊的分块策略值得单独提一下——按问题或主题聚类后分块。在某些垂直领域比如程序文档、问答库文档天然由一个个“问题答案”组成。这种情况下按单个问答对分块效果远好于按段落或标题分块。这也是为什么我坚持强调源数据盘点只有知道你手里是什么形态的文档才能选出合适的分块策略。2.3 表格、代码、多栏版面非纯文本块的特殊处理表格是分块环节最头疼的敌人。把表格当作纯文本直接切切出来的基本是不可用的碎片。常见做法是先把表格转成Markdown表格格式再作为一个独立的Chunk整体索引。这里有个取舍大宽表可能超过模型的上下文限制需要做行列转置或只保留关键列。另一个思路是把表格转成自然语言描述比如”某产品在2023年第三季度的销售额是1200万元同比增长15%”这种描述形式在向量化时效果往往比原始表格结构好得多因为它直接贴近自然语言的表达空间。代码块和公式同理。直接向量化代码本身的效果一般因为代码的语义分布和自然语言差异很大。我在代码类RAG项目里看到比较成功的做法是把代码块和它上方的注释或说明文字绑定在一起作为一个Chunk让注释充当代码的语义锚点。多栏版面是另一个大坑常见于学术论文和公众号长文截图。解析时如果不做版面分析双栏文档的文字会从左栏排到右栏段落完全错乱。这个问题必须在解析层解决分块阶段已经回天乏术。所以之前提到的解析环节相当重要PDF解析时要做版面分析和阅读顺序还原而不是简单的文本抽取。3. 向量化环节的工程账本模型选型、维度设定与服务器成本分块完成后接下来就是向量化。这一步看似简单——把文本塞进模型得到一个向量存进数据库——但实际操作里有几个容易被忽略的决策点尤其是向量维度和归一化方式会直接影响后续数据库索引的选型和检索效果。3.1 稠密向量与稀疏向量的兄弟配合文本向量化首先遇到的是路线选择稠密向量Dense Embedding、稀疏向量Sparse Embedding还是两者混合稠密向量是目前RAG的主流选择它的初衷是解决同义词、语义近似的问题——“如何退款”和“退钱流程”在字面上完全不同但语义上很接近稠密向量可以把它们映射到相近的位置。Embedding模型通常是一个Transformer编码器把整个文本编码成一个固定维度的向量常见的有768维、1024维、1536维。维度越高表达能力越强但存储成本和计算成本也同步上升。稀疏向量则是另一种思路更像是传统的关键词匹配升级版它保留词级权重但比TF-IDF多做了一步语义扩展。实践中我越来越倾向于把两者做加权融合稠密向量保证“语义相似但不含关键词”的内容能被召回稀疏向量保证“精确匹配关键词”的高质量结果排在前面。纯稠密方案在专有名词、编号、型号这类场景下经常丢分比如用户搜索“A100显卡”时文档里写的是“NVIDIA A100 Tensor Core GPU”虽然语义相同但稠密检索往往没有精确匹配给到的置信度高。3.2 从榜单选型到业务验证Embedding模型选择的正确姿势每次有新的Embedding模型发布总能在RAG社区引起一阵换模型的躁动。但我的建议是不要被公开榜单带跑排行榜上的分数是在特定评测集上测出来的和你的业务领域往往存在分布偏移。应该在选型阶段准备一小批业务真实数据用手头要解决的检索问题做对比测试而不是直接信网上的平均分数。具体测试方法也简单挑出50到100条有代表性的业务查询把对应的正确答案准备好然后分别用不同的Embedding模型生成向量在相同的分块和检索参数下跑一遍召回率对比。这个测试成本很低但远比任何榜单都贴近你的真实场景。模型本身的大小和推理成本也要纳入考量。有些大模型效果确实好但单条向量化的推理时间动辄几百毫秒在需要大批量入库时这个成本会被放大到难以接受。我在实际项目中比较常用的是那类参数量适中、向量维度768或1024的通用型模型它们效果在线推理速度快服务器成本可控。有预算再考虑引入更大参数的模型作为精排阶段的重排模型这个后面会讲到。3.3 向量归一化和向量化服务器的并发设计向量归一化是个经常被忽略的细节。很多Embedding模型的输出向量并没有做过L2归一化而向量数据库在计算余弦相似度时如果向量没有归一化需要每次都计算模长既影响性能也影响某些ANN索引的精度。所以我一般在入库和查询两侧都加一个归一化预处理把向量模长统一为1这样余弦相似度就等于内积计算更快速还能配合支持内积距离的索引类型。向量化服务本身也要设计成可横向扩展的无状态服务。入库阶段和查询阶段对向量化服务的调用模式差异很大入库是批量高吞吐查询是低延迟交互。我见过不少项目把两者混在同一个服务里批量入库时把查询接口的响应时间拖到了几秒。稳妥的做法是用两个独立的部署池一个面向批处理入库存量一个面向线上查询必要时可以给查询池配置更强的GPU或更快的推理框架。热词里提到的“向量化服务器”本质上就是这个环节的基础设施。如果你只是个人项目或小规模知识库甚至可以不单独部署向量化服务直接在入库和查询的进程内调用模型推理。一旦进入多业务线共享知识库的阶段一个独立的向量化服务就变得必要因为它能把模型推理资源集中管理避免每个业务线都各自部署一套模型。4. 向量数据库里不存在银弹索引、召回、混合检索的搭配逻辑向量化工作做完了接下来是把向量存进数据库。很多人以为向量数据库只是个存向量的地方随便选一个就行。但真实情况是向量数据库的索引选择和检索参数对召回质量的影响不亚于Embedding模型本身。4.1 精确检索还是近似检索一个需要算清楚的账向量检索有两种泾渭分明的路线精确检索比如暴力扫描Flat索引和近似最近邻检索ANN如HNSW、IVF。精确检索的召回率是100%代价是查询慢数据量大时完全不可行。近似检索速度快但会有召回损失具体损失取决于索引参数配置。对大多数RAG项目来说暴力扫描是不可能承受的因为数据量往往在几十万甚至上百万级别。HNSW是当前最主流的近似索引方案它通过多层图结构实现快速跳转查询时从顶层开始逐层向下每一层找到局部最近的点最终逼近全局最近邻。HNSW的几个参数值得花时间调M值每个节点的最大连接数越大召回越准但索引越大、efConstruction建图时的搜索宽度、efSearch查询时的搜索宽度。我的建议是先从默认参数跑一轮记录召回率再逐步提高efSearch观察召回率提升与延迟增加的性价比曲线。另外这里要特别说一下列表中的“向量化和向量数据库”这个热搜词暴露出的常见误区以为向量化完了直接丢进数据库就能查得很好。实际上向量数据库内部还会做两层处理——量化压缩和索引重排。很多向量数据库为了压缩内存占用默认开启量化这会导致信息损耗。如果业务对精度要求高要留意量化参数的配置或者干脆在实际测试中对比量化前后的召回差异。4.2 混合检索与Rerank让精确匹配和语义匹配各司其职纯向量检索在RAG项目里越来越难以独立支撑业务需求这是我的总体判断。真实的用户查询往往同时包含语义需求和精确需求。用混合检索的方式结合稠密向量和稀疏向量是当前更稳健的做法稀疏部分负责精确关键词匹配稠密部分负责语义扩展。混合检索的落地有两种形式一种是在向量数据库层面直接支持例如同时建向量索引和全文索引然后做RRF加权融合另一种是在应用层分别调用两种检索接口再做结果合并。前者性能好但融合策略相对受限后者灵活度高可以做更精细的加权逻辑。小规模项目两种都行大规模高并发场景优先考虑数据库原生支持。重排Rerank是检索链路上值得投入的一环可以说它是性价比最高的精度提升手段。无论是稠密检索还是混合检索第一轮拿到的都是粗排结果Top-N可能包含噪音。用一个精排模型对这Top-N条重新打分效果会显著提升。精排模型通常是交叉编码器Cross-Encoder它把查询和候选片段拼接成一对输入做精细的关联度打分比双塔结构生成向量的Embedding模型精度更高但因为需要逐条推理速度慢得多所以只能做粗排阶段之后的小规模精排。4.3 数据量大时的分层存储策略当知识库规模超过了单机内存能承载的范围分层存储就变得必要。实践中常见的方案是“热数据走向量索引冷数据走对象存储加延迟加载”。把高频访问的文档放在高性能向量索引中低频访问的大文档只保留元数据或摘要向量查询时如果摘要命中再去对象存储取全文重新向量化。这个思路和互联网架构里的多级缓存是一个道理。不过我也要泼一盆冷水如果知识库规模还没有到千万级折腾分布式向量检索很多时候是过度设计。单个实例上用HNSW索引承载百万级向量完全可行先把单机吃透再考虑分片。5. 当RAG开始长脑子知识组织、重排与Agent化之后的管道变化基础管道跑顺了很多团队会忍不住向前一步从“文档碎片检索”走向“知识组织检索”再从“单轮问答”走向“多步推理”。这个方向确实有价值但每一步都会对数据管道提出新的要求而且这些要求往往和最初的设计相冲突。5.1 Ontology与知识分层把散碎片段重新粘起来检索碎片化的问题是RAG的老毛病召回了一堆片段但片段之间的逻辑关系没有被表达出来。一个常见的改进是用Ontology或知识图谱为RAG构建一个上下文骨架。这并不意味着要搞一个庞大的图谱工程。轻量级做法是在原有Chunk之上增加层级关系——知识库由多个主题域构成每个主题域下有多篇文章每篇文章由若干Chunk构成。查询时先通过意图识别定位主题域再在主题域内部做向量检索。这样可以有效避免跨领域的高相似度片段互相干扰比如“退款”在售后文档和财务文档里语境完全不同用主题域隔离后查售后时不会被财务文档的“退款”跑偏。更重量的做法是引入实体关系图把文档中的人名、产品名、指标名抽取出来形成图谱和图谱查询结合RAG一起使用。这类“Ontology RAG”在垂直行业很有价值因为它解决了“知识碎片之间失去上下文”的痛点让模型的回答有了一张可以依赖的知识地图而不是东拼西凑的幸运抽奖。5.2 Agentic RAG管道从单次查询变成动态编排有热词在讨论“Agentic RAG”和“RAG和MCP区别”简单解释一下传统RAG是一条直线——用户提问系统检索拼接上下文生成回答。Agentic RAG则让大模型扮演调度者的角色根据问题自主决定调用哪些工具、检索哪部分知识、是否需要多轮查询。这给数据管道带来的最大变化是知识库不再只是被动的检索源而是变成了Agent可调用的一项能力服务。此时向量检索的输入输出都需要做协议化封装——定义标准的查询接口、返回结构与置信度字段。Agent需要知道每个知识域适合回答哪类问题也需要知道某次检索结果是否足够可信。这些信息来自哪里来自管道的元数据知识域的覆盖范围、Chunk的时间戳、来源可信度评级。“RAG as a Service”的理念也是这么来的。我关注到热词里有“agentscope 2.0 rag as service”本质上是把RAG能力从单项目工具升级为可复用的内部基础设施。这要求数据管道具备多租户隔离和统一治理能力不同业务线共享同一套清洗分块向量化基础设施但数据互相隔离检索策略各自配置。5.3 本地知识库场景下的资源约束与方案选择热词里还有一个“net rag本地知识库”值得聊聊。很多个人开发者或中小团队没有足够的GPU预算倾向于在本地搭建完全离线运行的RAG知识库。这个场景的资源约束非常具体不能调用云端API显卡算力有限甚至没有显卡。在有限算力下我的选型建议是Embedding模型选择轻量级中文模型维度尽量控制在768以内分块策略适当加大块大小200到300字因为轻量模型对长文本的语义捕捉能力较弱过短的块会进一步稀释信息。向量数据库选择纯本地嵌入式方案几百毫秒内完成近十万级向量的检索完全不是问题。重排阶段可以选择不跑交叉编码器而是用关键词重叠度加BM25分数做轻量重排效果能达到交叉编码器的七八成但延迟几乎为零。本地知识库还有一个优势很多人没意识到隐私和数据安全。不少企业内部文档不允许出内网本地化部署是唯一合规路径。这种情况下即使云端Embedding模型效果更好也必须放弃法律合规的红线是不能碰的。6. 一套能落地复查的评估方法与个人踩坑记录最后聊聊容易被忽视但在真实项目里回报率最高的部分评估。很多RAG项目死在“感觉挺好但说不清哪里好”的状态里。没有量化评估你就无法判断一次改动到底带来了提升还是回退也无法向团队或老板说清楚为什么要花时间优化数据管道。6.1 检索质量与生成质量分离评估RAG评估必须分层。第一层是检索评估给定一组问题检查召回的内容是否符合预期。核心指标是RecallK前K条结果中包含正确答案的比例和MRR正确答案在结果列表中的平均倒数排名。第二层是生成评估将检索结果拼进上下文后大模型生成的回答是否准确、完整、忠实于检索内容。这两个层面的评估要分开做。如果生成质量不好可能是检索的问题也可能是大模型本身的指令遵循问题还可能是上下文拼接方式的问题。混在一起评估只会让你无从下手。先用检索指标确认召回率达标再去看生成环节。生成评估里还有一个特别容易踩的坑用大模型来评估大模型。现在很多RAG项目引入LLM-as-a-Judge用GPT系模型给回答打分。这个做法可以参考但不能迷信尤其是涉及专业领域时评估模型本身的领域知识可能比被测模型还差。更稳妥的方案是建立一小批人工标注的黄金数据集哪怕只有一二百条定期回归测试比完全依赖模型打分靠谱得多。6.2 从失败案例反推管道缺陷的三个典型模式我在项目里总结过检索质量差最常见的三个模式遇到问题可以先对照排查第一个模式是“提到的关键词完全没召回”。这通常不是向量检索的问题而是源文档在解析或清洗阶段丢了内容比如扫描PDF的OCR识别率太低、表格被错误截断、或网页抓取时正文被过滤掉。问题出在管道最前端跑向量化之前就已经丢了。这种Case一旦出现要优先检查源文档预处理链路的日志。第二个模式是“召回了相关内容但不是用户想要的”。这往往是分块粒度不对。比如一块里包含了两个主题用户查主题A时向量重心被主题B的内容拉偏导致排序时排到了后面。解决方式是细化分块粒度或者用主题域/章节结构做隔离。第三个模式是“检索结果是对的但生成的答案胡编”。这是最让人迷惑的情况。原因通常是上下文窗口使用不当检索回来的多个片段互相矛盾而拼接时没有做冲突消解或者把所有片段一股脑堆给大模型模型在超长上下文中注意力分散最终被个别噪音片段带偏。对策是限制拼接数量并增加一个生成前的相关性过滤只保留与用户查询明显相关的片段。6.3 个人踩坑记录做一个索引迁移项目时走了哪些弯路最后分享一个印象深刻的教训。去年某个项目从开源向量数据库迁移到云托管向量数据库本以为迁移过程只是导出导入实际上踩了整整一周的坑。问题出在索引参数原库的HNSW的M参数设置的是16新库默认是32虽然索引更精细了但建图时间和内存占用显著上升最要命的是这批配置变更并没有让召回率提升多少——因为原始文档的向量质量本身就一般索引参数的微小变化根本弥补不了源头的质量问题。这个教训让我彻底改变了做事的顺序先想办法提升数据管道前端的质量解析清洗分块而不是一上来就折腾检索侧的参数。索引参数、重排模型的调优是在前端质量稳定之后才做的锦上添花而不是雪中送炭。另一次教训是关于元数据的。早期我觉得元数据就是给每个Chunk打个标签随便存一下就行。后来做基于时间的过滤查询只查最近一个月的文档时才发现当初入库时根本没有记录文档的创建时间字段导致所有时间过滤都无法实现只能重新清洗入库。从那以后我坚持在数据管道里做一套标准的元数据字段模板文档来源、作者、部门、创建时间、入库时间、版本号、内容哈希、权限标签。这套模板从第一个项目沿用至今帮我避开了无数后续的麻烦。回到开头那句话RAG成功的关键不在某一个环节而在于整条数据管道是否健康。分块和向量化确实重要但它们只是管道中游的两个节点。上游的源数据接入、解析清洗中游的分块向量化、索引构建下游的检索重排、生成评估每一环都在影响最终的用户体验。与其在一个环节上反复纠结不如把视野拉高把整条链路跑顺、测稳、养好。这条路上没有银弹但每一步做扎实了你的RAG项目就已经超过了大多数停留在“切块丢向量库”阶段的同行。