从银行数据治理转向AI产品开发的五年老手，用血泪教训揭示了一个行业真相：在GPT、Claude等大模型能力趋同的今天，决定AI产品专业度的不是API参数，而是底层数据的「洁癖级」处理。本文通过金融客服翻车、法律问答崩盘、知识库精神分裂三个真实案例，拆解数据清洗、SFT微调、RAG架构中的致命陷阱，给所有正在与「垃圾进垃圾出」搏斗的AI产品人一剂清醒剂。

在银行写了五年数据，转去做 AI 产品之后，我接的第一个活是一个金融客服。

模型用的是行业顶流，Prompt 调了好几版，可用户反馈始终有一句很扎心的话：「像个背课文背串了的学生，看着聪明，一说话就露馅。」

那时候我也焦虑过算法。今天 DeepSeek 出新版本，明天通义千问刷榜，我对着两份 API 文档比参数，像挑发动机的二手车买家。后来产品上线，问题一个个冒出来，我才慢慢看清楚一件事：模型混淆、答非所问、前后矛盾这些病，大部分不是模型的问题，是底下那堆数据的问题。

模型能力差不多了的今天，谁家产品做得好，看的是底层数据，不是 API。

下面是三件具体的事。

银行那五年留下来的「洁癖」

很多做 AI 产品的朋友听到我有银行背景，第一反应是「你们那套是不是太保守了」。

确实保守，保守到接近洁癖。但我后来在 AI 产品里反复栽跟头的地方，恰恰是这种洁癖救我的地方。

带我的人话不多，给我立过一条规矩：数据进仓之前，必须过三道闸。第一道是源头清洗——空值怎么填、异常值怎么判、时间格式统一成什么样，全是死规矩。第二道是逻辑校验——主键唯一，外键能关上，上下游指标互相能勾稽。第三道是分层——ODS 贴源层放原始数据只留存不动，DWD 明细层做清洗去重，DWS 汇总层按主题聚合，ADS 应用层才是真正给前端用的。每一层都有自己的活，不许串。

我印象最深的一次是做月末监管报表。某个 ETL 作业里，一个字段精度在小数点后第三位出了偏差。0.001，搁互联网产品里连 bug 都算不上。但银行那套数据是层层汇总的，这个偏差一路加上去，最后会影响到风险加权资产。

那天下午我被叫去办公室，对方没骂人，只是把报表摊在桌上，指着那一行问我：「如果这个数字被监管看到，你觉得他们会认为是我们系统的问题，还是态度的问题？」

我那时候才二十多岁，记到现在。

数据治理这件事，技术上没多难，难的是这种「手一抖就是几千万」的紧绷感。后来我跳出银行做 AI 产品，发现行业里大多数团队最缺的就是这个基本功。

GPT、Claude、DeepSeek、通义千问，大家用的脑子都差不多，智商都在 140 以上。那凭什么你的 AI 产品比别人专业？凭你给它读的那本教科书是不是经过严格审校的。

我见过太多团队做 RAG 知识库，把原始文档、清洗过的 FAQ、业务部门临时写的说明、甚至测试环境的假数据，一股脑倒进同一个向量库。然后回头抱怨「模型不行，检索不准」。

这不是模型的问题。是你把教科书、草稿纸、小广告和厕所涂鸦订在一起，塞给了那个学生。他再聪明也得疯。

第一次 SFT：我用爬虫数据把模型喂坏了

银行出来之后，我接的活之一是给一个法律方向的产品做 SFT 微调。

第一反应是数据嘛，爬。爬虫跑了几天，扒了一千多条法律问答对，格式统一，直接喂给模型监督微调。训练 loss 曲线挺漂亮，降得稳稳的。我做完测试，第一个问题就把我干懵了。

我问：「劳动合同到期不续签，公司需要提前多久通知？」

模型回答了一大段。前半段说《劳动合同法》第四十条的提前三十天通知，后半段突然拐到试用期解除的条件，最后还来了一句「具体以当地政策为准」。三个知识点串成三串烤面筋，没一根在签子上。

