聊《一个大数据项目改成 AI 流程后，最难的部分完全变了》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

上周参与了一个需求评审，产品经理问："这个RAG系统什么时候能上线？"我说还差权限校验和日志追踪没搞定。产品经理一脸困惑："不就是查个文档吗，还要权限？"

现场沉默了三秒。

这就是大数据工程师转大模型最常撞上的墙——Demo和上线之间，隔着的不是模型能力，而是工程化。今天复盘一个真实项目，说说我们是怎么从"能跑"走到"能用"的。

目录

• 大数据与大模型的交叉点
• 数据治理：从Hive表到向量库
• 向量数据库：选型不是目的，边界才是
• RAG数据管道：从ETL到Embedding
• 真实案例：权限问题导致上线延期两周
• 失败原因：业务错误、配置错误、环境错误
• 适用边界：什么时候不该照搬方案
• 总结

大数据与大模型的交叉点

大数据和AI工程有很多重叠，但边界在变。

过去你做ETL，核心是保证数据从A到B不出错。现在做RAG，核心是保证数据被模型正确理解和检索。输入输出格式变了，质量评估方式也变了。

我们团队转大模型时，最大的错觉是"大数据能力直接平移"。事实是：

• Hive表查询 → 向量检索，逻辑相似但语义维度完全不同
• 数据质量校验 → Embedding质量评估，指标体系没建立起来
• 调度依赖 → Agent工具调用链，异步和不确定性让调度失效

真正拉开差距的，是对"不确定性"的处理能力。大数据场景下，输入确定、输出确定。大模型场景下，输入确定、输出不确定。

数据治理：从Hive表到向量库

数据治理是大数据工程师的基本盘，但转大模型后，治理对象变了。

我们当时接了一个内部知识库项目，原始数据是500张Hive表，涉及财务、人力、产品三条业务线。传统做法是建数据仓库，现在要建向量库。

踩的第一个坑：直接拿原始数据做Embedding。

结果检索出来的内容全是乱码，因为Hive里的JSON字段、XML配置、Base64图片，全部扔进文本编码器，Embedding质量极差。

正确的做法是分层治理：

1. 清洗层：去掉HTML标签、压缩空白、统一编码
2. 切分层：按段落/章节切分，控制Token数在500-800之间
3. 元数据层：保留来源表、更新时间、权限标签
4. 向量化层：选择与业务语义匹配的Embedding模型

这段治理逻辑，和传统数仓的ODS→DWD→DWS层思路一致，只是多了一层语义切分。

向量数据库：选型不是目的，边界才是

向量数据库选型，网上文章写了一堆。但真正决定上线的，是业务边界。

我们项目最终选了Milvus，原因很简单：团队有运维经验，数据量预估在千万级，延迟要求<200ms。

但选型之后才发现，真正的问题是召回策略。

Demo阶段用Top-5召回，准确率看起来不错。上线后发现，业务场景对准确率要求极高——财务数据出错就是事故。于是加了阈值过滤和重排序。

这里有一个取舍：召回率 vs 精确率。Demo阶段追求召回率，上线阶段追求精确率。

RAG数据管道：从ETL到Embedding

大数据工程师做RAG，最顺手的是数据管道。但管道里有一步变了：Embedding。

我们写了一个完整的RAG管道，核心逻辑如下：

class RagDataPipeline:
    def __init__(self, embedding_model, vector_db):
        self.embedder = embedding_model
        self.db = vector_db

    def ingest(self, source_table, chunk_size=512):
        # 1. 从Hive读取原始数据
        df = self._read_hive(source_table)

        # 2. 数据清洗和切分
        chunks = self._chunk_and_clean(df, chunk_size)

        # 3. 批量Embedding
        embeddings = self.embedder.encode([c.text for c in chunks])

        # 4. 写入向量库，附带元数据
        self.db.upsert(
            vectors=embeddings,
            metadata=[{
                'source': source_table,
                'chunk_id': c.id,
                'permission': c.permission_level,
                'updated_at': c.timestamp
            } for c in chunks]
        )

    def retrieve(self, query, top_k=5, permission_filter=None):
        # 1. 查询Embedding
        query_vec = self.embedder.encode([query])[0]

        # 2. 向量检索
        results = self.db.search(query_vec, top_k=top_k)

        # 3. 权限过滤（关键步骤）
        if permission_filter:
            results = [r for r in results if r.metadata['permission'] <= permission_filter]

        return results

