当RAG遇上数仓：数据开发正在悄悄换赛道

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01

前言

前阵子听朋友吐槽，去面个数据开发岗，二面面到一半，面试官突然抛了个问题：你做的数仓里，哪一层最适合给RAG做检索？

他当场就卡壳了。

SQL八股背得滚瓜烂熟，维度建模翻了三遍，Spark调优的笔记记了小半本，偏偏这道题，既不像传统数开题，也不是纯大模型题，属于两不管的跨界题。

出来他跟我抱怨，说现在面试怎么偷偷换题库了，连个通知都没有。我心想这哪是换题库啊，这是连考试范围都变了。

1. 不是题库更新了，是岗位的终点变了

把两三年前的面试题和现在的放一块对比，差别真不是多了几个AI名词这么简单。

核心变的，是数据最后喂给谁。

1.1 以前的数开，主打一个数据给人看

过去干数开，逻辑很顺：采数据、洗数据、建模型、做汇总，最后输出到BI报表、经营看板，给业务同学看数做决策。

所以能力栈多少年都很稳：SQL、维度建模、Hive/Spark/Flink调优、数仓分层、调度ETL、数据治理。就像开饭馆，菜单十年不换，厨子把菜炒好就行。

1.2 现在多了个新甲方：AI

现在不一样了，数据不光要给人看，还要给AI用。Agent要调，RAG要召回，模型还要靠真实数据迭代。

相当于饭馆突然多了批外卖订单，客人不光要吃菜，还要按特定规格打包、配餐、准时送，你原来那套堂食流程，就得改改。

1.3 能力不是推倒重来，是叠buff

别觉得以前学的都没用了，旧能力一点没过期，只是上面又叠了一层新要求。

原来的数仓分层还得会，现在还要懂Embedding、向量检索、RAG混合召回；原来的数据质量还得做，现在还要管AI上下文治理、防幻觉。

说白了，以前终点是“BI给人看”，现在多了个终点：把数据做成AI能懂、能搜、能调用、能溯源的上下文。不是旧题换了新题，是老本事有了新用场。

2. 别急着从头学AI

很多人一看到面试题变了，第一反应就是赶紧补大模型知识，背Transformer架构、刷Prompt技巧，恨不得把自己速成半个算法工程师。

基础概念当然要懂，但光靠背名词，走不远。一来标准答案网上一搜就有，没真实经验，面试官追问两句就露馅；二来你本来最值钱的数仓经验，反而浪费了。

2.1 很多新名词，都是老本事换马甲

其实很多AI领域的新概念，和你早就会的数仓能力，本质是一回事。

数仓建模，放到AI场景里就是语料建模、Chunk切片策略；数据质量，对应检索召回质量、Chunk质量；数据治理，就是AI上下文治理、幻觉防控；ETL调度，对应索引重建、Embedding增量更新。

就像你原来卖包子，现在改卖汉堡，揉面、调馅、控火候的手艺都还用得上，只是换了个面包胚，加了片生菜。

2.2 换个视角重读你的旧项目

最有效的升级方式，不是从零学新东西，而是用AI的视角，把你做过的项目再过一遍。

比如问问自己：如果把这些结构化数据转成可检索的语料，该怎么组织文本、切分Chunk、加元数据？原来的数据质量监控，哪些指标能挪去监控检索质量？已有的元数据和血缘，怎么帮着把回答溯源到来源表和加工规则？

这套想明白，你就不是“会点AI的数开”，而是“能把AI数据链路做稳的数开”，听起来差几个字，稀缺度差远了。

2.3 现在就能做的三个小动作

第一，把你做过的数仓项目拿出来重写一遍，假设要加RAG或者Agent场景，数据模型、权限、质量指标、更新机制该怎么改。

第二，跑一个端到端的真实项目，别做玩具demo，要有真实数据、可量化指标、异常处理、增量更新和溯源链路。

