做RAG项目做得越多我越觉得一个容易被忽略但是决定成败的问题是你的数据到底长什么样。很多团队上来就选框架、配向量库、调Embedding模型折腾半天发现效果很差回头一看问题出在数据形态没盘清楚。RAG的全称是Retrieval-Augmented Generation检索增强生成听到“检索”两个字人很容易默认想到向量检索但实际上不同类型的业务数据对应的检索方式、存储结构、解析策略甚至评估口径完全不一样。所以我想从“数据类型”这个最底层的视角把RAG从头到尾重新拆一遍。这篇文章适合正在做RAG落地、被知识库效果困扰的工程师也适合刚入门RAG想建立整体认知的人。我会从数据形态出发讲清楚为什么数据类型会决定RAG方案架构再结合检索、解析、切分、评测这些实操环节补上我在项目里踩过的坑和总结出来的经验。内容尽量不绕弯子能直接落到代码和配置层面的我都会写清楚。1. RAG 的真正起点先认清你的数据长什么样1.1 数据类型决定 RAG 的架构选型我在很多分享里反复强调过一个观点RAG难点从来不在大模型的调用上而在数据侧。数据侧的第一步不是清洗、不是切分而是先做类型识别。很多团队拿到的数据是几百个PDF和Word文档以为这就是全部结果做完了才发现真正高频被问到的数据在Excel里或者在内部系统的数据库里。数据形态不同RAG的方案几乎是完全不同的技术栈。从数据结构维度我习惯把RAG的数据分成四类非结构化文本数据比如文档、PDF、网页正文结构化表格数据比如Excel、CSV、关系型数据库里的表图结构数据强调实体与关系的知识图谱以及代码类数据比如源码、API文档、配置文件。这四类数据检索逻辑完全不一样。非结构化文本靠语义召回靠切块和Embedding表格数据靠自然语言转SQL或者转查询表达式图数据靠图遍历靠Cypher、SPARQL这类图查询语言代码数据则要兼顾语法树结构和符号之间的引用关系。所以当我听到有人说“我用RAG做了一个知识库”的时候我第一反应永远是反问一句你知识库里的数据主要是哪一种类型这个问题的答案决定了你后面80%的技术决策。这也是为什么我认为“从数据类型出发理解RAG”不是一句空话而是整个项目规划的原点。1.2 非结构化文本数据TextRAG 的典型通路最常见的RAG形态是非结构化文本RAG通常被称为TextRAG或VectorRAG。这类RAG的处理对象是自然语言文本。整个链路是文档解析、段落切分、向量化、存储、召回、重排、拼接上下文、交给大模型生成答案。这条链路里最容易出问题的点是切分很多人直接按固定长度暴力切分比如每500个token切一块结果把一个完整的意思拦腰截断召回时上下文碎片化答案质量断崖式下降。更好的做法是结构感知切分Markdown按标题切PDF按章节标题和段落边界切HTML按DOM结构切。市面上很多RAG框架比如LlamaIndex和LangChain都内置了这类NodeParser策略。但框架给的只是通用方案真实项目里必须针对自己的文档结构做定制。我在一个法律合同项目中把合同按“条款编号条款标题”做递归切分每一块尽量保持法律语义的完整性召回准确率比纯按字数切要高很多。1.3 结构化表格与数据库TableRAG 与 NL2SQL 的战场非结构化文本只是RAG的第一层。真实业务里大量高价值信息躺在表格和数据库里。比如财务数据、销售明细、用户表、订单表。表格数据跑了普通的文本切分后果很惨表头被切到一个chunk里数值被切到另一个chunk里检索时拿到的是断裂的单元格大模型根本拼不出完整语义。针对表格数据行业里有几条主流路线。一类是TableRAG思路把表格先做序列化描述也就是把表头和示例行转成文本描述再做向量化召回最后把命中的表格片段交给模型生成回答。另一类是NL2SQL路线也是我在这类项目里更推荐的做法让大模型把用户问题转成SQL或查询表达式直接在数据库里执行查询拿到精确结果后再让大模型组织自然语言回答。后者避免了把表拆碎的问题因为它压根不切表而是切“查询逻辑”。这两种方案怎么选如果表格本身不大、行数少、适合直接塞进上下文用TableRAG序列化描述就够了如果表格在真正的数据库里数据量大、实时性要求高那我建议直接上NL2SQL。这个时候你真正需要的是一个好的Schema设计和一个严格的SQL校验机制防止生成非法查询。1.4 图数据Graph RAG 与 Ontology RAG 的进阶路线当数据的价值更多体现在实体关系和多跳推理上时比如“A公司和B公司之间通过C项目产生了什么关联”纯向量检索的表现会非常吃力。因为向量检索擅长做相似匹配不擅长做关系推理。这种情况下Graph RAG开始发挥作用。Graph RAG和TextRAG最大的区别在于它先把非结构化文本中的实体和关系抽取出来构建成知识图谱存入图数据库比如Neo4j、NebulaGraph然后用图查询来回答问题。搜索热词里的ontology rag本质上是Graph RAG的进阶版先定义好本体层也就是实体类型、属性、关系类型再按照本体去抽取和入库保证知识图谱的schema一致性。我自己做过一个企业供应链项目数据散落在几百份供应商合同和审计报告里。业务方的问题经常跨多个实体比如“某供应商的所有下游客户里有多少家同时是我们的竞争对手”。这种问题用普通向量检索做大模型只能凭上下文猜但建了供应商、合同、客户、竞争对手四类实体和五类关系的图谱之后一条Cypher查询就能精确回答。这类需求在实际业务里非常普遍也是Graph RAG在目前RAG落地中最受关注的原因之一。2. 从数据类型倒推检索与存储选型2.1 Dense Vector Search 与密集向量检索的本质RAG的主流召回方式是dense vector search也就是密集向量检索。所谓密集向量是Embedding模型把文本转换成几百甚至上千维的浮点向量语义相近的文本在向量空间里距离更近。Vector Search做的是近似最近邻搜索常用HNSW算法用图索引加速查询。提到dense vector核心关键词是“语义相似度”。好处是能解决同义改写的问题比如用户问“怎么退货款”文档里写的是“退款流程”两者字面完全不同但语义接近向量检索能匹配到。代价是Embedding模型分不清精确数值和逻辑条件。你问“去年销售额超过100万的客户有哪些”向量检索根本没法做大于小于比较这种查询必须走结构化检索。这是我在项目里反复强调的边界dense vector search适合“找相关内容”不适合“算精确结果”。一旦问题里出现数值比较、条件过滤、聚合统计就要考虑混合检索或NL2SQL方案了。很多RAG项目翻车就是拿向量检索干结构化查询的活。2.2 稀疏检索、BM25 与混合检索的配合逻辑虽然向量检索是RAG的代名词但我实际项目中几乎不会只跑向量检索。关键词精确匹配在很多场景里依然不可替代尤其是人名、产品型号、合同编号、法律条文号这类专有名词。Embedding模型在这类精确标识符上经常表现不稳定稍微改写一下就可能召不回。所以我在生产环境里通常用混合检索BM25稀疏检索加向量密集检索并行再用RRFReciprocal Rank Fusion或Rerank模型做结果融合。BM25是传统的词频统计检索算法对精确词匹配非常友好向量检索负责语义泛化。两者互补之后召回率会比单一检索高出一大截。热词里的embedding rerank就是这条链路的关键环节。Embedding负责初筛Rerank模型负责精排。初筛阶段召回100条候选Rerank阶段根据用户query与候选文档的相关性打分拿出前5条。很多队伍到这一步就收工了但我想多说一句Rerank模型一定要和Embedding模型分家不要用同一个模型既做召回又做排序。因为召回模型追求宽泛召回排序模型追求精排区分度两者目标不同混用会两头不讨好。2.3 图存储与向量检索的协同在Graph RAG体系里存储选型更复杂。图数据库负责存实体和关系向量索引负责存实体的语义描述两者之间需要协同。比较常见的做法是图数据库里每个节点绑定一个embedding属性用图数据库的向量索引插件做近邻搜索或者把向量放到外部向量库然后通过实体ID关联。比如Neo4j从5.x版本开始内置了向量索引功能可以把节点属性的embedding直接存入然后跑kNN查询。实际项目中我更喜欢把向量索引和图形遍历分开各司其职。第一步用向量召回实体种子节点第二步沿着图结构做多跳扩展第三步把扩展结果作为上下文。这种“先向量召回种子再图遍历扩展”的混合方案比纯粹依赖向量检索或纯粹依赖图查询都更稳健。在这个架构里还有一个索引一致性问题。业务系统的数据在变图谱在变向量索引也要跟着变。很多项目初期效果很好跑了一个月后越来越差就是因为增量更新没做好。所以从设计第一天就必须把“哪个字段变化时需要更新哪个索引”这个映射关系定清楚。2.4 不同类型数据映射到存储组件的实践思路不同数据类型对应的存储组件我列一个对照表方便做技术选型的时候直接参考。数据类型检索方式典型存储适用场景长文本/文档向量检索BM25混合Milvus、Qdrant、Elasticsearch合同、政策、FAQ知识库短文本/问答对向量检索上述任意向量库客服FAQ、操作手册表格/数据库NL2SQL/查询表达式MySQL、PostgreSQL、DuckDB经营分析、财务数据查询关系密集型文本图遍历向量召回Neo4j、NebulaGraph供应链风控、舆情分析代码仓库AST解析符号索引自建索引向量库代码问答、API检索Redis这类缓存型数据库在RAG里也在承担新角色比如热词里的redis数据类型。很多团队用Redis存用户的会话上下文、缓存检索结果、管理rerank后的临时结果集。Redis的String、Hash、JSON等数据类型与RAG的缓存策略结合得比较紧密但要注意它不是主力存储主检索还是得交给专业向量库。3. 核心细节类型转换、解析与切分的那些坑3.1 文档解析中的“类型劫持”很多人在做RAG项目时会忽略一个前置问题从文件里读出来的数据真的是你以为的那个类型吗以PDF为例一个看起来是表格的PDF可能实际上是由绝对坐标拼出来的文本框并没有真正的表格结构。用普通的文本抽取工具会把表格顺序完全打乱。热词里的“pandas 数据类型转换”和“python变量和数据类型”恰恰点出了这个问题的本质数据从一种介质转换到另一种介质时类型信息会发生丢失或畸变必须做显式转换和校验。我的处理惯例如下PDF到文本优先用PyMuPDF或paddleocr表格抽取优先用Camelot或pdfplumber抽取完后用pandas检查列数是否一致、缺失值比例是否异常再做字段类型推断。数据库从MySQL同步到数据湖时时间字段经常从datetime类型变成字符串金额字段可能从decimal变成float这些类型变化如果不提前识别到RAG检索阶段就会出各种脏数据。还有乱码问题。很多扫描版PDF没有文本层直接抽出来的文本全是乱码这种就必须走OCROCR完再做一次校对否则会带着大量识别错误进入向量库严重影响检索质量。这个过程费时费力但它是RAG数据质量的生命线。3.2 代码数据的类型意识与代码 RAG代码类数据是RAG里比较特殊的一类。代码的语义高度结构化依赖包导入、函数定义、变量作用域、类型声明。普通文档的切分策略用在代码上基本失效。把一份完整的Java类文件按固定长度切成几块结果就是每个chunk里都是不完整的语法片段检索出来根本没法直接用。针对代码数据我的建议是尽量用语法解析器生成AST抽象语法树以函数、类、方法为最小单元切分保留文件路径、类名、函数签名等元信息。拿Java举例用tree-sitter或JavaParser把源文件解析成语法树按方法块与类块组织索引。这样用户问“某个REST接口的入参校验逻辑在哪里”检索系统能准确定位到对应方法而不是返回一大段无关代码。热词里出现“codesys里_uxint是什么数据类型”“sv中的数据类型转换“java基本数据类型”这类问题说明开发者群体对数据类型本身就有强烈的问答需求。代码RAG的落地方向之一就是把这些数据类型、函数库、API文档做成一个可检索的开发者知识库让大模型直接回答类型定义、转换规则这类开发问题。这种场景下数据的“类型意识”从字面意义上就变得非常重要。3.3 数据类型规范化打通检索与推理的边界做完解析下一步就是数据规范化。数据规范化的核心是统一字段类型和命名规则。例如客户ID在合同文档里是字符串在数据库里是bigint在Excel里可能被读成了float因为有缺失值pandas会把整列推断为float。如果不做统一转换后续检索和查询会遇到大量类型不匹配的报错或者更隐蔽的查询结果出现偏差。我在项目里通常建一个数据字典统一记录每个字段的物理类型、逻辑类型、取值范围和示例值。这个数据字典本身也是知识库的一部分喂给大模型可以让NL2SQL生成的查询更稳定。比如字段名叫created_at我就不会让模型把它当成普通字符串去过滤。实际上NL2SQL方案中很多生成SQL的报错都是字段名或类型理解错误引起的提前给模型一份清晰的Schema和数据字典能大幅减少这类问题。此外热词里的agentic rag提示我们新一代RAG不再是单次检索后直接回答而是让大模型像Agent一样根据问题自主规划检索步骤必要时调用多个工具。这个过程中数据类型的理解能力更加关键因为Agent一旦误解了某个字段的类型或含义后续的规划和工具调用全都是错的。所以在Agentic RAG项目中我更强调先把数据类型和字段语义定义清楚再让Agent去编排。4. 实操过程一个混合数据 RAG 项目的完整链路4.1 项目需求与数据摸底这里我拿一个做过的真实项目作为案例来讲。项目背景是某企业需要搭建一个内部采购制度问答系统数据来源包括几百份采购管理制度文档、一套ERP系统的物料主数据表、以及一份供应商风险等级的评分表。业务方希望员工用自然语言提问系统能回答制度流程问题也能查询物料的库存与供应商风险情况典型的需求包括“某某物料的当前库存是多少”“采购金额超过50万的流程需要哪些审批节点”。项目启动后我做的第一件事就是数据摸底。我把所有数据源列成了清单逐个标注数据格式、规模、更新频率、有没有结构化字段、文本里有没有图片或表格然后按照前面说的四个数据类型做分类。结果发现制度文档属于非结构化文本物料主数据和评分表属于结构化表格。不同数据对应着完全不同的技术路线。4.2 数据预处理与类型规范化摸底之后是繁琐但决定成败的预处理阶段。制度文档的预处理重点是清洗与切分。我用PyMuPDF抽取文本过滤页眉页脚和重复的目录信息再按章节结构切分每段保留来源和章节号。针对文档中的表格单独抽取出来转成文本描述附在对应章节后面。物料主数据的处理就不一样了。我先用pandas读取数据库表检查字段类型。常见的问题是物料编码被Excel识别成科学计数法导致精度丢失部分日期字段是字符串格式需要统一转换成datetime类型。我把物料编码统一降级成字符串并加前导零补齐金额字段统一转成decimal避免浮点数比较误差。这一步做完之后我对每一张表都生成了字段描述表包括字段名、类型、单位、取值含义这些后续都要交给大模型使用。4.3 索引构建与检索链路配置结构化数据和非结构化文本分开建立索引。制度文档的章节块我用embedding模型这里我们用的是bge-large-zh转成向量存入Milvus同时把文本原文同步到Elasticsearch做BM25索引双路召回。物料数据和评分表没有做向量化而是保留在MySQL里通过NL2SQL方式查询。检索链路配置为用户提问后先经过一个查询分类器判断是文档查询还是数据查询。文档查询走混合检索向量与BM25同时召回再用RRF融合送入Rerank模型精排最后把Top5拼进Prompt。数据查询则走NL2SQL大模型根据表结构生成SQL先做语法校验再执行查询把结果拼接成自然语言回答返回给用户。对于混合型问题比如“某某物料的库存和采购制度是什么”系统会同时触发两条链路把结果合并后再回答。4.4 回答合成与引用约束最后一步是回答合成。这里有个我踩过很多次的坑大模型很容易一本正经地编造引用。解决方案是做引用约束要求模型在输出答案时必须从上下文中摘取原始片段作为依据如果没有找到对应内容必须直接说“未找到相关信息”而不能自行发挥。我会在Prompt里明确给出格式约定要求回答中每个关键结论后跟一个方括号引用标记标记对应检索结果的编号。系统在最终展示时根据编号把原文链接附在后面。这一步极大提升了业务方对系统的信任度。对数据查询类回答我还会在Prompt后面附上一句提醒如果数据查询结果为空模型只能回答“查询无结果”不允许猜测。这类约束写得越细生产表现越稳。5. 从数据类型视角看 RAG 失败模式与评估5.1 RAG 测评怎么做别只看最终答案对不对热词里有“rag测评怎么做”“rag评估方案”说明大家都在重视评估但很多团队的评估方法太简陋。单纯让大模型对最终答案打一个分完全不够。一套完整的RAG评估至少应该分成检索评估和生成评估两层。检索评估看召回质量常用指标是RecallK、MRR、命中率。我习惯的做法是维护一个标准问题集每个问题标注正确的文档片段ID然后测试在不同K值下系统能召回多少个正确片段。生成评估看端到端回答质量用RAGAS这类框架做忠实度、相关性和答案正确性评分。此外我还会人工抽检bad case尤其是推理型问题和多跳问题因为这类问题最容易暴露出数据链路的缺陷。在评估数据集构建上有一个容易被忽视的点必须按数据类型分层设计评测问题。文本类问题测语义召回表格类问题测数值查询准确性图类问题测多跳推理能力。如果混合在一起评估某个环节的缺陷会被其他环节的成绩掩盖。5.2 类型错位导致的典型 bad case我在项目里整理过一批高频bad case基本都是数据类型错位引起的。第一种是文本和数值混用。用户问“上个月的采购总金额是多少”系统误把这个问题交给了文档检索结果回答了一段关于采购流程的文字根本没有具体金额。这就是典型的query类型识别失败。第二种是数值精度丢失。物料编码从Excel读入时被转成了科学计数法导致下游匹配全部失效。或者是金额字段被转成float以后出现0.1加0.2不等于0.3的问题。这种问题在开发环境很难发现因为数据量小一旦上生产匹配错误率和查询偏差就会集中爆发。第三种是关系型问题被误判为相似性问题。用户问“A项目影响了哪些供应商”如果系统只在文档片段里做向量检索得到的一定是语义相似的内容而不是真正的关联实体集合。正确答案应该通过图查询或结构化关联查询获得。这类问题的判定需要跟业务方充分对齐我会在项目一开始就建立类型判定清单把常见的“关系型问题”模板识别出来。5.3 常见问题速查与避坑记录结合多个项目的经验我把RAG中与数据类型相关的高频问题整理成一张速查表问题现象根因排查方向检索结果语义对但数值错数值被切分或类型转换异常检查chunk切分边界检查Excel/数据库字段类型专有名词召回不到向量检索对精确词不敏感改用混合检索加BM25表格内容乱序PDF表格解析失败换Camelot/pdfplumber做表格抽取保留行列结构查询SQL频繁报错Schema信息和数据类型未提供给模型提供字段字典和示例SQL多跳推理答案零散实体关系未建图评估是否需要Graph RAG构建实体关系抽取管线Rerank后效果反而变差检索引擎分到了不同文本粒度统一检索结果粒度确保Rerank输入格式一致这张表我建议参数团队在项目上线前逐条对照检查。很多时候RAG效果不好不是大模型不够聪明而是数据侧的隐性问题没暴露出来。从数据类型出发做一次系统体检能少走很多弯路。我个人在实际操作中还有一个比较深的体会数据类型的梳理不是一次性的工作而是需要持续维护的资产。随着业务扩展新的数据源不断接入类型体系必须同步演进。那些告诉我RAG项目上线后基本不用管了的团队我基本都会劝一句检索层的指标和bad case还是要有持续的监控机制数据形态一变整个链路的稳定性就得重新校准。这是我做了这么多项目之后最想留下的一个经验。