聊《我用大数据经验做了次 AI 项目，最先失效的是旧方法》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

> 摘要：很多大数据开发者误以为转行 AI 就是学 Python 和 PyTorch，其实最大的鸿沟在于“确定性”与“概率性”的思维转换。本文复盘了一个从离线数仓转向实时 RAG 管道的项目，重点探讨在资源受限的小团队中，如何避开过度设计的陷阱，将重心从“模型调优”转移到“数据治理、权限控制与可观测性”这一真正决定上线成败的工程基石上。

---

目录

1. 思维断崖：当“ETL”遇到“非结构化”
2. 治理前移：别等 Embedding 了才后悔
3. 向量库不是银弹：选型与存储的取舍
4. RAG 管道的工程化：可观测性大于准确率
5. 落地建议：小团队的生存法则

---

思维断崖：当“ETL”遇到“非结构化”

在大厂做数据仓库时，我们的信条是“Garbage In, Garbage Out”，但通过严格的 Schema-on-Read 或 Schema-on-Write 机制，我们能保证输出给 BI 报表的数据是 100% 确定的。

然而，当我第一次接手公司内部的智能客服知识库项目时，这种安全感瞬间崩塌了。大模型（LLM）不是基于 SQL 聚合，而是基于概率生成。这意味着，你无法像写 GROUP BY 那样精确控制输出的每一个字。

最痛的领悟发生在上线第一周。业务方问：“为什么模型回答的引用来源和我们的文档对不上？”在传统数仓思维里，这是 Bug；但在 RAG（检索增强生成）架构里，这可能是语义匹配偏差导致的“幻觉”。

核心冲突点：大数据工程师擅长处理海量数据的“清洗与标准化”，而大模型工程要求处理高维向量的“相似性与上下文窗口”。前者追求极致的一致性，后者允许适度的模糊性以换取泛化能力。

如果你还抱着“先把数据清洗得干干净净再喂给模型”的老思路，大概率会陷入死胡同。因为 LLM 对噪声有一定的鲁棒性，但对结构破碎的信息极其敏感。

治理前移：别等 Embedding 了才后悔

在之前的项目中，我们曾犯过一个典型错误：试图把所有 PDF、Word 和图片里的 OCR 文本直接丢进 Chunker（分块器）。结果嵌入（Embedding）出来的向量质量极差，检索召回率不足 40%。

教训很具体：治理必须在切片之前完成，而不是之后。

对于非结构化数据，我总结了一套“最小可行性治理”流程，不再追求传统数仓那种“维度建模”的宏大叙事，而是聚焦于元数据丰富度：

1. 文档结构解析：不要只用正则切分。使用像 Unstructured 或 Marker 这样的工具，保留标题层级、表格结构。LLM 对层级信息非常敏感。
2. 元数据打标：在存入向量库前，务必提取业务属性（如：部门、生效日期、版本号）。这不仅是用来过滤，更是为了后续做“混合检索”。
3. 碎片化清理：删除页眉页脚、乱码字符。这些在向量空间中会产生极大的噪声。

这里有一个具体的代码片段，展示了如何在存入 ChromaDB 前，为每个 Chunk 添加必要的元数据：

def prepare_chunk_for_ingestion(raw_text, doc_metadata):
    """
    简单的数据清洗与元数据注入
    """
    import re

    # 1. 基础清洗：移除多余空白和非打印字符
    clean_text = re.sub(r'\s+', ' ', raw_text).strip()

    if not clean_text:
        return None

    # 2. 注入关键元数据，用于后续过滤
    enriched_metadata = {
        "source": doc_metadata.get("source_file"),
        "department": doc_metadata.get("dept_code"),
        "version": doc_metadata.get("doc_version", "latest"),
        "cleaned_len": len(clean_text), # 用于监控数据质量异常
        "chunk_type": doc_metadata.get("chunk_type", "text") # 区分表格或正文
    }

    return {
        "ids": [str(uuid.uuid4())],
        "documents": [clean_text],
        "metadatas": [enriched_metadata]
    }

