跨越大数据到大模型：小团队做 RAG，为什么我劝数据工程师先盯权限？-优快云博客

聊《别急着换赛道：大数据经验在 AI 项目里到底值多少？》之前，先说一句实在的：别急着背概念，先看它在真实项目里到底解决什么问题。

摘要

很多数据工程师切入大模型项目时，容易一头扎进 Prompt 调优或复杂 Agent 编排。但实际交付时，真正卡住业务的往往是数据权限隔离、调用链路可观测性和生产环境稳定性。本文结合一次内部 RAG 系统重构经历，聊聊如何利用大数据工程经验平滑过渡，并在资源有限的小团队中避开过度设计，把精力集中在权限管控与全链路日志上。

以前做数仓，我习惯先拉满 Spark 任务，跑完 ETL 再看报表。现在切到 LLM 工程，很多同行还是带着这套惯性：先搞个 LangChain 跑通 Demo，再慢慢补工程化。结果往往是 Prompt 调了半个月，一上生产就被业务方砍掉——因为不知道用户问的“本月营收”到底能不能看，或者出了幻觉连排查都找不到根因。

大数据和大模型的交叉点从来不在算法层，而在工程层。你过去熟悉的分布式计算、数据血缘、元数据管理，其实都能平移。只是现在的“数据”变成了非结构化文本，处理单元从 GB/TB 降到了 KB/token，但“谁来读、读什么、怎么留痕”的逻辑没变。小团队资源就那么多，与其去卷开源模型微调，不如先把数据访问的边界划清楚。

数据治理：从清洗字段到管控权限

数据治理这词儿现在被说烂了，但在 AI 场景下，它直接等同于权限控制。传统数仓里，行级权限（Row-Level Security）和列级脱敏是标配。到了 RAG 架构里，如果文档不带上 tenant_id 或 user_role 标签，大模型就会毫无边界地吐出所有信息。

我之前带过一个客服知识库项目，初期直接用向量库存切片文档，检索时只靠语义相似度。测试环境跑得飞起，业务方一验收就傻眼：销售能看到竞对报价单，外包人员也能查到底层成本结构。后来我们没搞复杂的 RBAC 引擎，而是直接在数据入库阶段加了一层 metadata 过滤。写入向量库前，强制拼接权限标签；查询时，通过提示词注入 + 向量检索联合过滤。代码大概长这样：


# 入库时注入权限元数据
def prepare_document_chunk(text, user_role, doc_tenant):
    chunk_meta = {
        "role_filter": user_role,      # e.g., "manager", "agent"
        "tenant_id": doc_tenant,       # e.g., "sales_dept"
        "source": "internal_wiki"
    }
    return text, chunk_meta

# 检索时动态拼接过滤条件
def build_retrieval_query(query, current_user_role):
    base_prompt = f"请基于以下上下文回答问题。注意：当前用户角色为 [{current_user_role}]，仅返回该角色可见的信息。\n"

![优快云资料领取方式](https://i-blog.csdnimg.cn/direct/c1407c3b630f48fd93772070c1e239d9.jpeg)

    return base_prompt + query

别小看这段逻辑。它解决的不是多高深的算法，而是生产环境里最直接的合规问题。数据工程师做权限控制有天然优势：你熟悉数据分级分类，知道哪些字段能泛化、哪些必须硬拦截。把这些经验用到 LLM 的 prompt 工程和检索策略里，比盲目追求“通用权限中间件”靠谱得多。

向量数据库：小团队的取舍逻辑

聊完权限，很多人会接着问向量数据库怎么选。市面上 Milvus、Chroma、Qdrant 甚至 PGVector 都在争宠。对于资源有限的小团队，我的建议非常直接：别碰分布式集群，除非你的日增向量突破千万级且 QPS 要求稳定在三位数。

早期我也踩过坑，为了“高可用”硬上 Milvus 双副本，结果运维成本直接拖垮了开发进度。后来改用 PostgreSQL + pgvector，配合简单的读写分离，加上 Redis 做热点检索缓存，支撑几万日活完全够用。向量库本质是个带语义索引的存储引擎，它的核心价值是“快”和“准”。选型的判断标准只有两个：第一，是否支持自定义 metadata 过滤（前面权限管控就靠这个）；第二，生态是否跟得上你的技术栈。Java/Python 混用的团队，优先选语言 SDK 成熟、社区活跃的；如果团队本身就有 Postgres 运维能力，直接上 pgvector 是最省心的路径。过度追求性能指标，往往会在部署和联调上浪费大量时间。

RAG 数据管道：Demo 到生产的生死线

数据治理和存储搞定后，就到了最折磨人的 RAG 管道。这里我想重点提一下日志和可观测性。Demo 阶段大家喜欢看 LLM 吐出的最终答案，但生产环境里，答案错了只是表象。真正要命的是：召回了什么？Prompt 拼对了没？Token 消耗在哪里？有没有触发安全拦截？

我以前做批处理任务，丢数据可以重跑。但 LLM 是非确定性的，同一个问题问两次，回答可能完全不同。如果不记录完整的推理轨迹（Trace），排查问题就像盲人摸象。我们后来在管道里埋了三个关键日志节点：
1. query_rewrite_log：记录用户原话和经过意图识别后的改写结果。
2. retrieval_context_log：不仅存 Top-K 的文本，还要存对应的 doc_id 和相似度分数，方便回溯召回质量。
3. model_inference_log：完整保存 prompt 模板变量替换后的内容、模型返回的 raw json、以及耗时。

这些日志不需要上昂贵的 APM 平台，用 ELK 或者甚至本地 JSON 文件按天切分都行。关键是结构化。每次模型输出异常，直接按 trace_id 捞日志，半小时内就能定位是召回噪声太大，还是系统提示词冲突。小团队做可观测性，切忌追求全链路监控的“大而全”，抓住这三个核心节点，足够应对 90% 的线上故障。

落地建议与学习路线

从大数据转到 AI 工程，简历和项目展示上该怎么写？我见过太多同行把精力花在网上抄写的开源项目复现上。面试官一看：“这个 RAG 项目 GitHub 上有三百多个版本”，直接 pass。

我的建议是突出“工程约束下的取舍”。不要只写“使用了框架实现了问答系统”，要写清楚：在日均请求 5000 次的场景下，如何通过元数据过滤将越权请求拦截率降至 0.1%；如何通过精简检索逻辑，将 P95 延迟压到 800ms 以内；遇到长文档解析乱码问题时，是如何结合 OCR 和后处理规则兜底的。技术栈可以泛，但业务边界和性能指标必须具体。

学习路线也别贪多。第一步，先把 Python 异步编程和基础 HTTP 框架玩转，LLM 工程绝大多数场景都在做 I/O 密集型的流式传输和并发控制。第二步，吃透向量检索和重排序的基本原理，知道什么时候该用 BM25 召回，什么时候该上 Cross-Encoder。第三步，重点研究 Prompt 工程和日志埋点。至于模型微调，除非你有明确的垂直领域标注数据和算力预算，否则现阶段 95% 的业务用 Prompt + RAG 就能解决。

总结

大数据转大模型，不是换个赛道，而是换了一套处理数据的工具链。过去你守护的是数仓里的表和字段，现在你守护的是模型调用的上下文和边界。小团队做 AI 应用，最大的敌人不是技术难度，而是过度设计和对工程底座的轻视。把权限控制做扎实，把日志可观测做成习惯，哪怕用最基础的开源组件，也能跑出一个能真正替业务扛流量的系统。别急着卷智能体编排，

文章插图 1