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

摘要

摘要：去年帮一家电商公司做内部知识库问答系统，从数据仓库直接接手，代码写得飞快，demo 跑起来效果很好。结果上线第一天就崩了——权限没控住、日志没接好、调用链断了。这篇文章复盘这个项目，聊聊大数据工程师转大模型时的优势、容易忽视的坑，以及小团队怎么避免过度设计。

---

目录

• 大数据和大模型，到底哪里交叉
• 数据治理：大模型项目最容易被低估的环节
• 向量数据库选型：别被概念带着走
• RAG 数据管道：从代码到可观测
• 落地项目：电商客服机器人的一天
• 排查过程：权限和日志的噩梦
• 失败原因：业务错误、配置错误、环境错误怎么区分
• 适用边界：什么时候该照搬，什么时候该取舍
• 总结

---

目录

• 大数据和大模型，到底哪里交叉
• 数据治理：大模型项目最容易被低估的环节
• 向量数据库选型：别被概念带着走
• RAG 数据管道：从代码到可观测
• 落地项目：电商客服机器人的一天
• 排查过程：权限和日志的噩梦
• 失败原因：业务错误、配置错误、环境错误怎么区分
• 适用边界：什么时候该照搬，什么时候该取舍
• 总结

大数据和大模型，到底哪里交叉

很多人觉得大数据工程师转大模型要重新学一套东西，其实不然。

我做大数据这些年，核心工作就三件事：数据从哪里来、数据怎么清洗、数据怎么保证质量。大模型项目，尤其是 RAG 方向，本质上也是这三件事，只是输入输出换了。

数据从哪里来——以前是 Kafka、Hive、数据仓库，现在是网页、PDF、数据库、API。
数据怎么清洗——以前是 ETL 脚本，现在是文档解析、分块、去重、向量化。
数据怎么保证质量——以前是数据质量监控，现在是检索准确率、生成质量、幻觉率。

我接手这个电商项目的时候，团队里有两个做 Spark 的，一个做数仓的。他们上手 LangChain 和向量数据库的速度比我想象的快，因为分块策略、索引构建、数据质量校验这些思路是通的。

但问题也出在这里——他们太习惯"数据 pipeline 跑通就完事了"的思维。大模型项目不是这样。demo 跑通只是开始，权限、日志、可观测、成本，这些在大数据项目里你可能不碰，但在大模型项目里是生死线。

---

数据治理：大模型项目最容易被低估的环节

这个项目的核心需求是：客服机器人能回答商品相关的常见问题，比如发货时间、退换货政策、优惠券使用规则。

数据源来自三个地方：商品详情页、客服工单记录、内部文档（PDF 和 Word）。

大数据工程师做数据治理的直觉很自然——先搞清楚数据质量。但大模型项目的数据治理和普通 ETL 不一样。

普通 ETL：脏数据可以过滤、补全、标记，最终输出结构化表。
大模型数据治理：脏数据会直接污染检索结果，导致模型胡说八道。而且大模型对数据的"语义质量"要求更高——同样的内容，分块方式不同，检索效果可能差几倍。

我们踩的第一个坑是文档解析。客服工单是 PDF，有些是扫描件。直接用 PyPDF2 解析，OCR 效果很差，检索的时候关键词匹配不上。后来换成 OCR + LLM 联合处理，先把图片转文字，再用大模型做结构化提取，效果才上去。

# 文档解析和分块的核心逻辑
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.document_loaders import PyPDFLoader, Docx2txtLoader

def load_and_chunk(file_path: str, chunk_size: int = 500, chunk_overlap: int = 50):
    """加载文档并按递归方式分块"""
    if file_path.endswith('.pdf'):
        loader = PyPDFLoader(file_path)
    elif file_path.endswith('.docx'):
        loader = Docx2txtLoader(file_path)
    else:
        raise ValueError(f"不支持的文件格式: {file_path}")

    documents = loader.load()

    # 递归分块：优先在标题、段落边界切分
    splitter = RecursiveCharacterTextSplitter(
        chunk_size=chunk_size,
        chunk_overlap=chunk_overlap,
        separators=["\n\n", "\n", "。", " ", ""]
    )
    chunks = splitter.split_documents(documents)

    # 给每个分块加元数据，方便后续过滤和追溯
    for chunk in chunks:
        chunk.metadata["source"] = file_path
        chunk.metadata["chunk_size"] = len(chunk.page_content)

    return chunks

