那些年我们踩过的坑：水务大模型落地常见问题与应对
> 来自一线实践的教训总结，帮您少走弯路
前面十二篇文章，我们从架构到实施、从安全到选型，把水务大模型的方方面面都讲到了。但任何新技术落地，都会遇到书本上不会写的问题。这一篇，我们就把那些最常见的“坑”摆出来——数据质量问题、模型胡说八道的问题、员工不愿用的问题、供应商不靠谱的问题。每一个坑，都是真金白银换来的教训。
坑一：数据质量差——模型学了一堆错误知识
现象
模型上线后，问它“二号泵去年的维修次数”，它回答“三次”。但翻原始维修记录，实际是五次。原因是：维修工单系统里，有两条记录把“二号泵”写成了“2号泵”，模型检索时没关联上。
更常见的是：同一台设备，在不同系统里名称不同（“二号泵”“2泵”“P-02”“出厂水泵2”）。模型不是人，它不知道这些是同一个东西。还有的数据表里，浊度单位有时是NTU，有时是“度”，模型直接按数字比较，得出错误结论。
为什么会踩坑？
- 急于上线，没有对历史数据做充分的质量评估
- 以为“大模型很智能，能自动处理脏数据”——实际上模型会忠实学习错误数据
- 水司多年积累的数据分散在不同系统、不同年代、不同标准下，整合难度远超预期
怎么应对？
第一，先拿“干净数据”做试点。 不要一开始就把所有历史数据都倒进去。选一个数据质量相对好的子系统（比如近两年的水厂运行日志），先在这个小范围内跑通。验证效果后，再逐步扩大数据范围，同时每扩大一个数据源，就做一次质量检查。
第二，建立数据“体检”流程。 在数据进入知识库之前，做几项基础检查：必填字段是否为空、数值是否在合理范围内（比如浊度不可能为负数）、时间戳是否连续、单位是否统一。不要求所有数据完美，但要清楚知道“哪些数据有什么问题”，使用时心中有数。
第三，让模型帮忙发现数据问题。 当用户发现模型回答错误时，往往意味着背后的数据有问题。建立一个反馈机制：用户点“回答错误”后，系统记录下这个问题，定期汇总给数据管理员。数据管理员根据这些线索去修复原始数据。这样模型和用户一起，帮助水司把数据质量越修越好。
第四，关键数据人工复核。 对于涉及设备维修记录、水质超标事件、财务数据等关键信息，不要完全依赖模型的检索结果。模型可以作为快速查询工具，但正式报告或决策前，应去原始系统核对。
坑二：模型“一本正经地胡说八道”
现象
用户问：“东区管网的平均压力是多少？”模型回答：“根据资料，东区管网平均压力为0.32兆帕。”用户照着这个数据去做调度调整，结果发现实际压力是0.28兆帕。后来查明：模型检索到的是三年前的历史数据，但它没有说明是“历史平均压力”，直接当成了当前压力。
更隐蔽的情况：用户问“这个阀门是什么型号？”知识库里没有记录，但模型不想说“不知道”，自己编了一个型号——“Z45X-16Q”。看起来很专业，其实是假的。如果维修工照着这个型号去采购，就买错了。
为什么会踩坑？
- 大模型的本能是“生成流畅的答案”，而不是“保证每个事实都正确”
- 当知识库里没有答案时，模型倾向于“编一个合理的”，而不是承认不知道
- 用户容易被“格式工整、细节丰富”的回答误导，放松警惕
怎么应对？
第一，强制模型标明信息来源。 在模型设置里，要求每次回答必须引用来源（哪个文档、哪个数据库、哪条记录）。如果信息来自多个来源，分别列出。如果知识库里没有找到相关信息，模型必须回答“没有找到相关记录”，而不是自己编。
第二，对实时数据做特殊标记。 对于需要实时值的问题（如当前压力、当前流量），模型应明确提示用户“以下数据来自某某系统某时某刻的记录，请以现场仪表为准”。或者干脆不让模型回答实时数据类问题，而是引导用户去查看监控系统。
第三，关键决策人工确认。 凡是涉及调整加药量、开关设备、应急响应的建议，模型只能作为“参考意见”，最终决定必须由人来做。在系统流程上，可以设计“模型建议 + 人工确认”的环节，不能跳过。
第四，长期优化模型和知识库。 模型胡说八道的问题，会随着知识库的完善和提示词的调优而逐渐减少。但永远无法100%消除。所以要持续收集用户反馈，把发现的问题记录下来，定期优化。
坑三：员工不愿用——模型再好，没人用等于零
现象
系统上线三个月，后台数据显示：每天只有两三个人登录，问了几个问题就再也没来过。技术团队精心搭建的知识库、调优的模型，基本闲置。
深入访谈发现：一线员工觉得“问问题还不如直接去翻手册，手册我熟”；值班人员觉得“我已经干了二十年，不需要机器告诉我怎么调”；还有人担心“AI会不会将来取代我”。
为什么会踩坑？
全文见水之羿公众号
> 来自一线实践的教训总结，帮您少走弯路
前面十二篇文章，我们从架构到实施、从安全到选型，把水务大模型的方方面面都讲到了。但任何新技术落地，都会遇到书本上不会写的问题。这一篇，我们就把那些最常见的“坑”摆出来——数据质量问题、模型胡说八道的问题、员工不愿用的问题、供应商不靠谱的问题。每一个坑，都是真金白银换来的教训。
坑一：数据质量差——模型学了一堆错误知识
现象
模型上线后，问它“二号泵去年的维修次数”，它回答“三次”。但翻原始维修记录，实际是五次。原因是：维修工单系统里，有两条记录把“二号泵”写成了“2号泵”，模型检索时没关联上。
更常见的是：同一台设备，在不同系统里名称不同（“二号泵”“2泵”“P-02”“出厂水泵2”）。模型不是人，它不知道这些是同一个东西。还有的数据表里，浊度单位有时是NTU，有时是“度”，模型直接按数字比较，得出错误结论。
为什么会踩坑？
- 急于上线，没有对历史数据做充分的质量评估
- 以为“大模型很智能，能自动处理脏数据”——实际上模型会忠实学习错误数据
- 水司多年积累的数据分散在不同系统、不同年代、不同标准下，整合难度远超预期
怎么应对？
第一，先拿“干净数据”做试点。 不要一开始就把所有历史数据都倒进去。选一个数据质量相对好的子系统（比如近两年的水厂运行日志），先在这个小范围内跑通。验证效果后，再逐步扩大数据范围，同时每扩大一个数据源，就做一次质量检查。
第二，建立数据“体检”流程。 在数据进入知识库之前，做几项基础检查：必填字段是否为空、数值是否在合理范围内（比如浊度不可能为负数）、时间戳是否连续、单位是否统一。不要求所有数据完美，但要清楚知道“哪些数据有什么问题”，使用时心中有数。
第三，让模型帮忙发现数据问题。 当用户发现模型回答错误时，往往意味着背后的数据有问题。建立一个反馈机制：用户点“回答错误”后，系统记录下这个问题，定期汇总给数据管理员。数据管理员根据这些线索去修复原始数据。这样模型和用户一起，帮助水司把数据质量越修越好。
第四，关键数据人工复核。 对于涉及设备维修记录、水质超标事件、财务数据等关键信息，不要完全依赖模型的检索结果。模型可以作为快速查询工具，但正式报告或决策前，应去原始系统核对。
坑二：模型“一本正经地胡说八道”
现象
用户问：“东区管网的平均压力是多少？”模型回答：“根据资料，东区管网平均压力为0.32兆帕。”用户照着这个数据去做调度调整，结果发现实际压力是0.28兆帕。后来查明：模型检索到的是三年前的历史数据，但它没有说明是“历史平均压力”，直接当成了当前压力。
更隐蔽的情况：用户问“这个阀门是什么型号？”知识库里没有记录，但模型不想说“不知道”，自己编了一个型号——“Z45X-16Q”。看起来很专业，其实是假的。如果维修工照着这个型号去采购，就买错了。
为什么会踩坑？
- 大模型的本能是“生成流畅的答案”，而不是“保证每个事实都正确”
- 当知识库里没有答案时，模型倾向于“编一个合理的”，而不是承认不知道
- 用户容易被“格式工整、细节丰富”的回答误导，放松警惕
怎么应对？
第一，强制模型标明信息来源。 在模型设置里，要求每次回答必须引用来源（哪个文档、哪个数据库、哪条记录）。如果信息来自多个来源，分别列出。如果知识库里没有找到相关信息，模型必须回答“没有找到相关记录”，而不是自己编。
第二，对实时数据做特殊标记。 对于需要实时值的问题（如当前压力、当前流量），模型应明确提示用户“以下数据来自某某系统某时某刻的记录，请以现场仪表为准”。或者干脆不让模型回答实时数据类问题，而是引导用户去查看监控系统。
第三，关键决策人工确认。 凡是涉及调整加药量、开关设备、应急响应的建议，模型只能作为“参考意见”，最终决定必须由人来做。在系统流程上，可以设计“模型建议 + 人工确认”的环节，不能跳过。
第四，长期优化模型和知识库。 模型胡说八道的问题，会随着知识库的完善和提示词的调优而逐渐减少。但永远无法100%消除。所以要持续收集用户反馈，把发现的问题记录下来，定期优化。
坑三：员工不愿用——模型再好，没人用等于零
现象
系统上线三个月，后台数据显示：每天只有两三个人登录，问了几个问题就再也没来过。技术团队精心搭建的知识库、调优的模型，基本闲置。
深入访谈发现：一线员工觉得“问问题还不如直接去翻手册，手册我熟”；值班人员觉得“我已经干了二十年，不需要机器告诉我怎么调”；还有人担心“AI会不会将来取代我”。
为什么会踩坑？
全文见水之羿公众号