第三，做一次业务方案演练，假设业务要上一个Agent，你从数据侧出完整方案：数据从哪来、怎么洗、怎么检索、怎么控权、怎么监控，坏案例怎么回流优化。

3. 真正拉开差距的三项硬能力

面试的时候，第一层问题考你知不知道，再往下挖，就是考你到底做没做过。下面这三项，就是面试官最爱深挖的点。

3.1 打通“数据→Embedding→向量库”全链路

重点不是接个Embedding API就完事，而是把整条链路做成能上线、能扩展、好维护的系统。

比如Chunk怎么切，按句子还是按语义，要不要留重叠？ANN索引选HNSW还是IVF、PQ，召回率、内存、延迟怎么平衡？百万级数据怎么批量写，不会把向量库打崩？Embedding模型升级了，怎么重建索引还不影响线上服务？

你看，批量处理、性能调优、增量更新、双版本切换，这些本来就是数开的老本行。说白了，换了个存储介质，核心逻辑还是那套工程化思维。

3.2 搞懂各路检索的边界在哪

别觉得RAG就是向量检索，生产级的方案从来不是单选。

SQL擅长精确过滤和聚合，复杂关系推理就不行；向量检索能找语义相似的，碰到产品编码、金额、日期这种精确条件就容易翻车；全文检索适合关键词匹配，用户换个说法可能就搜不到了。

真要落地，都是结构化查询、知识图谱、全文、向量混着来，最后用Rerank融合结果。能说清每种方案的优缺点和适用场景，比只会报技术名词管用多了。

3.3 把数据反馈闭环真正跑起来

AI用数据会产生调用日志，日志里有失败请求、有低质量回答，把这些坏案例挑出来，回流到检索数据、评测集或者训练集里，持续优化。

这不是喊一句“持续迭代”的口号就行，背后是一整套口径、版本、标注、调度、质量监控、效果评估的数据链路。模型工程师更关心模型本身，而把这条闭环的数据流做稳，恰恰是数开最擅长的事。

4. 数开专属的实战升级路线

想把上面这些能力落地，可以按四个项目一步步来，不是四个零散的demo，是从数仓治理到Data Agent的完整链路。

4.1 第一步：把数仓底座做扎实

先从金融数仓加数据治理入手，把ODS、DWD、ADS分层跑通，补全主数据、数据契约，还有SLA/SLO这些治理机制。

地基打不稳，上面盖什么都容易塌。先把可信的数据底座做牢，后面加AI场景才不会处处踩坑。

4.2 第二步：加上实时链路和知识图谱

用Flink CDC做实时链路，处理双流同步、实体管理、图谱关系。让数据不光能查字段值，还能查实体之间的关联。

相当于原来你只有食材清单，现在连食材之间的搭配禁忌、烹饪顺序都理清楚了。

4.3 第三步：搭起混合检索体系

组合Elasticsearch、向量模型，做混合召回加Rerank，建立可量化的检索评测体系，持续优化召回率、准确率和最终答案质量。

这一步就是把“能搜”变成“搜得准”，从能用变成好用。

4.4 第四步：串起Data Agent闭环

加上SQL沙箱、Function Call、坏案例挖掘、数据集回流，把检索、调用、安全、迭代串成完整闭环。

到这一步，就不是单纯给AI喂数据了，而是搭了一套能自我优化的数据供给系统。

最后说句实在的，数据开发这个岗位不会消失，就像前后端、数据分析都不会消失一样，但都会慢慢加上AI的属性。

这场变化不是AI要替代数开，而是要求数开变成“AI的数据工程师”。不用人人都去训模型，但得懂AI怎么消费数据、在哪容易出问题、怎么把这条链路做的稳定可控可追溯。

毕竟手艺在身，换个赛道照样吃饭。

P.S. 无意间发现了一个巨牛的人工智能教程，非常通俗易懂，对AI感兴趣的朋友强烈推荐去看看，传送门https://blog.csdn.net/HHX_01