大数据转大模型：数据工程师凭什么能赢？

聊《做过大数据的人学大模型，哪些经验可以直接迁移？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

最近面试了几个从大数据转过来的候选人，有个现象挺有意思：算法岗的同学讲 RAG 讲得头头是道，但问到"你的 pipeline 出错了怎么定位"，很多人就卡壳了。而数据工程师出身的同学，虽然对模型本身不够熟，但聊到数据流转、质量把控、监控告警，反而能说出点东西。

这不是偶然。大模型应用从 Demo 走向生产，真正卡住团队的已经不是模型调用本身，而是权限、日志、可观测这些工程化问题。而这恰恰是大数据工程师的老本行。

目录

• 大数据和大模型的交叉点在哪
• 数据治理：大模型时代的新战场
• 向量数据库：别把它当传统数据库用
• RAG 数据管道：把 ETL 经验用对地方
• 落地项目：简历上怎么写
• 总结

大数据和大模型的交叉点在哪

很多人觉得大数据和大模型是两个世界，其实底层逻辑高度重合。

我带过一个项目，要把公司内部的文档知识库接入 RAG 系统。算法同学负责调模型，我负责数据管道。一开始大家都觉得这很简单——文档分块、向量化、存向量库，完事。

结果上线第一周就出问题了。

某个业务线的文档突然大量返回空结果，排查了两天才发现，是上游数据源做了一次 schema 变更，字段名改了但下游管道没同步更新，导致解析失败，整个数据流静默中断。如果是在传统大数据项目里，这种问题通常会有告警，但在 RAG pipeline 里，没有明显报错，只有"结果不对"。

这恰恰是数据工程师的价值所在。模型调得好不好是算法问题，但数据流得顺不顺是工程问题。

大数据工程师的核心能力——数据血缘追踪、质量校验、异常检测、容错设计——在大模型时代不仅没过时，反而更关键了。因为大模型放大了数据质量问题的影响：脏数据进，垃圾答案出，而且你还不知道是哪一步出的问题。

数据治理：大模型时代的新战场

传统大数据的数据治理关注的是准确性、完整性、一致性。大模型时代，这些依然重要，但还多了几个新维度。

第一个是来源可追溯。RAG 系统返回的答案需要能追溯到原始文档，否则业务方不敢用。这意味着你的管道需要保留完整的元数据：文档来源、处理时间、分块策略、向量 ID。这些信息在简历项目里怎么写？我见过最好的表达方式是：

> "构建了基于 Spark 的文档处理管道，支持 500 万字/天的处理能力，每条向量记录携带完整血缘元数据（sourceid、chunkindex、processing_timestamp），支持答案溯源到原文定位。"

有数字、有技术细节、有业务价值，比"负责数据清洗和向量化"强太多了。

第二个是权限控制。大模型应用经常需要访问不同敏感级别的数据，但很多团队的做法是直接把数据喂给模型，没有任何隔离。我在一个金融客户的项目里看到过，客服系统接入了包含客户身份证信息的文档库，但没有任何权限过滤，任何客服都能问到任何客户的信息。

数据工程师在这里的角色是：设计数据分级策略，在管道层做权限标记，确保向量检索时能带上权限过滤条件。

第三个是数据新鲜度管理。大模型应用对数据的时效性要求往往比传统报表更高。交易数据、库存数据、用户行为数据，延迟过高会导致模型给出过时的答案。这需要你设计增量更新机制，而不是每天全量跑。

向量数据库：别把它当传统数据库用

很多大数据工程师转过来之后，习惯把向量数据库当成普通数据库用。这是个误区。

向量数据库的核心操作是近似最近邻搜索（ANN），它的性能特征和关系型数据库完全不同。IOPS 不是瓶颈，召回率和延迟才是。

我在选型时踩过一个坑：初期选了 Elasticsearch，因为团队熟悉。但文档量到千万级之后，查询延迟从 50ms 涨到 2s 以上，而且召回率明显下降。后来换回 Milvus，同样的硬件条件下延迟稳定在 100ms 以内。

选型建议：

• 数据量百万级以下，Elasticsearch 够用，团队熟悉就行
• 百万级以上，优先考虑 Milvus、Qdrant 这类专用向量库
• 如果需要和现有大数据生态集成（Hive、Iceberg），可以用 StarRocks 或 Doris 的向量检索能力

代码层面，向量检索的 pipeline 通常长这样：

from pymilvus import connections, Collection
import numpy as np