注意，我没有在这里做复杂的 NLP 实体提取，因为在小团队初期，维护成本 > 精度收益。先保证有元数据可查，比做高精度的实体抽取更实际。

向量库不是银弹：选型与存储的取舍

很多转型者会纠结于 Milvus、Pinecone 还是 Qdrant。在我的实战中，结论很简单：取决于你的数据规模和并发需求，而不是算法的先进性。

如果数据量在百万级以下，且 QPS 不高，直接用 SQLite + 插件或轻量级的 Chroma/Pinecone 托管服务即可。不要为了几个查询请求去部署一套复杂的分布式 Milvus 集群，运维成本会吃掉你所有的创新空间。

但如果涉及企业级权限，情况就变了。

传统的 ETL 中，权限控制通常在应用层或 SQL 层。在 RAG 中，权限必须下沉到检索层。这就是为什么我在上面的代码块中强调 department 和 version 的重要性。

避坑指南：

• 不要只存向量：一定要存原文片段和原始元数据。
• 版本控制：文档更新后，旧版本的向量不能直接覆盖或删除，否则会导致历史会话引用断裂。我们需要一种“软删除+新版本插入”的策略，这在向量数据库中需要仔细设计索引。

RAG 管道的工程化：可观测性大于准确率

这是本文最想强调的观点，也是结合近期热点“从 Demo 转向可观测”的核心。

很多团队在 Demo 阶段，模型回答看起来挺聪明。一旦上线，用户反馈全是“胡说八道”或“答非所问”。问题往往不在于模型本身，而在于你不知道检索环节出了什么错。

在大数据领域，我们有 Data Lineage（数据血缘）。在大模型工程里，你需要构建 LLM Observability（大模型可观测性）。

一个简单的 RAG 链路包括：Query -> Retriever -> Context -> LLM -> Response。

你必须监控每一环：
1. 检索覆盖率：用户问的问题，到底有没有匹配到相关的 Chunk？如果没有，是向量库没索引，还是 Query 改写失败？
2. 上下文截断：召回的文档是否超过了 Token 限制？如果是，前端的 Prompt 是如何拼接的？
3. Token 成本与延迟：每次查询消耗了多少 Token？耗时多少？

我建议在项目中引入一个简单的日志追踪机制，记录每次对话的 Input, Retrieved Chunks, 和 Output。这样当业务方投诉时，你可以直接回放：“看，我们检索到了正确的文档，但模型因为上下文太长产生了幻觉。”

判断标准：如果你的团队无法快速定位一次错误回答是源于“检索不到”还是“生成瞎编”，那么这个系统就不具备生产环境价值。

落地建议：小团队的生存法则

作为大数据背景的技术人员，转型 AI 工程，我有三条具体的建议：

1. 停止追求 SOTA（State of the Art）模型：除非你有算力集群，否则 Llama-3-8B 或 Qwen-7B 这类开源小模型配合优秀的 Prompt 工程和 RAG，效果远好于盲目调用昂贵的 API。数据工程师的优势在于数据处理，而非模型训练。
2. 拥抱“脏数据”：不要花三个月整理完美的知识库。先用粗糙的数据跑通 Pipeline，建立反馈闭环。用户的纠错数据（Feedback Loop）才是提升模型表现的最快燃料。
3. 强化“后端”思维：大模型应用本质上是后端服务。重点放在鉴权、限流、缓存和日志上。一个稳定、可追踪、安全的 LLM 接口，比一个偶尔能写出诗歌的 Chatbot 更有商业价值。

总结

大数据转大模型，不是技术的替代，而是范式的迁移。从确定性的 SQL 聚合，转向概率性的语义检索。在这个过程中，保持对数据质量的敬畏，同时接受模型的不完美，并通过工程手段（元数据、可观测性、权限控制）来兜底，才是数据工程师进入 AI 时代的正确姿势。

别急着学 Transformer 的数学原理，先去把你的 ETL 管道改造成能吞吐非结构化数据的 RAG Pipeline，这才是当下最紧迫的实战。

总结

本文完成了关键概念、工程实践和落地建议的梳理。

资料展示

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

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