代码解释：

• 输入：文件路径，chunksize 默认 500 字符，chunkoverlap 默认 50 字符
• 核心逻辑：根据文件类型选择加载器，然后用 RecursiveCharacterTextSplitter 递归分块。separators 的优先级从高到低，优先在段落边界切，避免切断语义
• 输出：带元数据的文档列表，source 记录来源文件，chunk_size 记录分块大小
• 异常处理：不支持的文件类型直接抛 ValueError，避免后续静默失败

这个分块策略不是通用的。电商文档的特点是段落清晰、有标题层级，所以 RecursiveCharacterTextSplitter 效果不错。但如果数据是代码、表格、或者连续长文本，可能需要换策略，比如按 HTML 标签分块、按表格单元格分块。

---

向量数据库选型：别被概念带着走

向量数据库选型是大模型项目里最容易过度设计的地方。

市面上有 Milvus、Pinecone、Chroma、Weaviate、pgvector……每个都说自己好。我见过太多团队一开始就上 Milvus 集群，后来发现根本用不到那么多功能，运维成本反而成了负担。

小团队选向量数据库，核心看三点：
1. 能不能跑在现有基础设施上——如果公司有 PostgreSQL，pgvector 是最省事的，不用额外部署
2. 检索性能够不够——百万级向量，毫秒级响应，pgvector 加 HNSW 索引完全够用
3. 和现有生态能不能打通——LangChain 支持的所有向量库都能用，但有些集成本身就有坑

我们这个项目一开始想用 Milvus，因为听说性能最好。后来发现团队没人维护过 Milvus 集群，运维成本太高。最后选了 pgvector，部署在已有的 PostgreSQL 上，检索延迟 20ms 以内，完全够用。

# pgvector 初始化和本地检索示例
from langchain.vectorstores import PGVector
from langchain.embeddings import OpenAIEmbeddings
from sqlalchemy import create_engine

# 连接已有的 PostgreSQL
CONNECTION_STRING = PGVector.connection_string_from_db_params(
    driver="psycopg2",
    host="localhost",
    port=5432,
    database="knowledge_base",
    user="db_user",
    password="db_password"
)

# 初始化向量存储，embedding 用 OpenAI 的 text-embedding-ada-002
embeddings = OpenAIEmbeddings(model="text-embedding-ada-002")
vectorstore = PGVector(
    embeddings=embeddings,
    connection_string=CONNECTION_STRING,
    collection_name="ecommerce_kb"
)

# 批量写入
vectorstore.add_documents(chunks)

# 语义检索，top_k=5
results = vectorstore.similarity_search_with_score(
    query="退换货政策是什么",
    k=5
)
for doc, score in results:
    print(f"分数: {score:.4f}, 内容: {doc.page_content[:100]}...")

代码解释：

• 输入：PostgreSQL 连接参数、embedding 模型、文档列表、查询语句
• 核心逻辑：用 PGVector 封装 psycopg2 和 pgvector，adddocuments 批量写入，similaritysearchwithscore 做语义检索并返回相关度分数
• 输出：检索结果列表，每条包含文档内容和相关度分数
• 异常处理：连接失败会抛 psycopg2 异常，embedding 调用失败会抛 OpenAI 异常，需要在上层捕获

这里有个取舍：pgvector 的优势是部署简单、和现有数据栈打通，劣势是海量数据下性能不如专用向量数据库。如果你的向量数据超过千万级，或者需要分布式检索，那还是得考虑 Milvus 或 Pinecone。但对于大多数中小团队，pgvector 是最务实的选择。

