和chatBI打了这么久交道，今天想来聊聊在产品研发时在设计理念上的一些误区，希望我的这些经验能让大家避免“踩坑”。
误区一：没有设计错误处理机制
这是我当初在产品设计初期时踩过的一个很影响用户体验的坑。因为没有这些机制，常常出现使用时回复结果一直在“转圈圈”或者根本没有结果返回，场面一度非常尴尬。除此之外，有一些非“错误”型的问题也会导致以上很尴尬的场景出现，比如用户配置错了数据表，但是因为没有合理的回复和错误处理机制，让用户质疑我们的产品能力，进而放弃使用。
用户对产品的感受很多时候其实就是很主观的，当频繁的看到一些不合理的地方，就会放弃。我们要做的，是要给他们一种直觉，就是即便出错，也是有相应的优化方向的。
常见的报错集中在：
SQL生成错误
大模型语义理解错误
其他的技术层面的错误，比如内存溢出等
那如何在成本和效率都合适的情况下设置错误处理机制呢。我建议：
1. 在SQL生成那步增加错误重试机制，可在SQL执行失败时将原始SQL、表结构、错误信息一起提交给大模型，进行修正并重新生成；
2. 将各环节的报错信息下游都接入一个大语言模型，分析具体的问题类型，并返回用户友好的回复
误区二：日志只记录到结果，缺乏全流程跟踪
没有日志这件事我是特别慌张的，日志没有，掉坑都不知道是什么坑，尤其是在无法看到用户实际测试或使用过程中的详细日志。无法定位和还原问题现场，产品就没办法进行有效的迭代优化。当大家在各类产品中进行筛选的时候，要注意这一点。
以dify为例，它提供了详细的日志跟踪功能，可以追踪到每一个节点，包括用户的输入、模型的响应、中间处理步骤等。这种全链路日志不仅方便开发和运维人员快速定位问题，也有助于分析用户行为、优化产品体验。
建议日志系统要覆盖整个流程，从用户输入、模型推理、SQL生成、数据库查询到最终返回结果，每一步都要有详细记录。然后你就能看到很多让人苦笑不得的报错，比如大模型没钱了啊，网络不好啊，由于缺乏表结构的输入大模型在自己YY啊
误区三：不做数据治理就上线
数据治理这件事，真的是很多团队容易忽略的大坑。实际项目中，常常听到这样的对话：
“项目交付急，先把东西搭起来再说，数据反正都在那儿，你直接用就行。”
“我们的数据挺干净的，不用专门治理，没什么脏数据。”
但现实远比想象复杂。数据治理也绝不是简单的“清理脏数据”那么一条。
这里我们要理解数据治理的原因是要让大模型理解并且获得精确的结果，比如字段名为“name”或者“姓名”，这种具有意义的字段名，大模型可以很好的理解。但是如果字段名叫“bmmc”，大模型是很难推理出这个字段叫“部门名称”。亦或者如果数据类型全都是string, 你就不能期待LLM去生成与数值运算相关的SQL。在我的实际经验中其实很多的问题都来自于这个环节，在某种程度上决定了产品能力的上限。
大模型辅助数据治理是一个非常好的思路，也欢迎大家一起来讨论。
误区四：太依赖大语言模型，忽视工程上的发力
我们总说大语言模型时代，但是这并不意味着我们就可以完全抛弃那些小模型。一个完善的对话分析流程往往是多环节、多路径协同的，比如意图识别、维度值检索、指标检索、模式链接、意图拆解、意图改写等。如果每一步都用大模型，不仅响应时间长，成本也会飙升。
更高效的做法，是冷静地选择合适的技术：
误区五：没有真实需求，场景设计脱离实际
这种“拍脑袋”上项目的情况，遇到过太多次了。前期说得头头是道，等到真正对接落地时，需求却完全变了样。很多时候，产品团队还没搞清楚到底是给谁用、用在什么场景下，就匆匆忙忙推进开发，结果做出来的东西没人用，或者根本不符合实际需求。
产品设计初期想清楚“给谁用”“用在哪”，开发的时候遵从敏捷开发原则，并注重反馈和优化机制。如果这个问题想不清楚，就问到清楚为止。
误区六：销售说“能用就行”
这一点真的要给大家提个醒。销售同事有时候为了快速推进项目，常常有“先糊弄一个能用的就行”的大胆言论，但作为研发，我们更要关注产品的可用性和长期价值。前台和后台的关注点不同，销售要的是速度和成交，研发要的是质量和口碑。
年轻的时候我也听过不少这样的建议，结果出了问题，客户第一时间找的还是研发负责人。遇到这种情况，多问一句、多想一步，时间允许的话，还是尽量把产品做到尽善尽美。毕竟，只有真正好用的产品，才能赢得用户和市场的认可。
大语言模型无疑带来了革命性的技术变革，但我们也要时刻保持清醒。当前的生成式大语言模型依然存在不少局限，本质上它是一个概率模型，并不适合处理那些需要高度确定性的任务，比如精确计算等。在很多具体场景下，小语言模型也有“小而美”的优势，比如意图识别、模式链接等任务，用小模型反而更高效、成本更低。
理性看边界，冷静用优势，融合多技术，才能真正把 AI 的价值用到极致，而不是用到翻车。
粤ICP备14082021号
免费POC，
零成本试错
