数据开发在AI时代的转变，数仓、RAG（检索增强）与 Agent如何支持企业级AI
传统数仓、数据库和分析系统，为业务提供了稳定的数据支持和决策依据。但当数据开始面对 LLM 时，就产生了一个全新的挑战：如何将企业数据转化为模型可感知、可检索、可执行的“上下文”。
在企业 AI 系统中，这一过程通常经历三个关键环节：
1. 数仓与数据库：提供干净、统一、结构化的业务数据。
2. 搜索与 RAG：让模型能够快速、稳定地访问相关信息。
3. 工作流与 Agent：将数据能力编排成可执行的任务，实现复杂业务的闭环。
图中展示了这一链路的概览。
通过这条链路，可以发现数据不再只是“给人看的”，而是成为 AI 执行的核心驱动力。
一、从数仓到 LLM：数据“服务对象”的变化
在之前的文章中（微信公众号：小友数研），我们讨论了企业级AI落地的一个核心事实：模型是否能“干活”，并不取决于模型有多聪明，而取决于数据是否真正进入了模型的执行链路。
在传统企业架构中，数据的服务对象是人：
1. 数仓（ODS / DWD / DWS）服务于分析与决策。
2. SQL查询服务于报表、指标于业务复盘。
但当 LLM 进入系统之后，数据第一次开始面对一个全新的使用者：模型本身。
同时也会面临以下问题：
1. 模型不理解表结构。
2. 模型需要的是“上下文”，而不是“结果集”。
这意味着发生了一个关键变化：数据仍然来自数仓，但不再以数仓的形态被使用。
在上一篇中，我们已经完成了一个前提结论：企业数据要进入 LLM，必须先完成一次语义化转译。而从这一刻开始，真正困难的问题才出来：当数据已经“像上下文”之后，模型究竟如何稳定、可控地找到并使用这些数据？
二、搜索工程成为 AI 的“感知层”：BM25、分词器与模型召回
在很多 RAG 项目中，搜索系统常常被当作一个“附属组件”，甚至被向量检索完全替代。但在真实的企业场景中，这种做法往往很快会遇到瓶颈。
原因很简单：模型只能感知被检索出来的数据，如果召回不稳定或不准确，所有后续步骤都会出错。在实际应用中，搜索系统在 AI 架构中的角色已经发生了变化：从“给人用的搜索”，变成了“给模型用的感知层”。
在实际项目中，我们遇到的典型场景是：
- 业务需求：模型需要基于企业内部文档和数据库回答“某产品在不同版本的合规状态”。
- 数据特点：
1. PostgreSQL 中有结构化版本数据。
2. 文档库中有合规说明、流程文档和条款文本。
3. 数据更新频繁，且存在多个版本。
最初，我们只使用向量检索（embedding + cosine similarity）来召回相关文档，结果发现：
- 模型有时回答错误版本信息。
- 一些关键编码或专业术语无法匹配。
- 结果缺乏可追溯性。
为了解决这个问题，我们做了工程优化：
1. 引入 BM25 关键词检索作为第一召回
- 精确匹配产品编码、版本号、条款编号
- 解决了向量检索无法精确命中的问题
2. 优化分词器 / analyzer
- 针对企业术语和编码格式定制 tokenizer
- 保证“SQL 字段、条款编号、产品型号”等不会被切分错位
3. 混合检索策略（hybrid search)
- BM25 召回保证核心命中
- 向量检索补充语义相似内容
- 最终对候选结果按来源、版本、权重排序
4. 业务保障
- 将 ES/OS 索引和字段映射严格标准化
- 控制检索粒度，避免模型上下文超出 token 限制
- 对每条结果标注来源与版本，实现可追溯
通过这一套策略，模型在企业内部知识检索上的稳定性大幅提升：
- 回答版本信息准确率从 65% → 92%。
- 可追溯性和结果复核变得简单。
- 模型不再“随便猜”，而是依据明确检索结果输出答案。
在企业实际 AI 应用中，搜索工程已经从“辅助工具”升级为模型的“感知层”。数据开发通过调优 BM25、分词器和索引策略，直接决定了 RAG 的稳定性和上限。并且只有能被稳定召回的数据，才有资格进入模型的上下文。而“稳定召回”本身，就是一个典型的数据工程与搜索工程问题。
三、RAG：从“检索结果”到“上下文工程”
当搜索把数据“找出来”之后，并不意味着 RAG 就完成了。
在很多实现中，RAG 被简单等同为：embedding → 向量检索 → 拼接文本，但在真实系统中，这种做法往往效果不稳定，原因在于：检索结果 ≠ 模型上下文。
RAG 的本质，并不是检索本身，而是一次上下文工程：
1. 如何控制上下文粒度。
2. 如何合并或剪裁检索结果。
3. 如何避免重复与噪声。
4. 如何标注数据来源与版本。
5. 如何控制 token 长度。
这个过程决定的不是“能不能答”，而是：模型是在“理解数据”，还是在“猜测答案”。
也正是在这一层，混合检索真正发挥价值：
1. BM25 提供精确、稳定的候选。
2. 向量检索补充语义相似的内容。
3. 数据工程负责最终的上下文组织。
可以说，RAG 的效果上限，几乎由数据工程与搜索工程决定，而不是由模型大小决定。
四、从数据到执行：Dify Workflow 与任务型 Agent
完成了高质量的 RAG，系统仍然存在一个明显边界：它只能“回答问题”，却无法完成复杂业务任务，这正是工作流与 Agent 出现的原因。
在企业 AI 实践中，Agent 是一种工程能力的组合：
1. 多步骤推理。
2. 多次数据检索。
3. 工具调用。
4. 条件判断与结果汇总。
以 Dify 为代表的 AI Workflow，本质上提供的是一种可控的 Agent 实现方式。在这类架构中：
1. 数仓/数据库提供数据基础。
2. 搜索与 RAG 提供模型可用的上下文。
3. Workflow 负责将这些能力编排成可执行的流程。
这意味着，数据第一次不只是被“查询”，而是参与到任务执行之中。
对数据开发工程师而言，这并不是角色的削弱，而是职责的延展：数据能力开始以“节点”的形式，进入 AI 的执行链路。
五、数据开发工程师职责的转变
回看整条链路，会发现一个非常清晰的变化趋势：
过去，数据开发工程师主要关注的是：
1. 表结构是否合理。
2. ETL 是否稳定。
3. SQL 是否正确。
而在 AI 时代，数据开发开始参与更多“模型视角”的工程问题：
1. 数据是否具备可检索性。
2. 搜索策略是否稳定、可控。
3. RAG 上下文是否干净、可解释。
4. Agent 是否能安全地使用数据。
这并不是“转行做 AI”，而是：数据工程开始站在 AI 执行链路的上游，把企业数据，工程化地转译为模型可以感知、理解并执行的能，而不仅仅是写业务SQL。