这个回答我盯了挺久。

那一千多条数据，表面上都是法律问答，实际噪音大得离谱。有的是好几年前的旧法条，有的是不同地区的特殊规定，有的是论坛网友的回答，连基本的时效性都没校验过。模型像一个被塞了一肚子过期食品的孩子，你指望他吐出什么好东西？

后来我删了那批爬虫数据，拉着法务同事，花了大概一周，人工精选了一小批问答对。这批数据每一条都过三重校验：法条原文是不是现行有效、司法解释有没有更新、适用场景是不是明确。每一条都标了边界——这个问题适用于什么情形，不适用于什么情形，容易和哪个近似概念混淆。

我把这批精选数据，加上从原来一千多条里筛出来的一部分相对干净的语料，重新做了微调。

同样是那个劳动合同的问题，这一次模型不仅给出了准确的法条依据，还主动区分了「合同到期不续签」和「合同期内解除」这两种不同情形，甚至提示了部分地区有地方性规定。

少量精准、边界清晰的数据，比一千多条来路不明的语料管用得多。

AI 不变魔术，本质是模式识别加概率预测。你喂垃圾，它学的就是垃圾规律。

这事之后我给团队定了一条红线：入模前的数据，必须像银行月末报表一样，经得起审计。

RAG 知识库的「精神分裂」

第二个坑在 RAG。

那阵子我们做一个内部知识助手，需求很直白——员工问内部制度、流程、产品规则，AI 要能给准答案。技术方案没什么新意，向量库加 Embedding 加大模型生成。我们花了两周把几千份内部文档全部向量化塞进去，测试时简单问题都答对了，我以为这活儿成了。

上线第一周投诉就过来了。

有员工问某个信用贷产品的最高额度。AI 回答的前半段说的是去年废止的旧规则，后半段跳到今年新产品的准入条件，中间还夹杂了一段风控部门的内部讨论纪要。员工看完直接懵了——「所以到底是多少？我能给客户承诺吗？」

我打开知识库后台，看到那几千份文档的分类，血压一下就上来了。

原始制度、修订后的制度、部门内部解读 PPT、培训用的简化讲义、甚至某次会议的随手记录，全混在一起。向量检索的时候，模型同时抓到了「原始版」和「修订版」两个片段，逻辑不自洽，可不就精神分裂了吗？

我坐在电脑前，脑子里冒出来的是银行那张老架构图。

为什么 RAG 知识库不能也分层？

我们重新设计了架构。原始文档层只存不搜，作为母本。清洗校验层是人工或规则过了一遍的生效版本，每份都标了时效性、适用范围、版本号。知识片段层按主题切分、向量化，每个片段带明确的元数据——适用部门、生效时间、业务类型。应用接口层是唯一暴露给大模型检索的层。

但分层不是关键。

关键是每两层之间的「逻辑校验闸」。如果清洗校验层发现某份文档的生效日期和废止日期冲突，直接阻断，不许进入下一层。如果知识片段层里有两个版本对同一问题的描述不一致，触发人工复核。

这套搭起来之后，那个信用贷额度的问题再也没答错过。它检索到的每一个片段，都是版本一致、边界清晰的。

数据流干净，模型自己就能摸到规律。底层是一锅粥，模型再先进也只能在粥里打滚。

顺带说一句关于用户反馈的事。产品上线之后用户每次对话都是新数据，理论上是最高质量的语料——他问的那个问题揭示了你的盲区，他纠正的那一句包含了新知识。但这些数据要回到模型里，也必须走一遍同样的分层和校验：先过噪音过滤丢掉测试数据和恶意输入，再做价值标注，再做精细清洗和脱敏，最后才能用于增量微调或知识库更新。

跳过任何一步，你回流的就是新一批噪音。

这个行业现在不缺会用模型的人，缺的是愿意在数据这件脏活上扎下去的人。模型在哪一家手里能力差距都不大，差距在底下那本教科书上。