某公司的数据智能实践

凯先生

分享一下在数据智能产品建设中的实践和思考。

一、从数据工具到业务助理的演进之路
1.0 阶段：一站式数据服务平台对于一家房产经纪平台公司，将平台运营策略有效传递到这些门店和经纪人的关键角色，是区域经理。每位区域经理通常负责十几家到几十家门店，需持续关注这些门店的房源、客源是否充足，经营业绩是否有异常波动，哪些门店和经纪人需要重点跟进等，这些都离不开数据的支撑。
过去建设的驾驶舱重点服务管理层，对区域经理这一群体的诉求关注度不够。区域经理往往需要从多个系统、多处报表手动整合数据，耗费很多时间在数据查找和加工上。所以，我们的初期目标非常明确：为其量身打造一个一站式数据服务平台，真正做到“你想要的数据，这里都有”。
2.0 阶段：自助问答取数随着数据分类更合理，指标更丰富，看板更直观，我们初步实现了数据的统一获取，用户不再需要四处找数。但随着数据量持续增长，核心指标虽易于查找，那些不常用的长尾指标却往往埋藏在较深的菜单中，用户体验并不理想。
随着大模型能力的显著进步，意图识别、槽位提取、实体消歧、任务拆解、可视化呈现等关键环节都具备落地条件，以自然语言问答直接定位用户所需数据、并支持表格、柱状图、趋势图等多种呈现形式的ChatBI产品应运而生。
值得一提的是，我们面临两条技术路线的选择：NL2SQL和NL2API指标。NL2SQL更为常见和灵活，但我们选择了NL2API，先卖个关子，后面再解释。
3.0 阶段：业绩分析诊断至此，用户既可通过数据驾驶舱获取数据，也可通过直接提问得到结果。然而，数据本身只是原材料，看数的本质是为了分析。“门店经营状况如何？哪些方面做得好、哪些存在不足？具体是哪些人员或环节导致问题？应如何提升？”——此类问题仍无法得到良好的应答。
回答这些问题的核心在于分析思路的沉淀。类似杜邦分析，我们在各业务板块沉淀了自己的分析框架，并针对典型业务问题整理了对应的策略和知识库。在AI产品化层面，我们采用了与当前主流实践相近的方案（RAG + Function Calling + 人格化输出），从而实现对业务情况的自动分析与问题监测，帮助区域经理更快总结业绩、发现问题并推进解决。

4.0 阶段 业务助理至此，我们完成了一款功能丰富的数据运营工具，也收获了积极的用户反馈。但随着对用户工作场景的深入调研，我们发现，即使分析结论和问题预警也并非数据的终点。
举个例子，区域经理有一项关键任务——巡店。系统能否自动生成巡店建议，例如新开门店或业绩连续下滑门店？到店后，能否自动生成详实的门店分析报告，涵盖业绩概览、核心问题、各业务板块表现等，省去区域经理手动加工过程？更进一步，能否实现数据的个性化自动推送、汇报材料的自动生成？这些，才是数据应用的真正终端。
至此，我们的产品不仅是一款数据工具，更是一位贴心的业务助理，将用户从繁重、重复的数据处理中解放出来，直接提供所需结论与材料，从而专注于沟通与决策本身。

二、为什么AI助理产品是更先进的产品形态
回顾这四个阶段：
1.0 阶段如同早期门户网站，聚合信息但交互有限；
2.0 阶段类似搜索引擎，实现精准检索；
3.0 阶段则如专业顾问，提供分析建议；
4.0 阶段已成为真正的工作助理，主动规划、预判需求、提供终端服务。
产品形态的演进，以及我们选择NL2API而不是NL2SQL，核心原因在于数据规模爆发带来的复杂度飙升。如果仅面对几张表、几十个指标，搭建一张精美的数据看板足矣。但是，大规模的数据体量，对查询性能、数据准确性、运维成本都提出了极高要求。
这正如管理一家10人公司与10万人公司的区别：前者靠喊话就能协调，后者则必须依靠完善的架构与流程。
大家是否想过，论生活水平，我们比古代历代帝王都要高，但很多职场人过得并不开心，自嘲为“牛马”。核心原因在于没有人帮我们分担掉那些琐碎的、价值度不高的事情。如果能够只把心思花在战略规划、业务决策、真正创造性的工作上，不喜欢做的事情都交给助理完成，大家的工作体验和效能一定会显著提升。这也是我们把最终产品定位为“业务助理”的核心逻辑。
在过去，只有高管才会配备助理。而上位者和普通人最大的区别，就在于掌握更多的资源。如果能把过去上位者验证过的需求，通过新技术降低成本，下放给普通人使用，就存在巨大的市场机会。人形机器人之于保姆、自动驾驶之于司机，甚至孙正义那套 Time Machine理论，我认为也是同样的逻辑。

三、结语
每一次技术变革的本质，都是将曾经稀缺的资源转化为可规模化提供的服务，我们在数据智能领域的探索，正是这一逻辑的印证。
我也想要一个助理。
本文由 @凯先生 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议