接了个 RAG 项目才醒悟：大数据工程师进 AI 最大的坑不是模型是权限和日志

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

摘要

摘要：从 Hadoop/Spark 转到大模型工程，很多人以为技能断层在 Python 或向量检索上。真正让团队项目翻车的，是权限控制、调用日志、可观测链路这些"老本行该会但没人教"的工程细节。本文结合一次团队 RAG 落地复盘，拆清楚数据工程师转型时最容易忽视的三条硬坎，并给出可以直接复用的排查和实现路径。

---

目录

• 1. 大数据和大模型的交叉点到底在哪
• 2. 数据治理：从 Hive 到 LLM 的一条暗线
• 3. 向量数据库：我踩过的那几个坑
• 4. RAG 数据管道：权限和日志才是真正的上线门槛
• 5. 落地项目实战复盘
• 6. 总结

---

1. 大数据与大模型的交叉点到底在哪

说实话，刚开始我觉得转型大模型就是换个语言写代码。Spark 熟 Python 不熟？学一周够用。向量检索不懂？Milvus 文档看两天就会了。

后来接手一个团队项目，Demo 跑通没问题，上线第一天崩了。领导问我一句："用户 A 能看到用户 B 的数据吗？"

我愣住。

这个项目的权限体系完全空白——数据层用的是共享集群账号，应用层没做租户隔离，日志里只有 LLM 调用的 token 数，没有任何业务上下文。说白了，我带着大数据时代的"数据管道思维"进去了，但漏掉了大数据时代同样要求、只是习惯用 Hadoop/Spark 框架隐式保证的东西：权限、审计、可观测。

大数据和大模型的交叉点，不是算法，而是工程化。你把离线数仓的治理思路搬过来，反而比纯 AI 背景的人更有优势——你只是需要先认清：LLM 系统的治理逻辑和传统数仓不完全一样。

---

2. 数据治理：从 Hive 到 LLM 的一条暗线

数据治理是数据工程师的基本功。从 Hive 表生命周期管理到数据质量监控，这套能力在大模型项目里没有消失，只是换了对象。

传统数仓治理的对象是结构化数据，核心关注点是准确性、完整性、一致性。LLM 系统的治理对象增加了三类：

1. Prompt 模板版本：一个提示词改动可能导致输出质量剧烈波动，但没有 changelog
2. Embedding 模型版本：切换 embedding 模型会让现有向量库全部失效，需要重新索引
3. RAG 知识库更新时效：知识入库时间和问题回答时间之间的 gap 是什么

我做的那个项目，原始需求是把企业内部操作手册接入 RAG。手册存放在一个 HDFS 路径下，按日期分区。我用 Spark 做了清洗和分块，这块和传统 ETL 没什么区别。

真正出问题的是后面的事——手册每个月更新一次，旧版本怎么处置？向量库里的旧 chunk 没有 TTL 机制，查询结果里混入了已废弃的操作步骤，而日志里没有标记哪条 chunk 对应哪个版本。

经验：如果你之前做过数据血缘追踪，把这套思路用在 RAG chunk 上会非常顺手。每个 chunk 记录 sourcepath、version、updatetime、embedding_model，这三张表在 RAG 查询时做 JOIN 过滤，就能解决版本追溯问题。这和你在数仓里做 slowly changing dimension 是同一套思维。

---

3. 向量数据库：我踩过的那几个坑

向量数据库选型上，我最初选了 Milvus，因为团队有现成的集群资源。但实际上，这个项目用不上 Milvus 的分布式特性——数据量级不到百万，查询延迟要求 200ms 以内。

真正踩的坑不是选型，是分块策略。

第一个坑：chunk 大小直接照搬了论文里的 512 token。结果检索召回率很低，因为一个完整的操作步骤被拆到了两个 chunk 里，用户问"如何重置密码"时只召回了前半段。

第二个坑：没有做 chunk 之间的元数据关联。修复方式是给每个 chunk 加一个 parent_id 字段，查询时先召回 parent document，再展开相关子 chunk。

第三个坑更隐蔽：嵌入向量本身没有校验。我第一次上线后，发现某些特殊格式的文本（比如代码块里的特殊字符）生成的 embedding 质量明显偏差，但日志里完全没有报错——embedding 接口正常返回了向量，只是向量本身是"垃圾进垃圾出"。

