企业官网建设流程全解析

如果你正准备往大模型方向转，《一个大数据项目改成 AI 流程后，最难的部分完全变了》这类问题别只看热度。更重要的是判断自己该补哪块能力，以及怎么证明你真的会。

摘要

最近半年，我和不少从大数据（BigData）转行做大模型工程（LLM Engineering）的朋友聊过。大家普遍有个误区：觉得只要把 ETL 流程换成 RAG 管道，或者把 Spark 作业改成 LangChain 编排，就能无缝切换赛道。

但现实很骨感。很多 Demo 跑起来丝般顺滑，一上生产环境，要么因为权限配置错误导致数据泄露，要么因为日志缺失根本查不到哪个 Token 在哪个环节卡死。

对于小团队或独立开发者来说，资源有限，盲目堆砌复杂的 Agent 架构往往是自杀。真正决定你能不能拿到 Offer、能不能让业务稳定运行的，不是你的 Prompt 写得有多花哨，而是你如何处理权限控制和可观测性。

这也是我今天想复盘的核心：从大数据到 AI，最难跨越的不是技术栈，而是工程思维的转变。

目录

• 交叉点：从“数据管道”到“意图管道”
• 数据治理：RAG 的基石，也是坑最深的地方
• 向量数据库：选型与取舍
• RAG 数据管道：从 ETL 到 ETL+L
• 落地项目：权限与可观测性的生死线
• 总结：从“数据搬运工”到“AI 架构师”

交叉点：从“数据管道”到“意图管道”

数据工程师熟悉的是确定性逻辑：输入 A，经过清洗、转换，输出 B。如果出错，报错日志是明确的。

但在 LLM 时代，输入是自然语言，输出是高概率的文本。不确定性带来了两个巨大的工程挑战：
1. 上下文窗口与成本：如何只传必要的数据给模型？
2. 执行边界：模型生成的代码或指令，能否直接执行？

在大数据里，我们习惯用 Hive/Spark 处理结构化数据。在 AI 工程里，我们需要处理非结构化数据和“行动”。很多转行者会陷入一个陷阱：过度关注模型选择（Qwen vs Llama vs Claude），却忽略了基础的数据治理和权限隔离。

我见过一个案例，某团队为了提升检索准确率，花两周时间微调 Embedding 模型，结果上线第一天因为未过滤敏感字段，导致 PII（个人身份信息）直接暴露给下游模型，被迫回滚。调优精度重要，但安全底线更致命。

数据治理：RAG 的基石，也是坑最深的地方

很多人认为 RAG（检索增强生成）就是往向量数据库里塞数据。错。如果源数据本身脏乱差，向量检索只会加速错误的传播。

在大数据领域，我们有 Data Quality Framework（数据质量框架）。在 AI 领域，这个概念同样适用，甚至更严格。

1. 切片（Chunking）不是随便切

不要直接用固定长度切分。我推荐基于语义边界的切分。比如 PDF 中的标题、表格前后。如果切碎了，检索回来的片段就失去了上下文意义。

2. 元数据过滤（Metadata Filtering）

这是大模型区别于传统搜索的关键。向量相似度只能解决“语义相关”，无法解决“事实权限”。

例如，用户问“我上个月的报销总额是多少？”
如果你的系统没有做权限隔离，模型可能会去检索全公司的报销数据，然后尝试汇总。这不仅慢，而且危险。

实战建议：
在存入向量数据库前，必须为每个 Chunk 打上明确的tenant_id（租户ID）、user_role（用户角色）和data_classification（数据密级）。检索时，先做元数据过滤，再做向量检索。这比你后期在 Prompt 里加“请不要透露其他公司数据”有效得多。

向量数据库：选型与取舍

不用纠结于最新出的向量数据库。对于大多数中小团队，现有关系型数据库配合 pgvector，或者成熟的 Milvus/Elasticsearch 完全够用。

关键指标只有三个：
1. 召回率：能不能找到相关的？
2. 延迟：响应时间在可接受范围内吗？
3. 运维成本：集群维护难度大不大？