代码解释：

• ingest方法对应传统ETL的Extract-Transform-Load，但多了Embedding步骤
• chunk_and_clean是核心，切分策略直接影响检索质量
• retrieve方法里加了权限过滤，这是Demo阶段最容易忽略的
• 元数据里带了permission字段，用于运行时权限控制

这段代码看起来简单，但权限过滤那一步，是上线前最后加上去的。

真实案例：权限问题导致上线延期两周

说一个真实案例。

项目Demo阶段一切正常，检索准确率85%，产品经理很满意。上线前做安全评审，发现一个问题：所有用户都能检索到全部数据，包括财务敏感信息。

排查过程：

现象：测试环境权限正常，生产环境权限失效。

验证动作：
1. 检查代码，发现权限过滤逻辑在retrieve方法里
2. 检查Milvus查询，发现没传expr参数过滤权限
3. 检查部署配置，发现环境变量PERMISSION_LEVEL没注入

排除结果：

• 代码逻辑没问题
• Milvus查询没问题
• 问题是部署时环境变量没注入，导致permission_filter默认为None，权限过滤被跳过

修复方式：在K8s部署配置里加了ConfigMap注入环境变量。

这次事故让我们意识到：Demo能跑通，不代表上线能跑通。环境变量、权限配置、日志追踪，这些在Demo阶段可以忽略的东西，上线前必须全部补全。

失败原因：业务错误、配置错误、环境错误

做RAG项目，失败原因可以分成三类：

业务错误：检索结果不准确。

• 原因：Embedding模型选择不当、切分策略不合理、元数据缺失
• 区分方法：检查Embedding质量、分析切分结果、验证元数据完整性

配置错误：权限、阈值、超时配置不对。

• 原因：环境变量没注入、配置文件没同步、测试和生产配置不一致
• 区分方法：检查环境变量、对比配置文件、验证运行时参数

环境错误：向量库连接失败、Embedding服务超时、GPU显存不足。

• 原因：资源不足、网络问题、依赖服务不可用
• 区分方法：检查日志、监控资源使用、验证依赖服务状态

这三类错误，大数据工程师最容易犯的是配置错误。因为传统数仓项目，配置一旦部署好就不怎么改。但大模型项目，配置项多、环境变量多、依赖服务多，配置错误的概率成倍增加。

适用边界：什么时候不该照搬方案

这个RAG方案不是万能的。有几个边界需要明确：

适用场景：

• 知识库检索、文档问答、内部系统查询
• 数据量在千万级以下
• 延迟要求<500ms
• 权限体系相对简单

不适用场景：

• 实时性要求极高的场景（向量检索有延迟）
• 数据量超过亿级（需要考虑分片策略）
• 权限体系复杂（多级权限、动态权限）
• 需要高并发（向量数据库吞吐有限）

取舍建议：

• 如果业务场景对准确率要求极高，考虑加入重排序模型
• 如果数据量很大，考虑先用传统搜索做粗筛，再用向量检索做精排
• 如果权限体系复杂，考虑在Embedding之前加权限过滤层

总结

从大数据转大模型，技术栈变化不大，但工程思维要变。

Demo阶段追求"能跑"，上线阶段追求"可控"。权限、日志、可观测，这些在Demo阶段可以忽略的东西，上线前必须全部补全。

我们团队这个项目，最终上线延迟两周，原因是权限配置问题。但这也让我们建立了完整的RAG工程化标准：权限过滤、日志追踪、质量评估、失败兜底。

大数据工程师转大模型，最大的优势是工程化能力。最大的挑战是对不确定性的处理。Demo能跑通只是开始，权限日志补全才是上线那道坎。

资料展示

下面是我整理的AI大模型学习资料和工具包预览，适合收藏后按主题逐步学习。

需要这份AI大模型资料清单的话，在评论区回复「清单」即可；我会根据大家的问题继续补充对应的实战内容。