背景
在企业大数据中台建设过程中，数仓往往承担了数据资产中心的角色，上承业务库，下接各个部门的分析师，数仓的建设就是数据清洗、中转和分发的一系列操作。我喜欢把数仓的工作比做图书馆管理员，数据资产就像一本书，我们做的数仓建模工作，就好比是系统化的设计、摆放和清理书架，把一本本书放到他应该属于的地方。如何让读者（数据使用方）快速、精确地找到自己想要的书，这就是数仓建设最重要的工作。
货拉拉数仓经过几年的建设目前已经日益成熟和庞大，随着业务发展，下游的分析师、数据科学家、工程师也越来越多，数仓同事每天都会花不少时间在帮助别人找数用数。在日益壮大的"图书馆"和日益增多的"读者"情况下，如何让用户自助解决各类数据资产问题成了当下最重要的提效点。
大数据数据资产智能答疑工具应运而生。 
行业思路
Fine-tuning与Embeddings
对于知识库答疑这样的场景，如果我们输入过多非必要的知识文本也会造成回答的不准确。为了解决这个问题，目前常有两种方法一个是Fine-tuning和Embedding。
| 对比维度 | Fine-tuning | Embeddings |
|---|---|---|
| 核心原理 | 基于预训练大模型，使用知识库数据调整模型部分or全部参数，让模型 "记住" 并直接生成知识相关内容 | 将知识库文本（文档、段落、问答对）转化为低维向量（Embedding Vector），存储于向量数据库，通过 "向量相似度检索" 匹配用户问题 |
| 优点 | • 生成能力强：可直接输出结构化回答，无需额外检索逻辑； • 上下文融合好：能结合用户问题的上下文灵活生成，适配复杂对话场景； • 知识内化深：知识融入模型参数，对高频问题的响应更流畅自然 | • 成本极低：无需调整大模型参数，仅需生成向量； • 实时性强：新增or修改知识时，仅需重新生成对应向量，无需重新微调模型； • 稳定性高：不易出现 "幻觉"，答案严格源于检索到的知识库内容； • 扩展性好：支持海量知识库 |
| 缺点 | • 成本高昂：需大量计算资源（GPU/TPU）； • 更新困难：新增知识需重新微调，周期长，无法实时更新； • 风险高：小样本微调易导致 "灾难性遗忘"（忘记预训练知识），且可能产生 "幻觉"； • 数据要求高：需高质量、大规模标注数据（如结构化问答对），否则效果差 | • 生成能力弱：仅输出检索到的原始知识片段，需依赖 "检索 + LLM 生成"（如 RAG）组合才能生成流畅回答； • 上下文依赖低：向量匹配依赖问题与知识的表层语义相似性，对 "同义不同表述" 的匹配精度可能下降； • 额外架构成本：需搭建向量数据库、检索逻辑（如 BM25 + 向量混合检索），增加系统复杂度； • 长文本处理差：单条 Embedding 对长文档（如 > 5000 字）的语义捕捉不完整，需拆分段落导致检索颗粒度分散 |
| 知识更新效率 | 低（需重新微调模型，周期长，不支持增量更新） | 高（新增知识直接生成向量插入数据库，秒级 / 分钟级更新） |
举个例子区分这两种方法：假设你招了一名实习生来帮你干活，Fine-tuning就好比是他刚入职时对他进行专门的入职培训，而Embedding则是提供一本指南宝典，当他遇到问题的时候翻宝典寻找最相似解法。
目前主流是基于work flow的compound system应用思路，由于其白盒的构建方式更可解释更可控，大部分的企业在构建知识库答疑机器人时还是会选择RAG方案。
HyDE
常见的知识库QA对有一个问题就是关键词的狭隘性，用户的提问通常都是多变的，如果用户换了另一种方式或者另一个关键词提问可能就查询不到对应知识。目前其中一种解决方案是HyDE，其思路是通过假设性文档拓展提问上下文。
GraphRAG
GraphRAG与传统RAG的区别在于，引入知识图谱，使用图结构来表示信息。节点代表实体（如表、字段、概念等），边表示这些实体之间的关系，通过捕捉实体间的复杂关系，能够精确丰富上下文，提高信息的丰富度和层次。其次通过Multi-hop Questions可以提高Agent推理能力，在知识向量数据库数据量变多时，可以提高查询速度，降低成本。 
解决方案
沟通成本的来源
事实上数仓大量的数据答疑问题都来自数据资产建设不完善的地方。事实上很多问题并非短期能够解决，而且随着新问题的不断冒出缺陷漏洞可能会越来越大，那答疑工作只会日益增多。 
问题的来源：
- 争议字段 业务研发和数仓开发过程中，可能会记录一些具有争议的字段，这些字段缺少有效的comment解释，使用方法不明确，业务逻辑不清晰，导致下游无法直接有效使用。 最常见的问题就是：XX字段枚举值的含义是什么？当它等于XXX时候业务上显示是怎么样的？
- 模糊口径 在指标或标签开发过程中，通常会出现一些复杂口径字段，这类口径需要超长的文本、图片、流程图甚至表格数据来解释，数仓不会将其记录在元数据系统里。因此需要单独一套文档来解释这类模糊口径。 最常见的问题就是：XX标签/指标计算的数据范围是什么？包不包含XX条件或有没有考虑XX场景？
- 数据质量 通常数据质量问题都需要比较长时间的定位，这可能是线上研发BUG导致，也可能是数仓开发错误导致，也可能是使用方不了解数据误会。这类问题通常会在某次发版/发布后出现，通常数据修复后就能解决。
- 前后端数据不一致：为什么这个数据前端显示XX，后端却显示YY？
- 表表间数据不一致：为什么同个订单ID这个表字段和那个表字段不一样？这个表有那个表没有？
问题的分类：
把数仓常见的问题进行分类，我们可以分成以下四类。 
日常答疑流程
分析目前数仓的答疑流程有以下特点及缺陷：
| 特点 | 缺陷 | |
|---|---|---|
| 职责划分 | • 数仓开发工作按主题域划分，答疑工作同样按主题域划分。 | • 问题路由提高了沟通成本 • 团队成员间彼此答疑记录隔绝，没有办法通过分析下游提问频率发现提问价值 • 彼此知识库隔绝，小问题无法互相解决 |
| 找数问题 | • 部分主题域有自己的数据字典文档，可以通过平台元数据+查阅文档可解决找数问题 | • 数据字典缺少系统性维护 • 部分资料陈旧，落后于业务变化 |
| 用数问题 | • 部分主题域有自己的知识库文档，可以通过查阅文档解决用数问题 | • 知识库文档缺少系统性维护 • 文本知识库可能不规范，RAG工程不准确 |
| 其他问题 | • 通过平台元数据血缘功能，可以找到对应研发，解决数仓无法答疑的数据问题 |
架构思路
- 问题关键词提取和主题识别
通过rag或prompt工程，完善大模型数仓建设主题域方面知识。在work flow设计主题域划分和关键词提取环节，通过提取结果路由至相关知识库和元数据。注意并非单一路由结果，部分问题可能涉及多个主题域。下图是个大致思路，实际上会有更多的上下文处理和流程优化节点。
- 数据字典维护转移至通过元数据平台维护
统一的元数据平台满足日常使用，避免交接过程中重要文档丢失，同时长期积累的业务文档具备更深的价值沉淀，随着数据字典完善以及日常数据变更逐渐变小，对大模型的影响更可控。 - 完善知识库文档
- 通过QA对的记录方式，保障文档chunking质量，关键词能被优先提取，确保核心知识路由。
- 文档记录在团队线上文档，团队成员可以彼此加工完善。
- 可以针对主题域划分知识库，针对一些小业务、特殊业务也可以做专门知识库。
- 提问和答疑记录
通过分析用户提问可以挖掘数据资产未来开发方向，如业务侧重点、大型数据质量问题、新业务概念等。记录的答疑结果可以接入大模型测评平台，测试智能答疑效果。 - 智能答疑运营
通过用户提问->数据回收->优化模型 这个运营流程，不断正反馈和优化智能答疑效果，将整个项目往更好的方向推动。
未来方向
- 数据血缘打通至业务研发
事实上，在我们日常的答疑工作中有一部分是数仓无法解决的，这一类问题我们通常需要接通到相关产品或者业务研发。从节省沟通成本的角度来看，数仓通过数据血缘将这一类问题直接引入到后端研发，跳过数仓答疑的环节即可。但是这其实是一种将答疑成本转嫁给其他人的行为，如果数仓不将这部分知识沉淀到数仓，那在未来同样会有重复的答疑工作。 - 数据质量问题难答疑
在下游提问的问题中，数据质量问题往往是最棘手的。这一类问题的定位通常需要进行大量的SQL探查、口径沟通和拉齐工作。如果从最理想化的项目设计角度来看，未来是可以通过AISQL相结合的方式，来解决这一类问题的。但是这部分的定位SQL是不明确的，目前稳定的NLP2SQL方案其实还是停留在固定模板的方式，想要通过智能答疑完全解决这类问题目前还是比较难。 同时这类问题的终点其实不在定位，而是在修复。这需要比较重的开发经验、沟通能力甚至是资源打通的能力，目前大模型Agent还不具备这样的能力。 - 更多的RAG架构
- 更多场景补充
如果把数仓的问题按数仓分层进行拆分，其实大致可以拆分成三层： 贴源层问血缘->公共层问用法->应用层问数据 过去的chatbi思路基本是集中在解决应用层问数据这块，在补齐了 问血缘、问用法、问数据更多细节场景之后，大数据Agent才能实现一条龙解决业务问题。 - 开源框架
- RAG-Anything: All-in-One RAG Framework 这个框架支持端到端多模态流水线、MinerU和Docling的文档解析工具、混合智能检索等特性。另外其Knowledge Graph的构建，通过实体提取和跨模态关联，能够真正打通不同文本、图像、表格之间的信息孤岛。
- MindsDB: An AI Data Solution 这个框架支持众多数据源集成，包括各种类型文件、数据库、向量存储、应用程序等，通过创建支持库可以将这些结构化和非结构化数据源的数据整合到统一的查询界面，最后通过大模型自然语言询问和返回，实现在所有数据上进行无缝查询和模型构建。
总结
RAG已死吗？
LLM支持的token数量，从GPT 4时代的8k，到如今Grok 4、Claude 4.5 Sonnet和Gemini 2.5 Pro都逐渐支持1M以上，这个量级的跃迁是明显的。要知道大部分长篇小说、学术著作字数，都在20万到200万之间，而如今的token支持字数，正在逐步超过这个范畴。过去的RAG技术，它其实有点像正则的升级版，用向量的思路帮助我们在茫茫学海里找到最相近的知识，精选出对应的信息，输入给LLM。但长下文更像是给LLM装上了记忆宫殿------我把知识都给你了，你在你的记忆宫殿里能找到吗？找得准吗？目前谁也不知道。
但RAG会死吗？
只要存在成本的控制，只要LLM还存在 幻觉、偏见的情况，像RAG这种定点爆破的方式，确实是最高效的。
参考
GitHub - DEEP-PolyU/Awesome-GraphRAG: Awesome-GraphRAG:
GitHub - HKUDS/RAG-Anything: "RAG-Anything: All-in-One RAG Framework"
MindsDB, an AI Data Solution - MindsDB
笔者介绍：杨舒林｜资深数据仓库工程师，现就职于货拉拉，主导过货拉拉数仓交易主题域大型业务切流、保障链路治理等工作，目前负责数据资产核心主题域公共层建设。