面试官突然问：“数仓哪一层最适合做RAG？”他一下被问住了…

面试复盘时一位同学去面某厂的数据开发岗。二面进行到一半面试官突然问❝“你做过的 数仓里哪一层最适合给 RAG 做检索为什么”他一下被问住了。SQL 八股背了维度建模复习了Spark 调优也准备得很充分。偏偏这道题既不像传统数开题也不是纯粹的大模型题。面试结束后他跟我吐槽“感觉这两年数开岗位静悄悄换了一茬题。题库变了自己却连通知都没收到。”这句话很真实。很多数开不是能力突然不够了而是岗位的考察坐标发生了偏移。接下来我们就把这件事拆开说清楚题目为什么变、变到了哪里以及现在该怎么准备。1.不是题库更新而是岗位的终点变了把两三年前和现在的数开面试题放在一起看最明显的变化并不是题库里多了几个 AI 名词而是数据最终要服务的对象变了。过去数开的主要任务是“把数据做好给人看”。数据经过采集、清洗、建模和汇总最后进入 BI 报表、经营看板和分析系统帮助业务人员做判断。因此传统能力栈一直很稳定SQL、维度建模以及星型模型与雪花模型的取舍Hive、Spark、Flink 的开发与性能调优ODS、DWD、DWS、ADS 等数仓分层调度、ETL、数据质量与异常追溯元数据、血缘、数据字典等治理能力这些能力没有过期。只是今天越来越多的数据还要“给 AI 用”。Agent 要能稳定调用RAG 要能准确召回模型还要从真实反馈中持续改进。于是能力栈上面又叠了一层Embedding、向量检索与 ANN 索引RAG、混合召回、知识图谱与 Rerank数据契约、SQL 沙箱与 Agent 调用反馈AI 上下文治理、权限控制与幻觉风险防控一句话概括❝以前的终点是“BI 给人看”现在又多了一个终点让数据成为 AI 可以理解、检索、调用和追溯的上下文。不是旧题被新题替代而是旧能力之上增加了新的使用场景。2.别急着“再学一门 AI”看到题目变化很多人的第一反应是赶紧刷 Transformer 架构、背 Prompt Engineering再把大模型名词过一遍。基础概念当然要懂但如果准备只停在背诵层面收益往往有限。原因也很直接标准答案随手就能查到没有真实链路经验追问两层就容易露怯更重要的是你原本最值钱的数据经验反而没有被用起来。❝更有效的路线不是把自己重新训练成半个 算法工程师而是用 AI 的视角重读一遍你已经做过的 数据工程。很多看似陌生的新名词其实都能在旧能力里找到对应关系你甚至可以拿过去的项目逐个追问如果把结构化事实转成可检索语料应该怎样组织文本、Chunk 和元数据原来的数据质量监控哪些指标可以迁移到检索质量监控已有的元数据和血缘怎样帮助回答结果追溯到来源表、版本和加工规则这套转换做完你的定位就不再是“会一点 AI 的数开”而是“能把 AI 数据链路做稳的数开”。两者听起来只差几个字实际稀缺度完全不同。可以立刻做的 3 个动作❝动作一重写一遍旧项目给每个做过的数仓项目补一段如果今天重做并增加 RAG 或 Agent 的使用场景数据模型、权限、质量指标和更新机制会怎么变❝动作二跑通一个 端到端项目不要只做能演示的 toy demo。项目里要有真实数据、可量化指标、异常处理、增量更新和可追溯链路。❝动作三做一次 业务方案演练假设业务方要上线一个 Agent你从数据侧给出完整方案数据从哪里来、如何清洗、如何检索、怎样控权、怎么监控以及 bad case 如何回流。3.真正拉开差距的 3 项能力!第一层问题考你知不知道第二层、第三层就会追问你到底做没做过。下面三项能力正是新题里最容易被向下深挖的地方。❝能力一打通“数据 → Embedding → 向量库”重点不是接通一个 Embedding API而是把整条链路做成可上线、可扩展、可维护的数据系统。你至少要能说清楚Chunk 如何按句子、段落或语义切分是否需要 overlapHNSW、IVF、PQ 等 ANN 索引如何在召回率、内存和延迟之间取舍百万级数据怎样批量写入如何避免把向量库打爆Embedding 模型升级后怎样重建索引并平滑切换不影响线上服务你会发现批量处理、性能调优、增量更新、双版本切换本来就是数开的优势区。❝能力二理解 SQL、图谱、全文与向量的边界SQL 擅长精确过滤和聚合却不擅长复杂关系推理向量检索能找到语义相似内容但对产品编码、金额、日期等精确条件并不可靠全文检索适合关键词匹配却未必理解用户换了一种说法后的真实意图。生产级 RAG 往往不是“只选一个”而是把结构化查询、图谱关系、全文和向量召回组合起来再通过 Rerank 融合结果。能讲清每种方案的边界比只会报技术名词更重要。❝能力三把数据反馈闭环真正跑起来AI 使用数据产生调用日志日志里暴露失败请求和低质量答案团队再从中识别 bad case回流到检索数据、评测集或训练集。这不是一句“持续优化”而是一条需要口径、版本、标注、调度、质量监控和效果评估的数据链路。模型工程师更关注模型本身数开最有优势的恰恰是把闭环里的数据流做稳。4.更适合数开的实战路线如果想把上面的能力真正练出来可以按下面四个项目逐步推进。它不是四个彼此孤立的 demo而是一条从数仓治理走向 Data Agent 的完整链路。❝篇一金融数仓 数据治理覆盖 ODS、DWD、ADS 分层补齐主数据、数据契约以及 SLA/SLO 等治理机制。先把可信数据底座做稳。❝篇二实时离线 Pipeline 知识图谱通过 Flink CDC 构建实时链路处理双流同步、实体管理和图谱关系让数据不仅能查字段还能查关系。❝篇三搜索引擎 语义检索组合 Elasticsearch、BGE、混合召回与 Rerank建立可量化的检索评测体系持续优化 Recall、Precision 和最终答案质量。❝篇四Data Agent 反馈闭环加入 SQL 沙箱、Function Call、bad case 挖掘和数据集回流把检索、调用、安全与迭代串成闭环。最后数开不会凭空消失但会继续进化同样前后端也不会消失但是会AI,数据分析等。我们要通过现象看本质AI时代的本质。这场变化并不是简单地用 AI 替代数据开发而是要求数据开发进一步成为“AI 的数据工程师”。你不必人人都去训练模型但需要理解 AI 如何消费数据、在哪些地方容易失真以及怎样让这条链路稳定、可控、可追溯。