排查过程如下：

现象：部分用户反馈回答质量下降，但整体 recall@5 指标没有明显变化。

验证动作：手动选取 50 条低质量回答的查询，反向追踪对应的 chunk ID，检查这些 chunk 的原始文本。发现其中 12 条 chunk 包含未处理的 HTML 标签和乱码字符。

排除结果：不是 embedding 模型的问题，是预处理阶段对特殊格式文本的处理不完整。在 Spark 清洗阶段加了 HTML 标签剥离和 Unicode 规范化步骤后，召回质量恢复。

这个案例说明：向量数据库不是黑盒，检索质量取决于你的文本预处理流水线，而这个流水线正是大数据工程师最擅长的部分。

---

4. RAG 数据管道：权限和日志才是真正的上线门槛

这是本文最想讲的部分。Demo 阶段我们通常只关注：查询 → 检索 → 生成 → 回答。但上线后，真正决定项目能不能交付的，是三件事：权限、日志、可观测。

权限

我的项目一开始用的是服务账号直连向量库和 LLM API。任何能访问服务的应用都可以查询任意知识库。上线前审计被发现：不同部门的员工可以通过同一个接口查询到跨部门的操作手册。

解决方案是在查询入口处加一层租户隔离。具体做法是在请求头里携带 tenantid，然后在向量查询的 filter 条件里加上 tenantid 字段：

# 核心查询逻辑，带租户隔离
def query_rag(query: str, tenant_id: str, user_role: str) -> dict:
    # 1. 校验租户权限
    if not access_control.check(tenant_id, user_role, "rag_query"):
        raise PermissionError(f"tenant={tenant_id} not authorized")

    # 2. 构建带过滤条件的向量查询
    vector = embedding_model.encode(query)
    results = vector_db.search(
        vector=vector,
        filter={"tenant_id": tenant_id},  # 关键：租户隔离
        top_k=5
    )

    # 3. 组装 prompt 并调用 LLM
    context = "\n".join([r.text for r in results])
    response = llm.chat(
        messages=[{"role": "user", "content": f"{query}\n\n{context}"}],
        extra={"tenant_id": tenant_id, "query_id": generate_query_id()}
    )

    return {
        "answer": response.text,
        "sources": [{"chunk_id": r.id, "score": r.score} for r in results],
        "query_id": response.metadata.get("query_id")
    }

关键代码解释：

• 第一层 access_control.check：这是鉴权拦截器，输入是租户 ID 和用户角色，输出是布尔值。它依赖一个预定义的权限映射表，类似 RBAC 模型。如果这里没有校验，后面所有步骤都是空谈。
• filter={"tenant_id": tenant_id}：这是向量查询的过滤条件。很多教程不讲这点——Milvus 和 pgvector 都支持在查询时加 metadata filter，这个 filter 是租户隔离的关键。不加这个 filter，默认就是全库查询。
• extra 参数传递 tenant_id：这是给 LLM 调用方（或后续日志系统）使用的上下文，不参与检索逻辑，但会在 trace 日志里出现，方便后续审计。

日志

传统数仓的日志是事件流，按天分区存储。LLM 系统的日志是请求-响应链，需要记录：查询 ID、租户、用户、输入文本、检索结果（chunk IDs 和 scores）、LLM 调用耗时、token 用量、生成内容摘要、错误码。

我的项目最开始只记录了 LLM 调用的耗时和 token 数。排查问题时完全无法定位——不知道某次慢查询是因为检索阶段耗时还是生成阶段耗时，也不知道是哪个租户、哪类问题触发的。

后来补全了日志结构，核心字段如下：

# 日志记录逻辑
def log_request(query_id: str, tenant_id: str, user_id: str,
                query_text: str, search_results: list,
                llm_stats: dict, response: str, error: str = None):
    log_entry = {
        "query_id": query_id,
        "timestamp": datetime.utcnow().isoformat(),
        "tenant_id": tenant_id,
        "user_id": user_id,
        "query_text_hash": hashlib.sha256(query_text.encode()).hexdigest(),
        "search_time_ms": search_results[0].meta.get("elapsed_ms"),
        "search_chunk_ids": [r.id for r in search_results],
        "llm_tokens_input": llm_stats["input_tokens"],
        "llm_tokens_output": llm_stats["output_tokens"],
        "llm_latency_ms": llm_stats["latency_ms"],
        "response_fingerprint": hashlib.md5(response.encode()).hexdigest()[:16],
        "error_code": error
    }
    # 写入 Kafka topic，供下游 Flink 实时处理
    producer.send("rag_request_log", value=json.dumps(log_entry))

