很多人做RAG检索增强生成项目一开始就把精力全砸在向量数据库选型、Embedding模型调优、Prompt编写上结果效果依然稀烂。我踩过这个坑之后回头复盘发现问题的根源往往不在检索和生成环节而在于最前端的数据——你根本没搞清楚自己手里的数据是什么类型就直接往上套通用流程了。从数据类型出发理解RAG是一个被绝大多数教程忽略但极其关键的视角。RAG全称Retrieval-Augmented Generation它的核心逻辑很简单先从外部知识库检索出相关内容再把检索结果交给大模型生成答案。但整个链路能不能跑通、跑得好不好完全取决于数据在进入系统之前你有没有针对它的类型做好预处理。文本、表格、JSON、代码、PDF扫描件、PPT、日志、协议文档这些不同类型的数据对应的是完全不同的解析方式、切片策略和检索方案。这篇文章我会从数据类型这个底层视角出发把RAG的全链路拆开讲清楚。内容包括为什么数据类型决定了RAG的上限、每种数据类型适配什么处理方案、Embedding和向量检索环节有哪些容易被忽视的坑、Graph RAG和Agentic RAG分别在什么数据类型下才值得用以及银行、3GPP协议文档、代码库这些实际场景怎么落地。适合正在做RAG项目、被效果问题折磨得头秃的工程师也适合刚入门想建立全局认知的初学者。1. 整体思路数据形态先于技术选型1.1 为什么我从数据类型切入而不是先选框架RAG技术栈里能选的组件太多了。LangChain、LlamaIndex是框架Chroma、Milvus、FAISS是向量库OpenAI、BGE、M3E是Embedding模型还有很多国产框架也做得不错。但如果你一上来就陷入框架选型很容易忽略一个最基本的事实RAG是一个数据处理系统不是模型调用系统。我在实际项目中最深的体感是数据决定了RAG的边界。文本类数据是最舒服的切一切、向量化、检索就能跑起来表格类数据和PDF扫描件就比较麻烦你不做结构识别和特殊处理出来的检索结果基本没法看JSON、XML这种半结构化数据如果你直接当纯文本切片层级关系全丢了检索到的内容大模型根本读不懂还有代码库、协议文档、法律合同、银行流水这种专业数据每种都有自己独特的语义结构。所以我现在接手一个RAG项目第一件事先做数据盘点。不看用了什么框架不看Embedding模型多大先问几个问题你们的数据源是什么PDF是文字版还是扫描版Excel表格是二维表还是透视表有没有JSON接口返回的日志数据库里的字段注释有没有维护这些问题回答完了RAG的整体方案基本就能定下大半。1.2 先给数据分个类再看技术选型为了方便讨论我把RAG项目中常见的数据类型粗分成五类。这个分类不是严格的学术分类而是从工程处理角度出发的数据类型典型载体处理难度RAG适配优先级纯文本Markdown、TXT、Word正文、协议书低高结构化表格Excel、CSV、数据库导出中中需要特殊处理半结构化数据JSON、XML、YAML、接口日志中高中取决于层级复杂度多模态文档PDF扫描件、PPT、图片、报表高低需要OCR和多模态能力专业代码/协议源代码、通信协议、规范文档高中需要结构感知这个表并不是说表格类数据就不适合做RAG而是说你不做适配直接硬跑效果一定差。理解了数据类型之后RAG的很多问题就不再是玄学而是可以归因到某个具体环节去解决的。2. 每一种数据类型都有它自己的“脾气”2.1 纯文本最友好但也不一定简单纯文本是所有数据类型里最适合做RAG的但“适合”不代表不需要思考。常见的问题反而是因为觉得简单就掉以轻心。第一是切片粒度。很多人直接用固定窗口切片比如256个token或512个token切一块相邻块之间加一点重叠。这个方案对一般性的技术文档、百科类文本是够用的但对强逻辑、强上下文的文档就不行了。比如一篇论文的“实验方法”和“实验结果”分属不同部分但结论高度依赖方法的细节如果你按固定窗口切片一个完整的方法描述可能被拦腰截断甚至被分到两三个不同的块里检索时找回来的内容是残缺的生成质量自然上不去。第二是格式信息。Markdown的标题层级、加粗、列表、代码块这些格式本身就是语义的一部分。你把这些格式全剥掉再切片等于把文章的逻辑骨架扔了。我常用的做法是先用markdown解析器把文档结构提取出来比如标题层级、表格、代码块、列表再基于结构去做切片。这样做的好处是每个切片本身就是一个语义完整的单元比如一个二级标题下的完整小节。第三是语言差异。中英文混合文档、代码注释多文档、专业术语密集的文档各自适合的切片策略都不一样。中文里按字数切片的稳定性不如按token数切片因为Tokenize后的中文字符和英文字符数量差异很大代码注释多的文档最好把代码和注释分开处理检索代码时用代码语义检索注释时用自然语言语义。2.2 结构化表格数据库里躺着好好的一进RAG就废了表格类数据是RAG翻车重灾区。我见过最典型的场景公司的商品信息存在MySQL里字段有商品名称、价格、库存、销量、上架时间一共几十万条记录。直接把这些记录转成文本丢给RAG问“库存大于100的商品里销量最高的三个是什么”检索回来的内容几乎不可能对齐因为模型不是查询引擎你让它从一堆被切片切碎的文字碎片里做过滤和聚合本来就是逆天而行。处理表格数据我有一个实操过多次的方案每一条数据库记录也就是一行作为一个独立的文档单元把它转换成一句自然语言描述。举例来说一条商品记录可以转换成商品编号SP10032商品名称为无线蓝牙耳机Pro版品牌为SoundMax 价格499元库存320件月销量1280件上架时间为2025年3月12日 所属分类为数码音频评价得分为4.8分满分5分。这样每条记录就是一个语义完整的单元向量化之后用户问“500元以下的蓝牙耳机哪个评分高”就有可能通过语义匹配召回“SoundMax无线蓝牙耳机Pro版”这条记录。为什么不是直接让大模型去查数据库因为RAG的价值在于你可以在不写SQL的情况下对非技术人员开放“用自然语言查数据”的能力。但从工程角度讲如果你的场景是固定维度的精确查询用Text-to-SQL方案可能更靠谱。RAG更适合的其实是“模糊检索总结归纳”类问题比如“我们卖得最好的数码产品都有什么共同特征”。还有一类表格是Excel里的维度表、配置表、交叉表比如不同产品线在不同区域的销售目标矩阵。这种二维表格比较复杂直接按行转文本会丢失列头信息按列转又会丢失行信息。我的做法是先把表格转成Markdown格式保留完整的表头和行列对应关系然后再把整个Markdown表格作为一个整体切块放进去。实践中发现大部分Embedding模型能比较好地理解Markdown表格的结构语义但你不能在切片时把表头和内容拆开。2.3 半结构化数据JSON、日志、接口返回层级关系是命根子JSON、YAML、XML这类半结构化数据在RAG项目里出现频率越来越高尤其是做企业内部知识库的时候很多系统的配置信息、接口文档、日志样本都是JSON格式。最糟糕的处理方式是把JSON转成纯文本字符串然后直接切片进向量库。这样做的结果是一个嵌套很深的JSON对象被切片器从中间切断子对象和父对象的关系完全丢失。检索的时候召回到的是碎片大模型的输出基本靠猜。正确做法是保留JSON的层级结构并用路径Path来标识每个节点的语义位置。比如说一个接口返回里包含“user”节点下面有“profile”子节点再下面有“address”子子节点。那“address”里的“city”字段它完整的语义路径就是user.profile.address.city。在切片的时候我建议把每个叶子节点最底层的字段及其路径拼在一起形成一条独立的检索单元比如路径定位: user.profile.address.city 字段值: 上海 字段含义: 用户所在城市这样做的好处是用户如果问“上海的用户有多少”系统可以通过语义检索找到所有city字段值为“上海”的条目同时路径信息告诉大模型这个字段的确切位置和含义生成答案的时候不会张冠李戴。日志类数据比JSON还麻烦。日志是时间序列数据天然带有顺序关系但一个日志系统里的日志量动辄每天几百万条不可能全部向量化。实际项目中我只对日志模板去掉可变参数后的固定格式做RAG把模板和对应的报错建议、修复方案配对。这样既控制了数据量又能保证“这个报错是什么意思、怎么处理”这类问题的答案质量。2.4 多模态数据与扫描件跨过“能不能提取文字”这道门槛再说PDF扫描件、PPT、产品图片、报表截图这类数据在RAG里属于高难度区。原因很简单RAG的常规链路默认输入是文本你喂一张图片进去除非你用了多模态Embedding模型否则系统根本无从处理。我的建议是分两步走。第一步先解决“提取”问题。PDF扫描件先用OCR把它变成文字层PPT最好导出成带备注的PDF再解析图片类的内容要么走多模态模型识别成文字描述要么放弃进入RAG。第二步才是切片和向量化。这一步有一个实操细节很多人忽略OCR出来的文字是纯平铺的没有排版结构比如表格线的位置、换行缩进、标题层级全部丢失。因此OCR文本进RAG之前最好先用规则或者小模型把结构重建一下至少要把标题行识别出来。不然一段扫描版合同条款和附件内容搅在一起检索效果是可以预见的差。现在也有一些多模态Embedding模型可以直接对图片建索引比如CLIP那一路的模型以及一些商用API提供的图片向量能力。在报表分析、海报合规审查等场景里确实有用。但多模态模型的部署成本和检索精度目前还是不如纯文本方案稳定所以我的建议是能提取成文本就优先提取提取不了的再考虑多模态。3. 从数据到检索全链路的四个环节逐一拆解3.1 数据解析一切效果问题的源头RAG全链路可以抽象成四个环节喂入、切分、索引、检索。我们用过很多RAG框架也自己踩了不少坑最终发现如果喂入环节做不好后面全白搭。喂入环节也就是数据解析最容易被低估。很多PDF解析出来里面不是文字而是图片直接喂进去检索自然一团糟。我处理过最典型的案例是一个3GPP协议文档的RAG项目文档中大量内容是以表格和示意图形式存在的协议正文里还有大量的交叉引用。如果解析阶段不做特殊处理直接按普通文本切片那协议条款之间的关联信息比如“第5.3.2节定义了承载建立流程与该流程相关的过程详见第6.2.1节”在检索中大概率匹配不上。我的经验是解析阶段至少要对文本做三层处理。第一层是类型判断。自动识别文件是文字版PDF还是扫描版是Word还是Markdown是单栏还是多栏排版。多栏排版的文档比如论文双栏如果直接按页切文字顺序会乱掉必须先做版面分析。第二层是结构抽取。标题层级、表格结构、代码块、引用关系、页眉页脚这些都要在解析阶段抽取出来并打上标签。这一步做得好后续的切片和检索会非常省力。第三层是清洗过滤。页眉页脚、页码、水印、多余的空白行这些噪声不清理向量化之后就是一堆没用的向量占内存还会干扰检索排名。3.2 切片策略不存在万能方案只看数据形态切片是RAG里讨论最多、也最玄学的一环。常见的策略有固定窗口切片、基于分隔符切片、基于语义切片、基于文档结构切片。我不想一一罗列每个策略的定义直接说结论固定窗口切片适用于无明显结构的文本比如新闻语料、百科词条。基于分隔符切片的典型是按“换行”“句号”切适合段落感强的文本但遇到长表格、长代码块会切得稀碎。基于文档结构切片是我最喜欢的按标题层级切一个二级标题下所有内容作为一个块。这个方案对Markdown写的技术文档、规范文档效果最好。如果文档结构清晰但不规整可以先做结构归一化再用结构切片。基于语义切片效果上限最高但计算成本也最高通常需要先用一个轻量模型判断句间相似度来划分语义边界。工程上一般不用它做全量数据而是聚焦在关键文档上。针对表格数据我一贯的做法是行式记录按行转文本列式配置按列或按区域转文本二维统计矩阵整体转Markdown表格。这里有一个细节转成Markdown表格之后建议单独将表头抽取为一句独立索引这样用户提问时如果只提到表头字段也能命中。3.3 检索环节稠密检索、稀疏检索和混合检索的适配性检索是RAG最核心的环节。今天主流的检索方式有三类稀疏检索BM25为代表、稠密检索向量检索和混合检索两者结合。稀疏检索的本质是词匹配。它不关心语义只在乎词面上重不重合。它的优势是精确匹配能力极强特别适合专业术语、ID号、型号、协议名称这类必须“一字不差”的查询。缺点是它不理解同义词和上下位概念问“水果”匹配不到“苹果”。稠密检索的本质是语义匹配。它对含义相近、但词面完全不同的内容有很好的召回能力缺点是偶尔会产生和查询词表面相关、但实际无意义的误召回。混合检索是目前工程上最稳妥的组合拳。先用BM25和向量检索各拿一批候选结果再用重排序模型Reranker对两批结果统一排序。我实测下来混合检索比单独用其中一种在绝大多数场景下能提升10到20个百分点的召回准确率代价是多一次Reranker的模型调用。关于向量检索有一个几乎没人提、但在实际项目中影响巨大的细节不同数据类型的向量最好分开建索引。不要把纯文本块的向量和表格记录的向量、JSON字段的向量全混在同一个Collection里。分开之后你可以为每一类数据设置不同的检索权重。比如代码库场景里代码语义匹配的权重高一些合同审查场景里条款文本的权重高一些。4. Embedding这一步数据类型如何影响“语义向量”的质量4.1 Embedding不是万能药它也是被数据类型支配的Embedding的核心作用是把一个文本片段映射到一个高维向量空间向量之间的距离表示语义距离。但大多数人忽略了一件事Embedding模型是在特定类型的语料上训练的它对“训练时见过的文本形态”最敏感。比如你用通用中文Embedding模型去向量化数据库表结构转出来的文本效果一定不好因为Embedding模型在训练时很少见过“字段名字段值”这种形态的内容。同样的代码和自然语言混合的内容很多Embedding模型处理起来也会很挣扎。所以这里的建议倾向于第一优先选用针对目标场景做过微调的Embedding模型或者在选型阶段就做一个小规模的评测集来测试第二在向量化之前把数据形态尽量靠近Embedding模型擅长的形态。比如表格记录转成“字段名是X值为Y”的自然语言描述这就比直接拼接col_axx|col_byy更容易得到高质量的向量。4.2 精度细节Embedding模型的“数据类型”偏好还有一个更细的维度容易被忽略就是Embedding模型本身对文本长度的适应性。有的模型对短文本效果好有的模型对长文本更友好。如果你的数据切片平均长度在100个token左右就别用官方推荐max_length是512的模型结果做无脑截断如果你的切片有2000个token但Embedding模型最大只能处理512个token多出来的部分直接被截掉了那段语义丢失了。这种情况要么把切片改短要么换支持长文本的Embedding模型。另外我强烈建议在向量化之前做一次数据抽样验证。就是把向量化之后的数据随机抽出一些样本人工检查向量检索的召回结果是否合理。这一步看起来费时但能帮你提早发现问题等上线之后再调就晚了。4.3 数值类型细节int、float与精度问题既然是从数据类型出发我这里顺手提一个更底层的点。在RAG的数据结构设计里你存入向量库的每个Document都会有若干字段比如原始文本、元数据、创建时间、来源等。这里面的时间、数值、价格等字段尤其要注意类型设置。举个例子你用Chroma或Milvus存商品信息里面的“价格”字段原始值可能是字符串“499元”也可能是浮点数499.0。如果你在检索时想用元数据过滤条件筛选“价格小于300的商品”那这个字段必须是数值类型才能比较。如果初始导入时没有做类型转换后面查询就会一直报类型错误或者查出错误结果。PyPandera类型转换、Pandasastype、SQL里CAST这些都是数据处理里的基本功但在RAG项目里它们同样重要。我自己实践中就踩过“价格字段存成了字符串导致元数据过滤失效”的坑排查了半天最后发现是类型问题。所以数据进向量库之前先做一个字段类型规范表把每个元数据字段的类型都钉死能省很多事。5. 遇到复杂数据类型时图RAG和Agentic RAG怎么选5.1 多路检索给不同数据类型分配独立的处理通道当一个知识库里同时存在文本、表格、JSON和代码时我的第一反应不是把它们全部塞进同一个管道而是设计多路检索架构。多路检索的意思就是每一种数据类型单独建一个处理管道文档走文档解析和结构切片表格数据走行转文本JSON数据走路径提取。每条管道各自有自己的索引检索时并行发起请求然后再合并结果。合并的时候需要一个权重策略。比如法律合同场景条款文本的权重应该高于附件表格的权重商品运营场景表格数据的权重可能高于商品介绍文案的权重。这个方案看起来复杂但工程落地并不难。LangChain里可以用MultiVectorRetrieverLlamaIndex里有典型的PropertyGraphIndex和多路召回设计如果你用国产框架或者完全自研核心思想都是把不同类型的数据分开处理、共享一个统一的重排序层。5.2 Graph RAG关系密集的数据类型要上图结构Graph RAG最近话题度很高热搜词里也有graph rag图搜索。但Graph RAG不是银弹它有明确的使用边界。Graph RAG适合的数据类型有一个共同特征实体密集且关系复杂。比如企业知识库里的组织架构、人员权限、项目依赖关系再比如一个软件系统里的模块、接口、数据流向关系。这些内容如果用纯文本RAG检索结果是一段一段的碎片实体间的关系要靠大模型去猜。但是用图结构把实体和关系提前抽出来Graph RAG就能在检索时沿着关系路径做多跳推理。举个例子用户问“A模块挂了会影响哪些下游服务”。文本RAG只能检索到描述A模块故障的文档片段Graph RAG可以先定位A模块节点顺藤摸瓜找到所有依赖链路上的下游服务节点。这是纯向量检索很难做到的多跳能力。但Graph RAG的成本不低。实体和关系的抽取需要调用LLM做一遍全量信息抽取对大文档库来说费用和时间都很高图数据库的运维也比向量库复杂得多。所以我的建议是如果你的数据实体间的关系非常密集且多跳问答是核心需求才考虑Graph RAG一般性的知识库问答用不上。5.3 Agentic RAG把“该走哪条检索路径”交给智能体Agentic RAG是另一个热门方向它的思路是不再把RAG当成一条固定管道而是交给一个Agent来自主决定该检索普通文档还是该查询数据库还是该调用一个外部API还是该先做一次信息抽取再进入检索。用数据类型来理解Agentic RAG就非常顺了。传统RAG对数据的处理方式是“我不管你是什么类型统一切块、统一向量化”Agentic RAG是“我先判断你是什么类型再决定处理策略”。这其实就是把我在第1节说的“数据盘点”工作前移到了运行时。实际操作时Agentic RAG通常需要一个路由模块。它先解析用户问题判断问题涉及的数据类型然后选择对应的工具或检索管道。举个例子用户问“我们上月销售额环比增长了多少”Agent会路由到结构化查询模块去数据库跑一个聚合查询用户问“销售合同里的违约责任条款有哪些”Agent路由到文档检索管道两个都涉及的情况Agent会先并行查询再合并。这个方案目前工程成熟度不如传统RAG但复杂企业场景下的效果上限更高。如果你正在做Java RAG或Spring AI相关的项目Agentic RAG已经有比较多的启发式实践可以借鉴但别把它想成开箱即用的库。6. 行业实战银行、3GPP协议、代码库6.1 银行RAG数据类型敏感更要强调合规审计银行场景下的RAG数据类型的复杂性更多体现在私域数据上。银行内部的制度文件、信贷审批规则、产品说明书、客户服务指引部分是Word和PDF部分是Excel表单还有一部分存在核心系统里以接口返回的JSON格式存在。银行做RAG有一个很敏感的合规问题数据不能出域。你不能把客户的交易流水、身份证号、手机号直接送到外部的大模型API去生成向量。所以银行场景下的RAG架构通常是私有化部署Embedding模型和LLM如果用了外部模型API则只能处理脱敏后的数据。我参与过的银行RAG项目里最关键的不是模型精度而是权限控制和审计追踪。同一个知识库里不同岗位的人能检索的内容必须不一样。这就需要在数据导入阶段给每一份文档打上权限标签并在检索时将用户的角色信息作为硬过滤条件。这些元数据标签本质上就是数据类型的又一维扩展——不是内容类型而是访问类型。6.2 针对3GPP协议的RAG超长规范化文本怎么切3GPP协议文档是通信行业标准文档特点是篇幅极长动辄几百上千页、术语极其规范、章节编号严格、表格和流程图多、交叉引用密集。直接拿通用RAG方案去处理基本没法用。我处理这类项目时的经验是把协议的结构化信息抽出来单独建模。章节编号是天然的切片边界协议里的表格要单独抽取并保留表头和注释交叉引用要建立双向链接术语表要单独建索引。切分协议文档时我不用固定字符数而是按“章节”和“子章节”切这样每个切片的语义完整性有保障。还有一个实用的技巧在切片的开头加上该切片在完整协议中的“坐标信息”比如“TS 38.300 V16.2.0第8.3.2节属于RRC连接管理部分”。这样当切片被检索到时大模型能清楚知道这段内容的出处和上下文回答的准确性会高很多。6.3 Java/Python开发者的RAG代码数据类型的特有挑战开发者在自己的项目里做RAG常见的数据源是自己的代码库、技术文档、Stack Overflow问答、GitHub Issue等。这里有一个特殊的挑战代码是一种半结构化强逻辑的数据类型它的语义不止存在于文本层面还存在于执行逻辑中。比如你问“这段代码里的并发安全问题在哪里”如果RAG只能检索到代码片段的字面内容而不知道这段代码的调用上下文、共享变量定义、锁的获取顺序它很难给出靠谱的回答。所以代码库RAG的通用做法是不仅索引代码文本还要索引代码的AST抽象语法树结构、函数调用关系、依赖关系。这些信息可以作为元数据附在代码切块上也可以在需要深度分析的时候借助Agent去读取完整的代码上下文再做回答。小技巧方面检索代码时用混合检索很有帮助。函数名、变量名是强词面匹配BM25对这类检索非常有效而“查找有内存泄漏风险的代码”这类语义查询向量检索更适合。两者一结合覆盖度会高很多。7. RAG效果测评不只是看指标更要反推数据类型的问题7.1 核心指标拆解从指标异常定位到数据类型问题RAG测评怎么做热搜词里关注度很高。我这边说说在实操中怎么把指标和数据质量问题关联起来。RAG的核心指标可以分成两块检索质量和生成质量。检索质量的常见指标有召回率RecallK、命中率Hit Rate、MRRMean Reciprocal Rank。生成质量的常见指标有忠实度Faithfulness、答案相关度Answer Relevance、上下文相关度Context Relevance。如果忠实度低也就是说大模型生成的答案和检索到的上下文不一致甚至相悖优先怀疑数据处理环节——是不是切片切碎了导致上下文不完整是不是表格转文本丢失了对齐关系。如果召回率低优先怀疑检索策略——是不是用了纯稠密检索导致术语匹配失败是不是Embedding模型对专业领域适配性不够。如果相关度低优先怀疑索引设计——是不是不同数据类型的向量混在了一个集合里导致结果被某些类型的噪声干扰。7.2 测评集怎么建才有效测评集的建设要围数据类型来设计这一点很少被人重视。我建议按数据类型分类建立测评用例纯文本类问题30%表格类问题20%JSON或结构化数据类问题20%跨类型综合问题20%边界问题数据不存在、数据不完整10%。每个用例要写清楚用户问题、期望答案或关键信息点、命中的数据文件或记录ID、答案来源类型。有了这个测评集你才能精准定位到“到底是哪个类型的数据在拖垮整体效果”。我见过不少团队拿一二十道通用问题做测评测出来效果还行一上真实数据就崩。这往往就是测评集没覆盖到真实数据里的复杂数据类型。7.3 一个实际案例把RAG从63%拉到81%我在做一个企业内部制度问答RAG项目时一开始用通用处理流程所有文档统一转Markdown、统一按固定长度切片测评召回率只有63%。后来我按数据类型拆开看发现拖后腿的是两类数据一个是Excel里的奖惩细则表一个是PDF扫描版的红头文件。Excel表被当成文本切碎后奖惩对应关系全乱了扫描版PDF没做OCR和版面重建检索到的内容基本是乱码。针对性地做了两件事Excel表改成按行转文本并保留表头信息扫描件先OCR再加版面分析重建结构。重新跑测评召回率从63%涨到了81%。整个过程中我没有换Embedding模型没有换向量库只是把数据类型的适配做对了。这个案例给我的启发是RAG项目的优先级是先治数据再调模型最后才轮到换框架。8. 常见问题与排查速查表结合我自己的实操经验和踩过的坑整理一个RAG项目常见问题速查表覆盖从数据类型到链路各环节的排障方向问题现象可能原因排查与解决方向检索结果和问题完全无关数据类型误判表格/JSON被当纯文本处理核对数据解析策略检查切片内容确认是否保留了结构信息召回了相关内容但答案仍然答非所问切片太小导致上下文不完整或关键信息被截断检查切片粒度按文档结构调整切片确保每个切片是语义完整的单元专业术语、型号、协议名称检索不到纯稠密检索缺乏精确匹配能力切换为混合检索保证BM25这类稀疏检索参与召回同一类数据的检索效果时好时坏不同数据类型的向量混在同一个集合中互相干扰按数据类型分开建索引在检索层分别召回后再做统一排序PDF文档检索效果差文件为扫描版或版面分析没做OCR后重建结构识别标题层级和表格区域后再切片Excel表格数据检索结果错乱表头和记录被拆开行列对应关系丢失按行转自然语言描述或整体转Markdown表格再单独索引表头JSON数据检索结果碎片化层级结构被扁平化后切断按路径字段切分保留父子节点关系元数据过滤不生效或字段报错字段类型未正确设置数值被存成了字符串在数据导入阶段做字段类型规范价格/时间等字段显式转换为数值类型偶尔检索到内容但不稳定文档中存在大量格式噪声页眉页脚、水印等在解析阶段加强清洗过滤剔除噪声后再向量化大模型生成时引用来源不准确检索结果缺少来源元数据文档切片时带上来源文件、章节号、行号等元数据检索结果统一回传除了表格里这些还有几条实操心得分享一下。第一永远保留原始文档和切片之间的映射关系。中间不论做了多少次清洗、转换最后检索结果里必须能追溯到原始文档和原始位置。这不仅是排障的关键也是很多行业审计合规的硬性要求。第二数据解析结果一定要抽样人工检查。解析器跑完一批文档不要直接进向量库先随机抽10到20份人工看一遍切片结果。这一步看起来慢但能避免因为一个通用的解析Bug导致整批数据效果翻车。第三RAG项目从第一天开始就要搭测评集。没有测评集你后面所有的优化都像是闭着眼开车。评测集的构建方式在上文说了按数据类型分类设计起步量不需要太大50到100条就够用关键是覆盖面要全。从数据类型出发理解RAG是我做了多个项目之后最想跟大家分享的一个角度。很多人把RAG当成一个模型能力问题实际上它更多是一个数据工程问题。数据是什么类型决定了你要怎么解析它、切片它、索引它、检索它。把这条主线理清楚很多所谓的“RAG效果不好”就不再是玄学而是可以定位、可以修复、可以验证的工程问题。最后再说一个我个人的做法吧。每次接到新的RAG项目我都会先做一个“数据体检”把客户给的所有样例数据人工翻一部分记录每份数据的类型、格式、结构、质量缺陷输出一份数据盘点报告。这份报告做完我基本能对项目的技术选型和工作量心中有数。你也可以试试这个习惯大概率会帮你在RAG项目里少走很多弯路。 数据类型决定RAG效果：从数据形态到检索优化的全链路实践
很多人做RAG检索增强生成项目一开始就把精力全砸在向量数据库选型、Embedding模型调优、Prompt编写上结果效果依然稀烂。我踩过这个坑之后回头复盘发现问题的根源往往不在检索和生成环节而在于最前端的数据——你根本没搞清楚自己手里的数据是什么类型就直接往上套通用流程了。从数据类型出发理解RAG是一个被绝大多数教程忽略但极其关键的视角。RAG全称Retrieval-Augmented Generation它的核心逻辑很简单先从外部知识库检索出相关内容再把检索结果交给大模型生成答案。但整个链路能不能跑通、跑得好不好完全取决于数据在进入系统之前你有没有针对它的类型做好预处理。文本、表格、JSON、代码、PDF扫描件、PPT、日志、协议文档这些不同类型的数据对应的是完全不同的解析方式、切片策略和检索方案。这篇文章我会从数据类型这个底层视角出发把RAG的全链路拆开讲清楚。内容包括为什么数据类型决定了RAG的上限、每种数据类型适配什么处理方案、Embedding和向量检索环节有哪些容易被忽视的坑、Graph RAG和Agentic RAG分别在什么数据类型下才值得用以及银行、3GPP协议文档、代码库这些实际场景怎么落地。适合正在做RAG项目、被效果问题折磨得头秃的工程师也适合刚入门想建立全局认知的初学者。1. 整体思路数据形态先于技术选型1.1 为什么我从数据类型切入而不是先选框架RAG技术栈里能选的组件太多了。LangChain、LlamaIndex是框架Chroma、Milvus、FAISS是向量库OpenAI、BGE、M3E是Embedding模型还有很多国产框架也做得不错。但如果你一上来就陷入框架选型很容易忽略一个最基本的事实RAG是一个数据处理系统不是模型调用系统。我在实际项目中最深的体感是数据决定了RAG的边界。文本类数据是最舒服的切一切、向量化、检索就能跑起来表格类数据和PDF扫描件就比较麻烦你不做结构识别和特殊处理出来的检索结果基本没法看JSON、XML这种半结构化数据如果你直接当纯文本切片层级关系全丢了检索到的内容大模型根本读不懂还有代码库、协议文档、法律合同、银行流水这种专业数据每种都有自己独特的语义结构。所以我现在接手一个RAG项目第一件事先做数据盘点。不看用了什么框架不看Embedding模型多大先问几个问题你们的数据源是什么PDF是文字版还是扫描版Excel表格是二维表还是透视表有没有JSON接口返回的日志数据库里的字段注释有没有维护这些问题回答完了RAG的整体方案基本就能定下大半。1.2 先给数据分个类再看技术选型为了方便讨论我把RAG项目中常见的数据类型粗分成五类。这个分类不是严格的学术分类而是从工程处理角度出发的数据类型典型载体处理难度RAG适配优先级纯文本Markdown、TXT、Word正文、协议书低高结构化表格Excel、CSV、数据库导出中中需要特殊处理半结构化数据JSON、XML、YAML、接口日志中高中取决于层级复杂度多模态文档PDF扫描件、PPT、图片、报表高低需要OCR和多模态能力专业代码/协议源代码、通信协议、规范文档高中需要结构感知这个表并不是说表格类数据就不适合做RAG而是说你不做适配直接硬跑效果一定差。理解了数据类型之后RAG的很多问题就不再是玄学而是可以归因到某个具体环节去解决的。2. 每一种数据类型都有它自己的“脾气”2.1 纯文本最友好但也不一定简单纯文本是所有数据类型里最适合做RAG的但“适合”不代表不需要思考。常见的问题反而是因为觉得简单就掉以轻心。第一是切片粒度。很多人直接用固定窗口切片比如256个token或512个token切一块相邻块之间加一点重叠。这个方案对一般性的技术文档、百科类文本是够用的但对强逻辑、强上下文的文档就不行了。比如一篇论文的“实验方法”和“实验结果”分属不同部分但结论高度依赖方法的细节如果你按固定窗口切片一个完整的方法描述可能被拦腰截断甚至被分到两三个不同的块里检索时找回来的内容是残缺的生成质量自然上不去。第二是格式信息。Markdown的标题层级、加粗、列表、代码块这些格式本身就是语义的一部分。你把这些格式全剥掉再切片等于把文章的逻辑骨架扔了。我常用的做法是先用markdown解析器把文档结构提取出来比如标题层级、表格、代码块、列表再基于结构去做切片。这样做的好处是每个切片本身就是一个语义完整的单元比如一个二级标题下的完整小节。第三是语言差异。中英文混合文档、代码注释多文档、专业术语密集的文档各自适合的切片策略都不一样。中文里按字数切片的稳定性不如按token数切片因为Tokenize后的中文字符和英文字符数量差异很大代码注释多的文档最好把代码和注释分开处理检索代码时用代码语义检索注释时用自然语言语义。2.2 结构化表格数据库里躺着好好的一进RAG就废了表格类数据是RAG翻车重灾区。我见过最典型的场景公司的商品信息存在MySQL里字段有商品名称、价格、库存、销量、上架时间一共几十万条记录。直接把这些记录转成文本丢给RAG问“库存大于100的商品里销量最高的三个是什么”检索回来的内容几乎不可能对齐因为模型不是查询引擎你让它从一堆被切片切碎的文字碎片里做过滤和聚合本来就是逆天而行。处理表格数据我有一个实操过多次的方案每一条数据库记录也就是一行作为一个独立的文档单元把它转换成一句自然语言描述。举例来说一条商品记录可以转换成商品编号SP10032商品名称为无线蓝牙耳机Pro版品牌为SoundMax 价格499元库存320件月销量1280件上架时间为2025年3月12日 所属分类为数码音频评价得分为4.8分满分5分。这样每条记录就是一个语义完整的单元向量化之后用户问“500元以下的蓝牙耳机哪个评分高”就有可能通过语义匹配召回“SoundMax无线蓝牙耳机Pro版”这条记录。为什么不是直接让大模型去查数据库因为RAG的价值在于你可以在不写SQL的情况下对非技术人员开放“用自然语言查数据”的能力。但从工程角度讲如果你的场景是固定维度的精确查询用Text-to-SQL方案可能更靠谱。RAG更适合的其实是“模糊检索总结归纳”类问题比如“我们卖得最好的数码产品都有什么共同特征”。还有一类表格是Excel里的维度表、配置表、交叉表比如不同产品线在不同区域的销售目标矩阵。这种二维表格比较复杂直接按行转文本会丢失列头信息按列转又会丢失行信息。我的做法是先把表格转成Markdown格式保留完整的表头和行列对应关系然后再把整个Markdown表格作为一个整体切块放进去。实践中发现大部分Embedding模型能比较好地理解Markdown表格的结构语义但你不能在切片时把表头和内容拆开。2.3 半结构化数据JSON、日志、接口返回层级关系是命根子JSON、YAML、XML这类半结构化数据在RAG项目里出现频率越来越高尤其是做企业内部知识库的时候很多系统的配置信息、接口文档、日志样本都是JSON格式。最糟糕的处理方式是把JSON转成纯文本字符串然后直接切片进向量库。这样做的结果是一个嵌套很深的JSON对象被切片器从中间切断子对象和父对象的关系完全丢失。检索的时候召回到的是碎片大模型的输出基本靠猜。正确做法是保留JSON的层级结构并用路径Path来标识每个节点的语义位置。比如说一个接口返回里包含“user”节点下面有“profile”子节点再下面有“address”子子节点。那“address”里的“city”字段它完整的语义路径就是user.profile.address.city。在切片的时候我建议把每个叶子节点最底层的字段及其路径拼在一起形成一条独立的检索单元比如路径定位: user.profile.address.city 字段值: 上海 字段含义: 用户所在城市这样做的好处是用户如果问“上海的用户有多少”系统可以通过语义检索找到所有city字段值为“上海”的条目同时路径信息告诉大模型这个字段的确切位置和含义生成答案的时候不会张冠李戴。日志类数据比JSON还麻烦。日志是时间序列数据天然带有顺序关系但一个日志系统里的日志量动辄每天几百万条不可能全部向量化。实际项目中我只对日志模板去掉可变参数后的固定格式做RAG把模板和对应的报错建议、修复方案配对。这样既控制了数据量又能保证“这个报错是什么意思、怎么处理”这类问题的答案质量。2.4 多模态数据与扫描件跨过“能不能提取文字”这道门槛再说PDF扫描件、PPT、产品图片、报表截图这类数据在RAG里属于高难度区。原因很简单RAG的常规链路默认输入是文本你喂一张图片进去除非你用了多模态Embedding模型否则系统根本无从处理。我的建议是分两步走。第一步先解决“提取”问题。PDF扫描件先用OCR把它变成文字层PPT最好导出成带备注的PDF再解析图片类的内容要么走多模态模型识别成文字描述要么放弃进入RAG。第二步才是切片和向量化。这一步有一个实操细节很多人忽略OCR出来的文字是纯平铺的没有排版结构比如表格线的位置、换行缩进、标题层级全部丢失。因此OCR文本进RAG之前最好先用规则或者小模型把结构重建一下至少要把标题行识别出来。不然一段扫描版合同条款和附件内容搅在一起检索效果是可以预见的差。现在也有一些多模态Embedding模型可以直接对图片建索引比如CLIP那一路的模型以及一些商用API提供的图片向量能力。在报表分析、海报合规审查等场景里确实有用。但多模态模型的部署成本和检索精度目前还是不如纯文本方案稳定所以我的建议是能提取成文本就优先提取提取不了的再考虑多模态。3. 从数据到检索全链路的四个环节逐一拆解3.1 数据解析一切效果问题的源头RAG全链路可以抽象成四个环节喂入、切分、索引、检索。我们用过很多RAG框架也自己踩了不少坑最终发现如果喂入环节做不好后面全白搭。喂入环节也就是数据解析最容易被低估。很多PDF解析出来里面不是文字而是图片直接喂进去检索自然一团糟。我处理过最典型的案例是一个3GPP协议文档的RAG项目文档中大量内容是以表格和示意图形式存在的协议正文里还有大量的交叉引用。如果解析阶段不做特殊处理直接按普通文本切片那协议条款之间的关联信息比如“第5.3.2节定义了承载建立流程与该流程相关的过程详见第6.2.1节”在检索中大概率匹配不上。我的经验是解析阶段至少要对文本做三层处理。第一层是类型判断。自动识别文件是文字版PDF还是扫描版是Word还是Markdown是单栏还是多栏排版。多栏排版的文档比如论文双栏如果直接按页切文字顺序会乱掉必须先做版面分析。第二层是结构抽取。标题层级、表格结构、代码块、引用关系、页眉页脚这些都要在解析阶段抽取出来并打上标签。这一步做得好后续的切片和检索会非常省力。第三层是清洗过滤。页眉页脚、页码、水印、多余的空白行这些噪声不清理向量化之后就是一堆没用的向量占内存还会干扰检索排名。3.2 切片策略不存在万能方案只看数据形态切片是RAG里讨论最多、也最玄学的一环。常见的策略有固定窗口切片、基于分隔符切片、基于语义切片、基于文档结构切片。我不想一一罗列每个策略的定义直接说结论固定窗口切片适用于无明显结构的文本比如新闻语料、百科词条。基于分隔符切片的典型是按“换行”“句号”切适合段落感强的文本但遇到长表格、长代码块会切得稀碎。基于文档结构切片是我最喜欢的按标题层级切一个二级标题下所有内容作为一个块。这个方案对Markdown写的技术文档、规范文档效果最好。如果文档结构清晰但不规整可以先做结构归一化再用结构切片。基于语义切片效果上限最高但计算成本也最高通常需要先用一个轻量模型判断句间相似度来划分语义边界。工程上一般不用它做全量数据而是聚焦在关键文档上。针对表格数据我一贯的做法是行式记录按行转文本列式配置按列或按区域转文本二维统计矩阵整体转Markdown表格。这里有一个细节转成Markdown表格之后建议单独将表头抽取为一句独立索引这样用户提问时如果只提到表头字段也能命中。3.3 检索环节稠密检索、稀疏检索和混合检索的适配性检索是RAG最核心的环节。今天主流的检索方式有三类稀疏检索BM25为代表、稠密检索向量检索和混合检索两者结合。稀疏检索的本质是词匹配。它不关心语义只在乎词面上重不重合。它的优势是精确匹配能力极强特别适合专业术语、ID号、型号、协议名称这类必须“一字不差”的查询。缺点是它不理解同义词和上下位概念问“水果”匹配不到“苹果”。稠密检索的本质是语义匹配。它对含义相近、但词面完全不同的内容有很好的召回能力缺点是偶尔会产生和查询词表面相关、但实际无意义的误召回。混合检索是目前工程上最稳妥的组合拳。先用BM25和向量检索各拿一批候选结果再用重排序模型Reranker对两批结果统一排序。我实测下来混合检索比单独用其中一种在绝大多数场景下能提升10到20个百分点的召回准确率代价是多一次Reranker的模型调用。关于向量检索有一个几乎没人提、但在实际项目中影响巨大的细节不同数据类型的向量最好分开建索引。不要把纯文本块的向量和表格记录的向量、JSON字段的向量全混在同一个Collection里。分开之后你可以为每一类数据设置不同的检索权重。比如代码库场景里代码语义匹配的权重高一些合同审查场景里条款文本的权重高一些。4. Embedding这一步数据类型如何影响“语义向量”的质量4.1 Embedding不是万能药它也是被数据类型支配的Embedding的核心作用是把一个文本片段映射到一个高维向量空间向量之间的距离表示语义距离。但大多数人忽略了一件事Embedding模型是在特定类型的语料上训练的它对“训练时见过的文本形态”最敏感。比如你用通用中文Embedding模型去向量化数据库表结构转出来的文本效果一定不好因为Embedding模型在训练时很少见过“字段名字段值”这种形态的内容。同样的代码和自然语言混合的内容很多Embedding模型处理起来也会很挣扎。所以这里的建议倾向于第一优先选用针对目标场景做过微调的Embedding模型或者在选型阶段就做一个小规模的评测集来测试第二在向量化之前把数据形态尽量靠近Embedding模型擅长的形态。比如表格记录转成“字段名是X值为Y”的自然语言描述这就比直接拼接col_axx|col_byy更容易得到高质量的向量。4.2 精度细节Embedding模型的“数据类型”偏好还有一个更细的维度容易被忽略就是Embedding模型本身对文本长度的适应性。有的模型对短文本效果好有的模型对长文本更友好。如果你的数据切片平均长度在100个token左右就别用官方推荐max_length是512的模型结果做无脑截断如果你的切片有2000个token但Embedding模型最大只能处理512个token多出来的部分直接被截掉了那段语义丢失了。这种情况要么把切片改短要么换支持长文本的Embedding模型。另外我强烈建议在向量化之前做一次数据抽样验证。就是把向量化之后的数据随机抽出一些样本人工检查向量检索的召回结果是否合理。这一步看起来费时但能帮你提早发现问题等上线之后再调就晚了。4.3 数值类型细节int、float与精度问题既然是从数据类型出发我这里顺手提一个更底层的点。在RAG的数据结构设计里你存入向量库的每个Document都会有若干字段比如原始文本、元数据、创建时间、来源等。这里面的时间、数值、价格等字段尤其要注意类型设置。举个例子你用Chroma或Milvus存商品信息里面的“价格”字段原始值可能是字符串“499元”也可能是浮点数499.0。如果你在检索时想用元数据过滤条件筛选“价格小于300的商品”那这个字段必须是数值类型才能比较。如果初始导入时没有做类型转换后面查询就会一直报类型错误或者查出错误结果。PyPandera类型转换、Pandasastype、SQL里CAST这些都是数据处理里的基本功但在RAG项目里它们同样重要。我自己实践中就踩过“价格字段存成了字符串导致元数据过滤失效”的坑排查了半天最后发现是类型问题。所以数据进向量库之前先做一个字段类型规范表把每个元数据字段的类型都钉死能省很多事。5. 遇到复杂数据类型时图RAG和Agentic RAG怎么选5.1 多路检索给不同数据类型分配独立的处理通道当一个知识库里同时存在文本、表格、JSON和代码时我的第一反应不是把它们全部塞进同一个管道而是设计多路检索架构。多路检索的意思就是每一种数据类型单独建一个处理管道文档走文档解析和结构切片表格数据走行转文本JSON数据走路径提取。每条管道各自有自己的索引检索时并行发起请求然后再合并结果。合并的时候需要一个权重策略。比如法律合同场景条款文本的权重应该高于附件表格的权重商品运营场景表格数据的权重可能高于商品介绍文案的权重。这个方案看起来复杂但工程落地并不难。LangChain里可以用MultiVectorRetrieverLlamaIndex里有典型的PropertyGraphIndex和多路召回设计如果你用国产框架或者完全自研核心思想都是把不同类型的数据分开处理、共享一个统一的重排序层。5.2 Graph RAG关系密集的数据类型要上图结构Graph RAG最近话题度很高热搜词里也有graph rag图搜索。但Graph RAG不是银弹它有明确的使用边界。Graph RAG适合的数据类型有一个共同特征实体密集且关系复杂。比如企业知识库里的组织架构、人员权限、项目依赖关系再比如一个软件系统里的模块、接口、数据流向关系。这些内容如果用纯文本RAG检索结果是一段一段的碎片实体间的关系要靠大模型去猜。但是用图结构把实体和关系提前抽出来Graph RAG就能在检索时沿着关系路径做多跳推理。举个例子用户问“A模块挂了会影响哪些下游服务”。文本RAG只能检索到描述A模块故障的文档片段Graph RAG可以先定位A模块节点顺藤摸瓜找到所有依赖链路上的下游服务节点。这是纯向量检索很难做到的多跳能力。但Graph RAG的成本不低。实体和关系的抽取需要调用LLM做一遍全量信息抽取对大文档库来说费用和时间都很高图数据库的运维也比向量库复杂得多。所以我的建议是如果你的数据实体间的关系非常密集且多跳问答是核心需求才考虑Graph RAG一般性的知识库问答用不上。5.3 Agentic RAG把“该走哪条检索路径”交给智能体Agentic RAG是另一个热门方向它的思路是不再把RAG当成一条固定管道而是交给一个Agent来自主决定该检索普通文档还是该查询数据库还是该调用一个外部API还是该先做一次信息抽取再进入检索。用数据类型来理解Agentic RAG就非常顺了。传统RAG对数据的处理方式是“我不管你是什么类型统一切块、统一向量化”Agentic RAG是“我先判断你是什么类型再决定处理策略”。这其实就是把我在第1节说的“数据盘点”工作前移到了运行时。实际操作时Agentic RAG通常需要一个路由模块。它先解析用户问题判断问题涉及的数据类型然后选择对应的工具或检索管道。举个例子用户问“我们上月销售额环比增长了多少”Agent会路由到结构化查询模块去数据库跑一个聚合查询用户问“销售合同里的违约责任条款有哪些”Agent路由到文档检索管道两个都涉及的情况Agent会先并行查询再合并。这个方案目前工程成熟度不如传统RAG但复杂企业场景下的效果上限更高。如果你正在做Java RAG或Spring AI相关的项目Agentic RAG已经有比较多的启发式实践可以借鉴但别把它想成开箱即用的库。6. 行业实战银行、3GPP协议、代码库6.1 银行RAG数据类型敏感更要强调合规审计银行场景下的RAG数据类型的复杂性更多体现在私域数据上。银行内部的制度文件、信贷审批规则、产品说明书、客户服务指引部分是Word和PDF部分是Excel表单还有一部分存在核心系统里以接口返回的JSON格式存在。银行做RAG有一个很敏感的合规问题数据不能出域。你不能把客户的交易流水、身份证号、手机号直接送到外部的大模型API去生成向量。所以银行场景下的RAG架构通常是私有化部署Embedding模型和LLM如果用了外部模型API则只能处理脱敏后的数据。我参与过的银行RAG项目里最关键的不是模型精度而是权限控制和审计追踪。同一个知识库里不同岗位的人能检索的内容必须不一样。这就需要在数据导入阶段给每一份文档打上权限标签并在检索时将用户的角色信息作为硬过滤条件。这些元数据标签本质上就是数据类型的又一维扩展——不是内容类型而是访问类型。6.2 针对3GPP协议的RAG超长规范化文本怎么切3GPP协议文档是通信行业标准文档特点是篇幅极长动辄几百上千页、术语极其规范、章节编号严格、表格和流程图多、交叉引用密集。直接拿通用RAG方案去处理基本没法用。我处理这类项目时的经验是把协议的结构化信息抽出来单独建模。章节编号是天然的切片边界协议里的表格要单独抽取并保留表头和注释交叉引用要建立双向链接术语表要单独建索引。切分协议文档时我不用固定字符数而是按“章节”和“子章节”切这样每个切片的语义完整性有保障。还有一个实用的技巧在切片的开头加上该切片在完整协议中的“坐标信息”比如“TS 38.300 V16.2.0第8.3.2节属于RRC连接管理部分”。这样当切片被检索到时大模型能清楚知道这段内容的出处和上下文回答的准确性会高很多。6.3 Java/Python开发者的RAG代码数据类型的特有挑战开发者在自己的项目里做RAG常见的数据源是自己的代码库、技术文档、Stack Overflow问答、GitHub Issue等。这里有一个特殊的挑战代码是一种半结构化强逻辑的数据类型它的语义不止存在于文本层面还存在于执行逻辑中。比如你问“这段代码里的并发安全问题在哪里”如果RAG只能检索到代码片段的字面内容而不知道这段代码的调用上下文、共享变量定义、锁的获取顺序它很难给出靠谱的回答。所以代码库RAG的通用做法是不仅索引代码文本还要索引代码的AST抽象语法树结构、函数调用关系、依赖关系。这些信息可以作为元数据附在代码切块上也可以在需要深度分析的时候借助Agent去读取完整的代码上下文再做回答。小技巧方面检索代码时用混合检索很有帮助。函数名、变量名是强词面匹配BM25对这类检索非常有效而“查找有内存泄漏风险的代码”这类语义查询向量检索更适合。两者一结合覆盖度会高很多。7. RAG效果测评不只是看指标更要反推数据类型的问题7.1 核心指标拆解从指标异常定位到数据类型问题RAG测评怎么做热搜词里关注度很高。我这边说说在实操中怎么把指标和数据质量问题关联起来。RAG的核心指标可以分成两块检索质量和生成质量。检索质量的常见指标有召回率RecallK、命中率Hit Rate、MRRMean Reciprocal Rank。生成质量的常见指标有忠实度Faithfulness、答案相关度Answer Relevance、上下文相关度Context Relevance。如果忠实度低也就是说大模型生成的答案和检索到的上下文不一致甚至相悖优先怀疑数据处理环节——是不是切片切碎了导致上下文不完整是不是表格转文本丢失了对齐关系。如果召回率低优先怀疑检索策略——是不是用了纯稠密检索导致术语匹配失败是不是Embedding模型对专业领域适配性不够。如果相关度低优先怀疑索引设计——是不是不同数据类型的向量混在了一个集合里导致结果被某些类型的噪声干扰。7.2 测评集怎么建才有效测评集的建设要围数据类型来设计这一点很少被人重视。我建议按数据类型分类建立测评用例纯文本类问题30%表格类问题20%JSON或结构化数据类问题20%跨类型综合问题20%边界问题数据不存在、数据不完整10%。每个用例要写清楚用户问题、期望答案或关键信息点、命中的数据文件或记录ID、答案来源类型。有了这个测评集你才能精准定位到“到底是哪个类型的数据在拖垮整体效果”。我见过不少团队拿一二十道通用问题做测评测出来效果还行一上真实数据就崩。这往往就是测评集没覆盖到真实数据里的复杂数据类型。7.3 一个实际案例把RAG从63%拉到81%我在做一个企业内部制度问答RAG项目时一开始用通用处理流程所有文档统一转Markdown、统一按固定长度切片测评召回率只有63%。后来我按数据类型拆开看发现拖后腿的是两类数据一个是Excel里的奖惩细则表一个是PDF扫描版的红头文件。Excel表被当成文本切碎后奖惩对应关系全乱了扫描版PDF没做OCR和版面重建检索到的内容基本是乱码。针对性地做了两件事Excel表改成按行转文本并保留表头信息扫描件先OCR再加版面分析重建结构。重新跑测评召回率从63%涨到了81%。整个过程中我没有换Embedding模型没有换向量库只是把数据类型的适配做对了。这个案例给我的启发是RAG项目的优先级是先治数据再调模型最后才轮到换框架。8. 常见问题与排查速查表结合我自己的实操经验和踩过的坑整理一个RAG项目常见问题速查表覆盖从数据类型到链路各环节的排障方向问题现象可能原因排查与解决方向检索结果和问题完全无关数据类型误判表格/JSON被当纯文本处理核对数据解析策略检查切片内容确认是否保留了结构信息召回了相关内容但答案仍然答非所问切片太小导致上下文不完整或关键信息被截断检查切片粒度按文档结构调整切片确保每个切片是语义完整的单元专业术语、型号、协议名称检索不到纯稠密检索缺乏精确匹配能力切换为混合检索保证BM25这类稀疏检索参与召回同一类数据的检索效果时好时坏不同数据类型的向量混在同一个集合中互相干扰按数据类型分开建索引在检索层分别召回后再做统一排序PDF文档检索效果差文件为扫描版或版面分析没做OCR后重建结构识别标题层级和表格区域后再切片Excel表格数据检索结果错乱表头和记录被拆开行列对应关系丢失按行转自然语言描述或整体转Markdown表格再单独索引表头JSON数据检索结果碎片化层级结构被扁平化后切断按路径字段切分保留父子节点关系元数据过滤不生效或字段报错字段类型未正确设置数值被存成了字符串在数据导入阶段做字段类型规范价格/时间等字段显式转换为数值类型偶尔检索到内容但不稳定文档中存在大量格式噪声页眉页脚、水印等在解析阶段加强清洗过滤剔除噪声后再向量化大模型生成时引用来源不准确检索结果缺少来源元数据文档切片时带上来源文件、章节号、行号等元数据检索结果统一回传除了表格里这些还有几条实操心得分享一下。第一永远保留原始文档和切片之间的映射关系。中间不论做了多少次清洗、转换最后检索结果里必须能追溯到原始文档和原始位置。这不仅是排障的关键也是很多行业审计合规的硬性要求。第二数据解析结果一定要抽样人工检查。解析器跑完一批文档不要直接进向量库先随机抽10到20份人工看一遍切片结果。这一步看起来慢但能避免因为一个通用的解析Bug导致整批数据效果翻车。第三RAG项目从第一天开始就要搭测评集。没有测评集你后面所有的优化都像是闭着眼开车。评测集的构建方式在上文说了按数据类型分类设计起步量不需要太大50到100条就够用关键是覆盖面要全。从数据类型出发理解RAG是我做了多个项目之后最想跟大家分享的一个角度。很多人把RAG当成一个模型能力问题实际上它更多是一个数据工程问题。数据是什么类型决定了你要怎么解析它、切片它、索引它、检索它。把这条主线理清楚很多所谓的“RAG效果不好”就不再是玄学而是可以定位、可以修复、可以验证的工程问题。最后再说一个我个人的做法吧。每次接到新的RAG项目我都会先做一个“数据体检”把客户给的所有样例数据人工翻一部分记录每份数据的类型、格式、结构、质量缺陷输出一份数据盘点报告。这份报告做完我基本能对项目的技术选型和工作量心中有数。你也可以试试这个习惯大概率会帮你在RAG项目里少走很多弯路。