用大数据经验做 RAG，上线第一天权限和日志把我打回原形

关注

原创最新推荐文章于 2026-11-12 17:50:43 发布 280 阅读 AI 写同款· GEO 优化 ›

一次实时数据链路丢数排查：从 MQTT 队列积压到 SQL 统计开销本文通过一次实时数据链路压测，排查了从MQTT到ClickHouse的端到端数据丢失问题。核心方法是为每条消息添加序号，建立独立观察点（MQTT订阅端、Kafka消费者），结合转发服务阶段统计与线程栈分析，定位到下游处理速度不足源于Druid SQL合并统计的高开销。优化措施包括关闭SQL合并、扩容代理队列、增强生产侧失败处理，并验证15分钟内实现全链路对账一致，显著缓解积压与丢包。关键收获：数据可对账、明确各阶段“成功”定义、关注客户端队列状态。阅读详情

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

摘要

接了一个医疗知识库问答的 Agent 项目，Demo 跑得很顺，业务方看着满意。结果上线第一天，有人投诉看到了不该看的内容，而我翻遍日志，根本还原不了当时的权限判断过程。

那次之后我意识到一件事：数据工程师转型大模型，最大的坑不是模型选型，也不是提示词怎么写，而是权限、日志、可观测性这些工程化细节。

大数据和大模型的交叉点

文章插图 1

很多人说大数据和大模型没关系，这个说法不准确。它们有交叉，但交叉点不是你想的那样。

传统数据工程强调精确查询、强一致性、数据血缘。大模型时代，向量检索的本质是模糊匹配，评估指标从准确率变成了召回率和回答质量，数据形态从结构化表格扩展到了非结构化文本甚至图片。

真正能复用的，只有两件事：数据治理的思路，以及管道设计的经验。

我做项目的时候，发现团队里做大数据出身的人有两个优势：第一，对数据质量敏感，知道脏数据会直接毁掉下游；第二，习惯写可维护的 ETL，不会为了 Demo 快就堆屎山代码。

但也有两个坑特别容易踩：一是过度设计权限体系，把简单的需求搞成迷宫；二是觉得有了模型就万事大吉，忽略了可观测性的基础建设。

一个真实案例

文章插图 2

去年下半年，我给一个区域医疗集团做知识库 RAG。输入是一批结构化病历数据加非结构化诊疗规范，目标是在医生输入症状时，给出带依据的治疗建议。

技术栈选了 FAISS 做向量存储，Spark 做预处理，FastAPI 搭服务。Demo 阶段一切正常，检索准确率跑到 0.82，业务方很满意。

然后我们进入上线准备，这时候问题一个个冒出来。

第一个是权限。我设计了细粒度的 ACL 表，按科室、职级、患者授权范围三层过滤，查询逻辑复杂得连自己都理不清。第二个是日志。我只记录了向量查询的耗时和结果，没有记录权限判断的具体路径，出事的时候完全无法还原现场。第三个是评估。我用的是检索准确率，但业务方关心的是答案质量，两个指标根本对不上。

上线第一天，有医生反馈看到了超出自己权限范围的病例。监控里查不到任何异常，因为权限判断走了三层 JOIN，而日志里没有记录每层判断的结果。排查花了整整两天，才找到问题——某个角色的权限映射配置错了，但因为没有完整的审计链，没人能第一时间定位到具体哪一层出了问题。

这件事给我上了很大的一课。

排查过程

权限事故发生的当天，业务方反馈有人看到了不该看的内容。我当时的排查路径是这样的：

现象是"越权访问"，但我不知道是哪个角色的用户、访问了哪条数据、走了哪个权限分支。

第一步，我先查了向量库的查询日志。日志里只有 embedding 请求和返回的 top-k 结果，没有任何权限相关的信息。这一步排除了向量库本身的问题。

第二步，我查了权限服务的接口日志。发现每次查询都会调用权限接口，但接口只返回了 pass 或 deny，没有记录判断依据。这一步说明权限服务的设计本身就存在问题。

第三步，我翻了代码，找到了权限判断的三层逻辑：科室归属、职级限制、患者授权。每层都是独立的 IF 判断，但没有任何一层记录了中间结果。

第四步，我重新加了一次日志，把每层权限判断的输入、输出、判断依据都记录下来，同时补上了请求的唯一 trace_id，这样可以把权限判断和向量查询关联起来。

排查的过程很痛苦，因为问题不在代码逻辑，而在缺少可观测性。这也是大多数数据工程师转型时会忽略的点：你们习惯了事后从数据里还原现场，但 Agent 的运行轨迹不是静态数据，是动态的执行路径，不记录就没法复盘。

优快云资料领取方式

代码解释

权限过滤这块，我后来改成了一个比较简洁的实现。思路是：不写复杂的权限树，先根据用户角色拿到允许的文档 ID 集合，然后在向量检索时把这个集合作为过滤条件。

def retrieve_with_permission(user_id: str, query: str, top_k: int = 5):
    # 输入：用户ID、查询文本、返回条数
    # 核心逻辑：先拿到用户的文档权限集合，再做向量检索

    # 1. 获取用户允许的文档ID集合
    allowed_doc_ids = get_user_allowed_docs(user_id)
    if not allowed_doc_ids:
        return []  # 异常处理：无权限时直接返回空

    # 2. 对查询文本做 embedding
    query_embedding = embed_text(query)

    # 3. 在允许的文档ID范围内做向量检索
    results = faiss_index.search_with_filter(
        query_embedding,
        filter=allowed_doc_ids,
        k=top_k
    )

    # 输出：带权限过滤的检索结果
    return format_results(results, allowed_doc_ids)

这段代码的核心逻辑有三步：先拿权限集合，再做 embedding，最后在权限范围内检索。关键点在于 FAISS 的 search_with_filter 方法，它可以在检索时直接应用布尔过滤，避免了先全量检索再二次过滤的性能损耗。

异常处理方面，get_user_allowed_docs 返回空的时候直接返回空列表，避免后续检索抛错。这个方法在权限配置错误的情况下也比较安全，不会因为权限系统故障导致整个查询崩溃。

权限集合的获取逻辑我没有展开，因为它取决于你们的权限模型设计。常见的有两种：一种是把权限表做成用户到文档 ID 的映射，查询时直接取；另一种是角色映射，先查用户角色，再查角色对应的文档范围。第一种适合权限粒度细的场景，第二种适合角色分类明确的场景。

我的建议是小团队用第一种，简单直接，排查也方便。