我在项目中曾尝试引入复杂的 GraphRAG（图谱 RAG），初期效果惊艳，但随着数据量增长，图构建和维护的成本呈指数级上升，最终不得不回退到标准的 Vector RAG + 元数据过滤。技术选型要服务于 ROI（投资回报率），而不是为了炫技。

RAG 数据管道：从 ETL 到 ETL+L

传统的 ETL（Extract, Transform, Load）在 AI 场景下变成了 ETL+L（Load with Logic）。

这里有一个具体的代码片段，展示如何在 Python 中实现带有元数据过滤的简单 RAG 检索层。注意，我故意简化了错误处理，重点在于结构。

import chromadb from chromadb.config import Settings from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import Chroma class SecureRAGRetriever: def __init__(self, collection_name="enterprise_knowledge"): self.client = chromadb.Client(Settings(anonymized_telemetry=False)) self.embeddings = HuggingFaceEmbeddings(model_name="sentence-transformers/all-MiniLM-L6-v2") # 获取或创建集合 if not self.client.list_collections(): self.collection = self.client.create_collection( name=collection_name, metadata={"hnsw:space": "cosine"} ) else: self.collection = self.client.get_collection(name=collection_name) def retrieve(self, query: str, user_tenant_id: str, max_results: int = 5): """ 带租户隔离的检索 :param query: 用户问题 :param user_tenant_id: 当前用户所属租户 ID :param max_results: 返回结果数 """ try: # 关键步骤：使用 where 语句进行元数据预过滤 # 这一步在向量计算之前完成，大幅减少噪声并保证数据安全 results = self.collection.query( query_texts=[query], n_results=max_results, where={"tenant_id": user_tenant_id}, include=["documents", "metadatas"] ) return results['documents'][0] except Exception as e: # 在实际生产中，这里需要记录详细的 Trace ID print(f"Retrieval failed for tenant {user_tenant_id}: {e}") return [] # 使用示例 # retriever = SecureRAGRetriever() # docs = retriever.retrieve("查询2024年Q3财报", user_tenant_id="T_1001")

这段代码看似简单，但它体现了两个核心工程原则：
1. 防御性编程：明确指定tenant_id，防止越权访问。
2. 前置过滤：在昂贵的向量相似度计算前，先用索引过滤掉无关数据，降低延迟。

落地项目：权限与可观测性的生死线

这是我最想强调的部分。很多面试者能说出 Transformer 的原理，却说不清在生产环境中如何追踪一个 Agent 的调用链。

1. 权限最小化原则（Least Privilege）

不要让 LLM 拥有执行DROP TABLE或发送全员邮件的权限。

• 沙箱执行：所有由模型生成的代码或命令，必须在受限的沙箱中运行。
• 人工审批网关：对于高价值操作（如转账、删除数据），必须引入 Human-in-the-loop（人在回路），将审批权交给后端服务，而非依赖模型的自我约束。

2. 可观测性（Observability）

传统的日志是静态的，而 LLM 的交互是动态且随机的。你需要追踪：

• Trace ID：每一次用户请求，生成唯一的 Trace ID。
• Token 用量：记录每个环节的输入/输出 Token 数，用于成本核算和优化。
• 延迟分解：区分网络延迟、向量检索延迟、模型推理延迟和后处理延迟。

推荐使用 OpenTelemetry 标准来接入你的 LLM 应用。不要只打印print(response)，那在排查问题时毫无帮助。

总结：从“数据搬运工”到“AI 架构师”

大数据转大模型，本质上是职业角色的升级。

• 过去：你关注数据的完整性、一致性、吞吐量。
• 现在：你还要关注安全性、合规性、不确定性管理以及用户体验。

不要迷信那些炫酷的 Agent 框架。对于一个起步阶段的小团队或初级工程师来说，稳健优于智能，安全优于功能。

如果你想在简历上脱颖而出，不要只写“实现了 RAG 系统”，而要写：
> “设计并实施了基于元数据过滤的多租户 RAG 架构，通过前置权限校验将数据泄露风险降至零；引入 OpenTelemetry 全链路追踪，使生产环境故障定位时间从小时级缩短至分钟级。”

这才是企业真正需要的 AI 工程师。工具在变，但工程化的思维内核从未改变。守住底线，才能走得更远。

资料展示

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

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