---

RAG 数据管道：从代码到可观测

RAG 数据管道不只是代码，还包括监控。

大数据工程师习惯看任务运行时间、数据量、成功率。大模型项目也一样，但指标不一样。

需要监控的指标：

• 检索准确率：用户的问题能不能检索到相关内容
• 生成质量：回答是否准确、有没有幻觉
• 延迟：端到端响应时间
• 成本：每次调用的 token 消耗

我们项目上线前，花了一周时间接监控。不是加复杂的 APM 系统，而是用简单的日志 + 数据库记录。

# 简单的调用日志记录
import json
import time
from datetime import datetime
from sqlalchemy import insert

def log_query(user_id: str, query: str, context: list, response: str, latency: float, model: str):
    """记录每次查询的日志，方便后续分析和排查"""
    log_entry = {
        "timestamp": datetime.utcnow().isoformat(),
        "user_id": user_id,
        "query": query,
        "context_snippets": [c.page_content[:200] for c in context],
        "response": response,
        "latency_ms": round(latency * 1000, 2),
        "model": model,
        "status": "success"
    }

    # 写入日志表
    with engine.connect() as conn:
        conn.execute(insert(query_logs).values(**log_entry))
        conn.commit()

    # 同时写文件日志，方便实时查看
    with open(f"logs/queries_{datetime.now().strftime('%Y%m%d')}.jsonl", "a") as f:
        f.write(json.dumps(log_entry, ensure_ascii=False) + "\n")

代码解释：

• 输入：用户 ID、查询语句、检索上下文、模型回复、延迟时间、模型名称
• 核心逻辑：构造结构化日志对象，同时写入数据库和 JSONL 文件
• 输出：无，副作用是记录日志
• 异常处理：数据库写入失败会抛 sqlalchemy 异常，文件写入失败会抛 IOError，需要在外层 try-catch 捕获，避免影响主流程

这个日志系统后来帮了大忙。上线后第三天，有用户反馈回答不准确。我们通过日志查到了具体 query，发现检索到的上下文里混进了过期的促销信息，导致模型给出了错误答案。

---

落地项目：电商客服机器人的一天

这个项目最终上线了，但上线过程并不顺利。

第一天：部署到测试环境，基础功能正常。客服问"双十一发货时间"，模型回答"一般 48 小时内发货"，看起来没问题。

第二天：接入生产环境，开始有真实用户提问。问题量比预期大，模型响应变慢。

第三天：开始出现错误回答。有用户问"优惠券能叠加吗"，模型回答"可以叠加"，但实际上活动规则明确写了不能叠加。

第四天：权限问题爆发。客服系统有 RBAC 权限控制，但 RAG 管道没有对接。普通客服能检索到内部成本数据，这是严重的安全问题。

第五天：开始排查。发现三个问题：
1. 检索到的上下文里有过期数据，没有时效性过滤
2. 权限没有和 RAG 管道打通，检索结果没有做权限校验
3. 日志系统没有覆盖检索环节，不知道每次检索返回了什么

---

排查过程：权限和日志的噩梦

权限问题是最严重的。我们用了 FastAPI 做接口，权限校验在路由层做了，但 RAG 管道的检索没有权限过滤。

现象：普通客服账号能检索到包含成本价的商品信息。
验证动作：
1. 检查 RBAC 中间件代码，确认权限校验逻辑
2. 检查 RAG 管道，确认检索时有没有过滤用户权限
3. 对比数据库里的权限表和检索结果

排除结果：权限校验只在接口层，RAG 管道完全不知道用户身份。检索返回的是全局数据，没有做权限过滤。

修复方案：在检索时传入用户权限标签，用向量数据库的元数据过滤功能限制检索范围。

# 带权限过滤的检索
def search_with_permissions(query: str, user_permissions: list, top_k: int = 5):
    """根据用户权限过滤检索结果"""
    # 将权限标签转为向量数据库可接受的过滤条件
    permission_filter = {"department": {"$in": user_permissions}}

    results = vectorstore.similarity_search_with_score(
        query=query,
        k=top_k,
        filter=permission_filter
    )
    return results

