这篇不先堆名词。我们把《大数据转大模型：一次新的项目切入》拆成几级台阶，看完至少知道下一步该学什么、该练什么。

摘要

先把这篇文章的目标说清楚：看完之后，你应该能判断这件事值不值得做，以及从哪里动手。

最近跟几个做数仓的朋友聊天，大家普遍有一种焦虑：Hadoop 生态稳如泰山但也波澜不惊，而大模型（LLM）的热度虽然还在，但风向变了。以前是拼谁家的 Prompt 写得花哨，现在业务方直接问：“你的模型能访问哪个部门的表？”、“出错了我怎么回溯？”、“权限怎么控制？”。

这就是从 Demo 到 Production 的鸿沟。对于数据工程师（DE）来说，这其实是好事。因为 LLM 应用的核心瓶颈，往往不是算法，而是数据治理和工程化落地。如果你能搞定结构化数据的清洗和管道，那么处理非结构化数据的 RAG（检索增强生成）管道，本质上只是换了一种数据形态，逻辑是相通的。

今天不聊虚的概念，就结合我最近帮一家金融客户搭建内部知识库的经历，聊聊数据工程师如何带着“旧手艺”杀入 AI 时代，特别是如何处理那些让人头秃的权限、日志和可观测性。

目录

• 大数据与大模型的交叉点：从 ETL 到 ETL+
• 数据治理：不仅是清洗，更是“对齐”
• 向量数据库：选型与反直觉判断
• RAG 数据管道：代码实战
• 落地项目：从 Demo 转向权限、日志和可观测
• 总结

大数据与大模型的交叉点：从 ETL 到 ETL+

很多 DE 转行 AI 的第一步是去学 LangChain 或者 LlamaIndex，然后发现很快就被各种 Agent 框架绕晕了。其实，回归本质，大模型应用的数据流依然逃不开 Extract, Transform, Load 的变体。

在传统数仓里，我们关注的是数据的准确性、一致性和时效性。在 RAG 场景下，我们需要关注的是：
1. 文档切片（Chunking）：这就像数据清洗中的分箱操作，切不好，语义就断了。
2. 向量化（Embedding）：这是将文本映射到高维空间的过程，类似于特征工程。
3. 检索与重排序（Retrieval & Rerank）：这相当于 SQL 查询优化，不仅要快，还要准。

我的建议是：不要急着写代码。先画出你的数据流向图。你会发现，之前的 Hive/Spark SQL 经验在这里依然值钱。比如，如何用 Spark 并行处理千万级 PDF 的文本提取，这比 Python 单线程脚本高效得多。

数据治理：不仅是清洗，更是“对齐”

在大模型时代，数据治理的内涵扩大了。以前我们治理的是数值和枚举值，现在我们要治理的是事实一致性和安全合规。

举个反例。某电商团队直接把商品评论扔进向量库，结果用户问“这款手机电池耐用吗”，模型基于负面评论给出了极其消极的回答，甚至引战。这是因为缺乏“治理”环节——没有对评论进行情感标注或过滤，也没有建立负面反馈的修正机制。

对于 DE 来说，你需要建立新的治理标准：

• 毒性过滤：在 Embedding 之前，必须有一层 LLM 或规则引擎来过滤敏感、攻击性内容。
• 时效性标记：金融政策、产品价格变化极快，必须在元数据中打上 updated_at 字段，并在检索时赋予更高权重。
• 来源追溯：每一段向量数据，必须能追溯到原始文档的 URL、章节和作者。这是后续审计的基础。

向量数据库：选型与反直觉判断

很多人第一反应是 Milvus 或 Pinecone。但在企业内网环境中，尤其是涉及权限隔离时，我倾向于推荐 PostgreSQL + pgvector或者Elasticsearch。

为什么？因为你们团队已经熟悉 SQL 了。

Vector DB 最大的坑在于混合检索。纯向量相似度搜索（Semantic Search）只能解决“意思相近”的问题，解决不了“精确匹配”的问题。比如用户搜“订单号 123456”，向量搜索可能找不到，但 BM25 可以找到。

因此，最佳实践通常是 Hybrid Search（向量 + 关键词）。如果你用 ES 或 PG，可以直接利用现有的权限体系和索引能力，不需要引入新的运维组件。对于从大数据转过来的人来说，维护一套 K8s 集群跑 Milvus 的成本，远高于维护一个 PG 实例。

RAG 数据管道：代码实战