这个日志结构的设计原则是：不存原文，只存哈希和指纹。原因有两个：一是隐私合规，二是存储成本。query_text 和 response 都经过哈希处理，但保留了足够的信息用于去重和异常检测。

可观测

可观测性不是监控大盘，而是问题定位能力。我的项目上线两周后，运维报警说响应时间从 800ms 涨到了 3s。没有 trace 链路的情况下，花了半天才定位到是向量库的索引参数被误改了——原来是运维同事在做集群扩容时改错了 configmap。

如果有完整的 trace_id 贯穿"HTTP 请求 → 检索 → Embedding → LLM 调用"全流程，这个排查时间可以从半天缩短到几分钟。

---

5. 落地项目实战复盘

把这个项目完整复盘一遍，最有价值的不是技术选型，而是决策判断。

输入：企业内部操作手册（HDFS 存储，约 200 万 word，15 个部门，每月更新）

步骤：
1. Spark 清洗分块（chunksize=300, overlap=50），增加 metadata：tenantid、docversion、updatetime
2. Embedding 向量化（BGE-M3，dim=1024）
3. 写入 Milvus，collection 级别按 tenant_id 分区
4. 查询入口加租户鉴权和 query_id 注入
5. 日志写入 Kafka，Flink 实时聚合 + Spark 离线归档
6. 接口增加 health_check 端点，监控 embedding 和 LLM 服务的可用性

可观察结果：

• 上线首周，发现 3 起跨租户查询泄漏（已通过权限拦截器拦截并告警）
• 通过日志分析定位到 2 个低质量检索案例，原因是 chunk 边界切割不当，修复后 recall 提升约 12%
• LLM 调用平均耗时从 3.2s 优化到 1.8s，原因是缓存命中了 30% 的重复查询

失败原因分析：

| 类别 | 具体错误 | 根因 |
|------|---------|------|
| 配置错误 | 向量库 filter 未生效 | milvus 集合创建时没声明 tenant_id 为 indexed 字段 |
| 环境错误 | Embedding 服务 OOM | 批处理 batch_size 设置过大，生产环境内存比开发环境少一半 |
| 业务错误 | 检索结果混入过期知识 | 知识库更新时没有删除旧 chunk，导致 stale data 参与检索 |

区分这三类错误的方法很简单：配置错误改一下参数就恢复；环境错误换个配置或扩容就能解决；业务错误需要改数据或逻辑。我最初把这三种错误全混在一起排查，浪费了将近一天。

---

6. 总结

大数据工程师转大模型，技术栈上的 gap 其实不大。Python、PyTorch、向量检索这些，补一补就能上手。真正拉开差距的是工程化能力——权限、日志、可观测，这些在大模型项目里不是锦上添花，而是上线的前置条件。

如果你正在考虑转型，建议按照这个顺序准备：

1. 先用一个完整的 RAG 项目跑通全流程，不要停在 Demo
2. 主动给项目加上租户隔离和请求日志，哪怕只是写到本地文件
3. 学会用 trace_id 串联一个请求的全链路，这是排查问题的核心能力
4. 了解大模型服务的常见故障模式（超时、限流、模型降级），这和 Hadoop 集群的故障排查思路是一样的

大数据教会我们的是处理大规模数据的纪律，大模型项目需要的也是同样的纪律——只是数据对象从结构化表变成了非结构化文本，从精确匹配变成了语义匹配。底层思维没有变。

---

适用边界：本文的案例基于 Milvus + BGE-M3 + 自研鉴权中间件的技术栈，适用于中等规模（百万级 chunk）的企业内部知识库场景。如果你的场景是超大规模（亿级 chunk）或需要多租户隔离，建议直接使用成熟向量库的原生 RBAC 能力而非自建。另外，本文的日志方案侧重审计追溯，如果侧重视实时的性能监控，需要额外接入 Prometheus + Grafana 指标体系。

总结

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

资料展示

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

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