class VectorSearchPipeline:
    def __init__(self, collection_name: str, timeout: float = 10.0):
        connections.connect("default", host="your-milvus-host", port="19530")
        self.collection = Collection(collection_name)
        self.collection.load()
        self.timeout = timeout

    def search(
        self,
        query_vector: list[float],
        top_k: int = 5,
        filter_expr: str = None
    ) -> list[dict]:
        """
        带权限过滤的向量检索
        filter_expr 示例: "tenant_id == 'abc' and dept == 'finance'"
        """
        limit = top_k * 3  # 多召回一些再做精排

        search_params = {
            "metric_type": "IP",
            "params": {"nprobe": 16}
        }

        results = self.collection.search(
            data=[query_vector],
            anns_field="embedding",
            param=search_params,
            limit=limit,
            expr=filter_expr,
            timeout=self.timeout
        )

        return self._format_results(results)

    def _format_results(self, results) -> list[dict]:
        formatted = []
        for hits in results:
            for hit in hits:
                formatted.append({
                    "id": hit.id,
                    "score": float(hit.distance),
                    "text": hit.entity.get("text"),
                    "source": hit.entity.get("source"),
                    "chunk_index": hit.entity.get("chunk_index")
                })
        return sorted(formatted, key=lambda x: x["score"], reverse=True)

注意代码里的几个细节：limit = top_k * 3 是为了先粗召回再精排；filter_expr 是权限过滤的关键；返回结果带了 source 和 chunk_index，这是溯源的基础。

RAG 数据管道：把 ETL 经验用对地方

RAG 的数据管道本质上就是一个 ETL 过程，只是多了 Embedding 这一步。但正因为多了一步，很多传统 ETL 的经验需要调整。

数据分块（Chunking）不是随意切。我见过太多团队用固定的字符数切分，结果一个完整的技术文档被切成三截，向量检索时只能召回其中一段，答案自然不完整。

我的做法是按语义分块：

from langchain.text_splitter import RecursiveCharacterTextSplitter

def chunk_documents(texts: list[str], chunk_size: int = 500, chunk_overlap: int = 50):
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=chunk_overlap,
        separators=["\n\n", "\n", "。", ". ", " ", ""],
        length_function=len,
    )

    chunks = []
    for text in texts:
        split_chunks = splitter.split_text(text)
        for i, chunk in enumerate(split_chunks):
            chunks.append({
                "text": chunk,
                "chunk_index": i,
                "total_chunks": len(split_chunks),
                "source_text": text[:100] + "..."  # 用于调试和溯源
            })

    return chunks

关键参数：separators 的优先级决定了分块边界，优先在段落之间切分，其次在句子之间。chunk_overlap 保证相邻块之间有语义衔接，避免关键信息被切断。

Embedding 的选择影响下游效果。不同模型的 Embedding 质量差异很大，而且和 RAG 系统的整体效果强相关。我的经验是：

• 中文场景优先选 text-embedding-v3 或 bge-m3
• 需要多语言支持选 text-embedding-v3 或 mxbai-embed-large
• 不要在生产环境频繁切换 Embedding 模型，向量空间不通用会导致召回结果完全变化

管道监控指标要设计好。传统大数据管道关注数据量和延迟，RAG 管道还需要关注：

• 分块成功率：多少文档成功切分，多少失败
• Embedding 成功率：多少向量成功生成
• 召回率：查询能召回多少结果
• 答案相关性：人工抽检或自动评估

这些指标需要在管道里埋点，而不是等出了问题再排查。

落地项目：简历上怎么写

这是我最想说的部分。很多数据工程师转大模型，简历写得很平淡：

> "负责 RAG 系统的数据管道开发"

面试官看不出你做了什么，也看不出你解决了什么问题。

我的建议是用"问题-方案-结果"的结构来写，而且要具体到数字和细节：

差的写法：
> "搭建了基于 LangChain 的 RAG 系统，使用 Milvus 存储向量，实现了文档问答功能。"

好的写法：
> "设计并实现了企业知识库 RAG 系统，日均处理文档 2000+ 篇，向量库规模 500 万+。引入权限过滤机制，支持多租户数据隔离。查询延迟 P99 < 500ms，答案准确率人工抽检 85%。设计了完整的管道监控体系，包括分块成功率、Embedding 成功率、召回率等核心指标，异常告警响应时间 < 5 分钟。"

注意几个要点：

1. 有数字：2000+ 篇、500 万+、500ms、85%、5 分钟。数字让项目可信。
2. 有技术细节：权限过滤、多租户、监控指标。体现你的工程深度。
3. 有业务价值：答案准确率、响应时间。体现你对结果负责。

如果你没有实际项目经验，可以用开源项目做实践，但一定要自己改造和扩展，不要只是跑通 Demo。比如：

• 在 LangChain 的 RAG 示例基础上，加上权限过滤和完整监控
• 用真实的业务数据（比如公司内部的文档）做测试
• 记录性能数据和准确率数据

这些改造和实验过程，才是你真正能讲出来的东西。

总结

大数据转大模型，不是从零开始，而是能力迁移。你的 ETL 经验、数据治理意识、管道监控能力，在大模型时代同样值钱，甚至更值钱。

关键是要把传统大数据的经验用对地方：数据质量把控、权限隔离、可观测性设计，这些是 Demo 和生产的分水岭。

简历上不要只写"做了什么"，要写"解决了什么问题"和"带来了什么结果"。有数字、有细节、有业务价值的项目描述，比任何技术栈罗列都管用。

大模型应用正在从 Demo 走向生产，这个过程中真正稀缺的不是会调模型的人，而是能把整个系统跑稳、跑对、跑可观测的人。大数据工程师，就是这种人。

资料展示

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

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