这里给一个基于 Python 和 LangChain 的简单 RAG 管道示例，重点展示权限过滤和元数据注入的部分。注意，我在 Embedding 前加了一个模拟的权限检查步骤，这是生产环境必备的。

from langchain_community.document_loaders import PyPDFLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import FAISS # 示例使用 FAISS，生产建议 PG/ES
from langchain_openai import OpenAIEmbeddings
import uuid

def build_rag_pipeline(pdf_path, user_role="analyst"):
    """
    构建带有权限控制的 RAG 管道
    """
    # 1. 加载与解析
    loader = PyPDFLoader(pdf_path)
    documents = loader.load()

    # 2. 切片 (Chunking) - 关键参数调整
    text_splitter = RecursiveCharacterTextSplitter(
        chunk_size=500,
        chunk_overlap=50,
        length_function=len
    )
    chunks = text_splitter.split_documents(documents)

    # 3. 数据治理：注入元数据与权限标记
    # 在生产环境中，这里应该对接 IAM 系统或 RBAC 数据库
    processed_chunks = []
    for chunk in chunks:
        # 模拟权限过滤：如果用户角色无权访问该文档标签，则丢弃
        if "internal" in chunk.metadata.get("tags", []) and user_role != "admin":
            continue

        # 为每个 chunk 生成唯一 ID，便于溯源
        chunk.metadata["doc_id"] = str(uuid.uuid4())
        chunk.metadata["user_role_access"] = [user_role]
        processed_chunks.append(chunk)

    # 4. 向量化与存储
    embeddings = OpenAIEmbeddings()
    vectorstore = FAISS.from_documents(processed_chunks, embeddings)

    return vectorstore

# 使用示例

# db = build_rag_pipeline("financial_report_2024.pdf", user_role="intern")

这段代码看似简单，但包含了三个关键点：切片策略、元数据增强和权限前置。在大数据开发中，这就像是你在 Spark Job 里加了 filter 和 withColumn。

落地项目：从 Demo 转向权限、日志和可观测

业务方提的需求通常是：“帮我做一个能问公司制度的 Bot。”
你给的 Demo 是：“没问题，基于 LangChain 搭建，准确率 80%。”
但上线时，PM 会问：
1. 权限：实习生能看到高管薪资制度吗？
2. 日志：用户问了个敏感问题，模型回答了错误信息，怎么追责？
3. 可观测：检索延迟太高，是因为向量库慢，还是模型推理慢？

这就是数据工程师的优势所在。我们可以用传统数仓的思维来解决这些问题：

• 构建“Chat Log”宽表：不要只存聊天记录。要把 user_id, query_embedding (或者 query hash), retrieved_docs_ids, llm_response, latency_ms, cost_tokens 全部存入 ClickHouse 或 Doris。这样你可以随时分析：“哪些文档被检索最多但点击最少？”（说明相关性差），“哪些用户提问耗时最长？”（说明系统瓶颈）。
• Trace 追踪：集成 OpenTelemetry。每一个 RAG 请求，从 User Input -> Retrieval -> Generation -> Output，都要有一个唯一的 Trace ID。当用户投诉“回答错误”时，你能通过 Trace ID 精准定位是哪一段文档导致了幻觉，从而修正向量库中的数据。
• A/B 测试框架：在大模型领域，Prompt 的迭代极快。利用你的数据管道能力，构建一个简单的 A/B 测试平台，对比不同 Prompt 模板或不同 Embedding 模型的效果。用转化率、满意度评分说话，而不是凭感觉。

总结

从大数据转向大模型工程，并不是要抛弃你过去的技能，而是要升级它们。

以前你关注的是 PB 级数据的存储和计算效率，现在你关注的是 KB 级知识片段的语义检索精度和业务安全性。向量数据库、RAG 框架、LLM API，这些只是新的“表”和“函数”。真正的核心竞争力，依然是数据治理的严谨性、管道设计的健壮性以及可观测体系的完备性。

如果你能把一个 RAG 系统的日志埋点做得像监控 Hadoop Job 一样清晰，把权限控制做得像 Hive ACL 一样严格，你就已经完成了从传统数据工程师到 AI 基础设施专家的转型。

别再去死磕复杂的 Agent 编排了，先把底层的“数据地基”打牢。这才是大厂真正需要的能力。

资料展示

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

如果你想看完整资料目录，可以在评论区留言「资料」；也欢迎告诉我你更关注AI大模型里的哪类内容。