聊《我用大数据经验做了次 AI 项目最先失效的是旧方法》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要接了一个医疗知识库问答的 Agent 项目Demo 跑得很顺业务方看着满意。结果上线第一天有人投诉看到了不该看的内容而我翻遍日志根本还原不了当时的权限判断过程。那次之后我意识到一件事数据工程师转型大模型最大的坑不是模型选型也不是提示词怎么写而是权限、日志、可观测性这些工程化细节。目录大数据和大模型的交叉点一个真实案例排查过程代码解释失败原因适用边界总结大数据和大模型的交叉点很多人说大数据和大模型没关系这个说法不准确。它们有交叉但交叉点不是你想的那样。传统数据工程强调精确查询、强一致性、数据血缘。大模型时代向量检索的本质是模糊匹配评估指标从准确率变成了召回率和回答质量数据形态从结构化表格扩展到了非结构化文本甚至图片。真正能复用的只有两件事数据治理的思路以及管道设计的经验。我做项目的时候发现团队里做大数据出身的人有两个优势第一对数据质量敏感知道脏数据会直接毁掉下游第二习惯写可维护的 ETL不会为了 Demo 快就堆屎山代码。但也有两个坑特别容易踩一是过度设计权限体系把简单的需求搞成迷宫二是觉得有了模型就万事大吉忽略了可观测性的基础建设。一个真实案例去年下半年我给一个区域医疗集团做知识库 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, filterallowed_doc_ids, ktop_k ) # 输出带权限过滤的检索结果 return format_results(results, allowed_doc_ids)这段代码的核心逻辑有三步先拿权限集合再做 embedding最后在权限范围内检索。关键点在于 FAISS 的search_with_filter方法它可以在检索时直接应用布尔过滤避免了先全量检索再二次过滤的性能损耗。异常处理方面get_user_allowed_docs返回空的时候直接返回空列表避免后续检索抛错。这个方法在权限配置错误的情况下也比较安全不会因为权限系统故障导致整个查询崩溃。权限集合的获取逻辑我没有展开因为它取决于你们的权限模型设计。常见的有两种一种是把权限表做成用户到文档 ID 的映射查询时直接取另一种是角色映射先查用户角色再查角色对应的文档范围。第一种适合权限粒度细的场景第二种适合角色分类明确的场景。我的建议是小团队用第一种简单直接排查也方便。失败原因那次项目我踩了三个主要的问题拆开来讲。第一个是权限过度设计。我一开始想做完整的 RBAC 加属性访问控制每个文档打上多个维度的标签查询时做多维过滤。结果查询慢、维护难出问题时还找不到根因。后来简化成用户直接绑定文档 ID 集合查询性能提升了将近三倍排查也方便多了。第二个是日志缺失。我只记了查询结果和耗时没有记录权限判断过程、模型调用的 prompt 和 response、用户的原始输入。这些东西不出事的时候没用出事的时候就是救命稻草。第三个是评估指标错位。我用检索准确率来评估业务方用回答质量来评估两边的数据对不上导致上线后业务方满意度很低。后来我加了一个回答质量的评估维度用规则加抽样人工复核的方式才把指标对齐。区分业务错误、配置错误和环境错误我有一个简单的判断方法业务错误是逻辑问题代码没问题但结果不对配置错误是参数或数据源的问题代码没问题但配置错了环境错误是基础设施的问题代码和配置都没问题但环境不对。排查的时候先确认是哪一类再针对性地解决效率会高很多。适用边界这套方案有一些明显的适用边界。第一它适合中小规模的知识库文档数量在十万级别以下。如果数据量更大FAISS 的过滤检索性能会下降需要考虑分片或者换成 Milvus 这类分布式向量库。第二权限模型适合角色明确的场景。如果你们的权限体系非常复杂比如有动态权限、临时授权、跨部门共享这套方案就不够用了需要引入更完善的权限框架。第三日志和可观测性这里只做了最基础的实现。如果你们是合规要求高的行业比如医疗、金融需要对接专业的可观测性平台比如 OpenTelemetry把 trace、metric、log 打通。取舍方面小团队不要一开始就做完整的可观测性体系先把最重要的东西记下来权限判断路径、模型调用记录、用户输入输出。等规模上去了再逐步完善。总结大数据工程师转型大模型最大的障碍不是技术栈的变化而是思维模式的转变。你们习惯做精确的、可验证的、有明确标准的事情。大模型项目的很多环节是概率性的、模糊的、需要不断试错的。但这不代表旧经验没用数据治理的思路、管道设计的经验、对数据质量的敏感度这些都是真实可用的。真正需要补课的是权限控制、日志记录和可观测性。这些不是大模型的专属问题是工程化的通用问题。但在大模型项目里你们更容易忽略它们因为 Demo 阶段这些问题不会暴露。我的建议是先做一个小型的内部项目把权限、日志、可观测性这三件事做实再去看更大的场景。Demo 能跑通只是及格线能把这三件事做好才是真正的门槛。如果你正在准备转型简历上不要只写做过 RAG 项目要写清楚你的权限设计思路、日志记录方案、以及你如何处理了权限事故。这些才是面试官真正想听到的东西。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
聊《我用大数据经验做了次 AI 项目最先失效的是旧方法》之前先说一句实在的别急着背概念先看它在真实项目里到底解决什么问题。摘要接了一个医疗知识库问答的 Agent 项目Demo 跑得很顺业务方看着满意。结果上线第一天有人投诉看到了不该看的内容而我翻遍日志根本还原不了当时的权限判断过程。那次之后我意识到一件事数据工程师转型大模型最大的坑不是模型选型也不是提示词怎么写而是权限、日志、可观测性这些工程化细节。目录大数据和大模型的交叉点一个真实案例排查过程代码解释失败原因适用边界总结大数据和大模型的交叉点很多人说大数据和大模型没关系这个说法不准确。它们有交叉但交叉点不是你想的那样。传统数据工程强调精确查询、强一致性、数据血缘。大模型时代向量检索的本质是模糊匹配评估指标从准确率变成了召回率和回答质量数据形态从结构化表格扩展到了非结构化文本甚至图片。真正能复用的只有两件事数据治理的思路以及管道设计的经验。我做项目的时候发现团队里做大数据出身的人有两个优势第一对数据质量敏感知道脏数据会直接毁掉下游第二习惯写可维护的 ETL不会为了 Demo 快就堆屎山代码。但也有两个坑特别容易踩一是过度设计权限体系把简单的需求搞成迷宫二是觉得有了模型就万事大吉忽略了可观测性的基础建设。一个真实案例去年下半年我给一个区域医疗集团做知识库 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, filterallowed_doc_ids, ktop_k ) # 输出带权限过滤的检索结果 return format_results(results, allowed_doc_ids)这段代码的核心逻辑有三步先拿权限集合再做 embedding最后在权限范围内检索。关键点在于 FAISS 的search_with_filter方法它可以在检索时直接应用布尔过滤避免了先全量检索再二次过滤的性能损耗。异常处理方面get_user_allowed_docs返回空的时候直接返回空列表避免后续检索抛错。这个方法在权限配置错误的情况下也比较安全不会因为权限系统故障导致整个查询崩溃。权限集合的获取逻辑我没有展开因为它取决于你们的权限模型设计。常见的有两种一种是把权限表做成用户到文档 ID 的映射查询时直接取另一种是角色映射先查用户角色再查角色对应的文档范围。第一种适合权限粒度细的场景第二种适合角色分类明确的场景。我的建议是小团队用第一种简单直接排查也方便。失败原因那次项目我踩了三个主要的问题拆开来讲。第一个是权限过度设计。我一开始想做完整的 RBAC 加属性访问控制每个文档打上多个维度的标签查询时做多维过滤。结果查询慢、维护难出问题时还找不到根因。后来简化成用户直接绑定文档 ID 集合查询性能提升了将近三倍排查也方便多了。第二个是日志缺失。我只记了查询结果和耗时没有记录权限判断过程、模型调用的 prompt 和 response、用户的原始输入。这些东西不出事的时候没用出事的时候就是救命稻草。第三个是评估指标错位。我用检索准确率来评估业务方用回答质量来评估两边的数据对不上导致上线后业务方满意度很低。后来我加了一个回答质量的评估维度用规则加抽样人工复核的方式才把指标对齐。区分业务错误、配置错误和环境错误我有一个简单的判断方法业务错误是逻辑问题代码没问题但结果不对配置错误是参数或数据源的问题代码没问题但配置错了环境错误是基础设施的问题代码和配置都没问题但环境不对。排查的时候先确认是哪一类再针对性地解决效率会高很多。适用边界这套方案有一些明显的适用边界。第一它适合中小规模的知识库文档数量在十万级别以下。如果数据量更大FAISS 的过滤检索性能会下降需要考虑分片或者换成 Milvus 这类分布式向量库。第二权限模型适合角色明确的场景。如果你们的权限体系非常复杂比如有动态权限、临时授权、跨部门共享这套方案就不够用了需要引入更完善的权限框架。第三日志和可观测性这里只做了最基础的实现。如果你们是合规要求高的行业比如医疗、金融需要对接专业的可观测性平台比如 OpenTelemetry把 trace、metric、log 打通。取舍方面小团队不要一开始就做完整的可观测性体系先把最重要的东西记下来权限判断路径、模型调用记录、用户输入输出。等规模上去了再逐步完善。总结大数据工程师转型大模型最大的障碍不是技术栈的变化而是思维模式的转变。你们习惯做精确的、可验证的、有明确标准的事情。大模型项目的很多环节是概率性的、模糊的、需要不断试错的。但这不代表旧经验没用数据治理的思路、管道设计的经验、对数据质量的敏感度这些都是真实可用的。真正需要补课的是权限控制、日志记录和可观测性。这些不是大模型的专属问题是工程化的通用问题。但在大模型项目里你们更容易忽略它们因为 Demo 阶段这些问题不会暴露。我的建议是先做一个小型的内部项目把权限、日志、可观测性这三件事做实再去看更大的场景。Demo 能跑通只是及格线能把这三件事做好才是真正的门槛。如果你正在准备转型简历上不要只写做过 RAG 项目要写清楚你的权限设计思路、日志记录方案、以及你如何处理了权限事故。这些才是面试官真正想听到的东西。资料展示下面是我整理的AI大模型学习资料和工具包预览适合收藏后按主题逐步学习。如果你想看完整资料目录可以在评论区留言「资料」也欢迎告诉我你更关注AI大模型里的哪类内容。
