聊《一个大数据项目改成 AI 流程后最难的部分完全变了》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要大数据工程师转型大模型大多数人以为卡点在学习 Python 或者调参实际翻车的环节往往是权限校验、日志追踪、数据溯源这些脏活。本文结合一个真实项目复盘讲清楚数据工程师做 RAG 和 Agent 时的真正门槛在哪以及怎么补。---目录大数据与大模型的根本差异数据治理从离线批处理到实时可溯源向量数据库不是换个存数据的工具RAG 数据管道最容易低估的工程环节落地项目权限和日志才是生产上线的生死线总结---大数据与大模型的根本差异做大数据的人第一反应是大模型不就是换个模型吗数据该清洗还是清洗。这个思路在 Demo 阶段没问题一上生产就露馅。大数据的核心假设是数据稳定、结构清晰、写入一次反复读。Hive 表建好ETL 跑通调度配好基本就稳了。大模型工程的核心假设恰恰相反数据在变、答案在变、每次请求的上下文都不一样。我带的第一个 AI 项目是给内部知识库做问答系统。数据组的同学花两周把文档全部向量化RAG 流程也跑通了Demo 演示效果很好。然后业务方提了一个问题 不同部门的人问同一个文档答案能不一样吗比如销售能看客户信息客服不能。这一下就把我们打懵了。传统大数据的权限体系是表级或行级的静态的。而 RAG 系统的权限是在检索阶段动态过滤的需要把权限元数据和向量一起存、一起查。这才是大数据工程师转型时最容易被低估的地方你不是在换技术栈你是在换一套问题建模方式。---数据治理从离线批处理到实时可溯源大数据的数据治理重点是质量、血缘、一致性。这些在大模型场景下依然存在但增加了一个新的维度来源可溯源。传统 ETL 链路原始日志 → Kafka → Hive → 数仓ODS/DWD/ADS → 报表血缘是线性的出了问题可以追到某张表的某个字段。RAG 链路原始文档 → 清洗 → 分块 → 向量化 → 向量库 → 检索 → LLM 生成问题出在生成结果不对时你需要知道这条答案是从哪几段文档来的每段文档的原始来源是什么向量库里的数据是今天更新的还是上周的我在项目里搭了一套简单的溯源方案核心思路是把元数据跟着向量一起存# 向量化时带上元数据 from langchain_community.vectorstores import Chroma from langchain_core.documents import Document def embed_with_metadata(texts, sources, permissions): docs [] for text, source, perm in zip(texts, sources, permissions): docs.append(Document( page_contenttext, metadata{ source: source, permission_level: perm, updated_at: datetime.now().isoformat(), chunk_id: f{source}_{len(docs)} } )) return docs # 检索时按权限过滤 def search_with_permission(query, user_level, top_k5): results vector_db.similarity_search_with_score(query, ktop_k * 2) filtered [ (doc, score) for doc, score in results if doc.metadata[permission_level] user_level ] return filtered[:top_k]看起来简单但有几个实际踩过的坑第一元数据不能太大。 每条向量都带一堆 metadata向量库查询性能会明显下降。我们最初把所有文档属性都塞进去QPS 直接掉了一半后来只保留 source、permissionlevel、chunkid 三个字段才恢复正常。第二权限模型要提前设计。 不是等做出来了再加权限而是在设计文档入库流程时就定义好权限层级。我们最终采用了文档级权限 字段级权限的混合方案前者控制能不能看后者控制能看到多少。第三数据过期要处理。 大模型场景下文档可能今天更新了但向量库里还是旧版本。我们加了updated_at字段配合定时任务做增量更新同时记录每次更新的版本号方便排查问题。---向量数据库不是换个存数据的工具很多大数据工程师第一次接触向量数据库第一反应是这不就是个带索引的 NoSQL 吗确实有点像但关键区别在于查询语义完全不同。传统数据库你按条件过滤结果确定。向量数据库你按相似度检索结果是概率性的。这意味着同样的查询不同时间可能返回不同结果——因为模型embedding在更新、数据在增量写入。我们项目里对比了三个方案Chroma本地开发用、Milvus生产部署、PGVector想用现成PostgreSQL基础设施时用。最终选了 Milvus原因很实际Chroma 并发能力不够压测 50 个并发就扛不住了PGVector 查询延迟波动大p99 能达到 2 秒Milvus 在 QPS 和延迟上表现最稳定但选型只是第一步索引策略才是关键。Milvus 支持 IVFFLAT、HNSW、IVFSQ8 等多种索引我们最初用默认的 IVF_FLAT召回率 92%但查询延迟 300ms。换成 HNSW 之后延迟降到 80ms召回率 89%。取舍很明确延迟优先还是召回率优先 对于内部知识库场景我们选择了后者——用户能接受 100ms 左右的延迟但不能接受漏掉关键文档。另一个容易被忽视的点批量写入 vs 实时写入。我们最初每条文档来了就写入向量库结果写入延迟越来越高因为每次写入都会触发索引重建。后来改成批量写入每小时一次延迟问题消失但引入了一个新的权衡数据延迟最多 1 小时。这个权衡是否可接受需要根据业务场景判断。---RAG 数据管道最容易低估的工程环节RAG pipeline 看起来很简单用户问题 → 检索相关文档 → 拼接上下文 → 调用LLM → 返回答案但生产环境里每个环节都有大量工程问题要解决。检索环节我们最初直接用相似度检索结果发现一个问题——文档里有些章节明显更相关但向量相似度打分把它们和无关章节混在一起了。后来加了重排序rerank步骤用 Cross-Encoder 模型对初步检索结果重新打分效果明显提升。拼接环节上下文长度是个硬约束。我们最初把所有检索结果全塞进去结果经常超出 token 限制。后来做了两段式处理先粗筛取 top 20再用 LLM 做摘要压缩到 top 5 的核心段落。调用环节这是最容易被忽视的。一个 RAG 系统不是单次调用而是多次调用的组合——检索一次、rerank 一次、生成一次。任何一步超时或失败整个流程都要有兜底。from opentelemetry import trace from opentelemetry.trace import SpanKind import time tracer trace.get_tracer(__name__) def rag_pipeline(query, user_id): with tracer.start_as_current_span(rag_pipeline) as span: span.set_attribute(user_id, user_id) span.set_attribute(query, query[:100]) start time.time() # 检索 docs search_with_permission(query, get_user_level(user_id)) span.add_event(search_done, {count: len(docs), latency_ms: (time.time()-start)*1000}) if not docs: return {answer: 未找到相关文档, sources: []} # 重排序 start time.time() reranked rerank(query, docs, top_k5) span.add_event(rerank_done, {latency_ms: (time.time()-start)*1000}) # 生成 start time.time() context build_context(reranked) answer call_llm(query, context) span.add_event(generate_done, { latency_ms: (time.time()-start)*1000, tokens_used: len(answer) }) return {answer: answer, sources: [d.metadata[source] for d in reranked]}这套链路里可观测性不是锦上添花是必须的。没有 trace你不知道慢在哪一步没有日志你无法复现问题没有指标你不知道系统是否健康。我们后来接入了 Prometheus Grafana监控的关键指标就几个端到端延迟p50/p95/p99各阶段延迟占比检索召回率通过人工抽样评估LLM 调用失败率单位成本每次查询的 token 消耗---落地项目权限和日志才是生产上线的生死线这个项目做了三个月前两个月都在做 Demo看起来一切顺利。第三个月接入生产才真正发现问题。第一个问题权限绕过。 我们以为做了向量级权限过滤就万事大吉结果发现有用户通过拼接多个问题的方式绕过了权限限制。比如用户 A 不能看文档 X但他可以问文档 X 里关于 Y 的内容是什么系统检索到 X 的片段后虽然没有直接返回原文但通过 LLM 的重新组织还是把敏感信息泄露了。解决方案在 LLM 输出端加了一道内容过滤检测是否包含敏感关键词同时限制单次查询的上下文长度减少信息泄露的可能。第二个问题日志缺失。 我们最初只记录了查询和结果没有记录中间过程。有一天用户反馈答案不对我们查日志发现检索到了正确的文档但 LLM 没有引用。因为没有记录 rerank 的结果和 LLM 的完整输入我们花了半天时间才定位到是 rerank 模型把正确结果排到了后面。解决方案记录完整的链路日志包括每次检索的结果、rerank 的打分、LLM 的输入输出。虽然日志量变大了但排查问题的效率提升了几个数量级。第三个问题成本失控。 我们最初没有监控 token 消耗结果一个月下来 LLM 调用费用超出预算三倍。排查发现很多查询是重复的但没有做缓存。解决方案加了一层结果缓存相同问题的查询直接返回缓存结果。同时设置了单次查询的 token 上限和每日调用上限。---总结大数据工程师转型大模型最大的误区是以为技术栈切换就够了。实际上真正的门槛在工程化能力权限设计、日志追踪、成本管控、可观测性。这些在大数据领域你可能接触不多但在大模型生产环境里它们是决定项目能不能上线的关键因素。建议的学习顺序1. 先搞懂 RAG 的基本原理和常见陷阱2. 动手做一个完整的 RAG 项目包括检索、重排序、生成3. 给项目加上权限控制和日志追踪4. 压测看延迟、召回率、成本的平衡点在哪5. 复盘如果这个系统要服务 1000 个并发用户哪里会先崩Demo 能跑只是开始权限、日志、可观测性才是真正的分水岭。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。