代码解释：

• 输入：查询语句、用户权限列表、返回数量
• 核心逻辑：将权限标签转为 pgvector 的 filter 参数，在检索时直接过滤
• 输出：符合权限的检索结果
• 异常处理：filter 格式错误会抛 pgvector 异常，需要验证权限标签格式

日志问题也花了时间排查。我们最初只记录了最终回复，没有记录检索上下文和模型调用详情。出了问题之后，完全不知道是检索阶段的问题还是生成阶段的问题。

现象：用户反馈回答不准确，但不知道是检索错了还是模型胡说。
验证动作：
1. 查看 query_logs 表，找到对应记录
2. 检查 context_snippets 字段，看检索到了什么
3. 检查 response 字段，看模型回复了什么
4. 对比 ground truth，判断是检索问题还是生成问题

排除结果：大部分不准确回答是检索阶段的问题——检索到的上下文不包含正确答案，或者包含了矛盾的信息。

修复方案：在日志里增加检索分数、检索时间、上下文数量等字段，方便定位问题。

---

失败原因：业务错误、配置错误、环境错误怎么区分

大模型项目的失败原因可以分成三类：

业务错误：检索策略不对、分块不合理、提示词设计有问题。这类错误的特点是逻辑上能复现，改配置就能修。
配置错误：权限配置不对、向量数据库连接配置错误、API 密钥配置错误。这类错误的特点是部署后出现问题，改配置就能修。
环境错误：网络超时、内存不足、依赖版本冲突。这类错误的特点是偶发，需要排查环境。

我们项目里三类错误都踩过了。

最典型的是权限问题，属于配置错误。RBAC 中间件配好了，但 RAG 管道没有对接，导致权限校验失效。修复方式是增加权限过滤参数，配置很简单，但漏掉了。

另一个是检索超时，属于环境错误。向量数据库查询时间超过 API 超时限制，导致请求失败。修复方式是增加超时时间，或者优化检索策略。

---

适用边界：什么时候该照搬，什么时候该取舍

这篇文章的经验适用于以下场景：

• 小团队（10 人以下）做大模型应用
• 数据源是结构化文档（PDF、Word、数据库）
• 检索规模在百万级以下
• 对成本敏感，不愿意维护复杂的基础设施

不适用以下场景：

• 大规模分布式检索（千万级以上向量）
• 实时性要求极高（毫秒级响应）
• 多模态数据（图片、视频）
• 需要复杂的工作流编排

核心取舍：

• 简单 vs 强大：pgvector 比 Milvus 简单，但海量数据下性能差
• 自托管 vs 托管服务：自托管成本低但运维重，托管服务省心但成本高
• 快速上线 vs 长期可维护：快速上线可能留下技术债，长期可维护需要前期投入

---

总结

大数据工程师转大模型，优势在于数据思维和工程能力。但大模型项目有新的坑：权限、日志、可观测、成本。这些在大数据项目里你可能不碰，但在大模型项目里是生死线。

给大数据工程师的建议：
1. 不要过度设计，先用 pgvector + 简单日志跑起来
2. 权限和日志要从第一天就考虑，不要等上线后再补
3. 监控指标和大模型项目不一样，检索准确率比数据量更重要
4. 失败原因要会分类，业务错误、配置错误、环境错误的排查方法不同

这个项目最终上线了，虽然不完美，但跑起来了。权限问题修了，日志系统接了，检索准确率也提上来了。重要的是，团队学会了在大模型项目里关注工程化问题，而不只是调模型和写 prompt。

大数据转大模型，不是换赛道，是换场景。核心能力还在，只是需要补一些新的东西。

资料展示

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

需要这份AI大模型资料清单的话，在评论区回复「清单」即可；我会根据大家的问题继续补充对应的实战内容。