- 博客(1208)
- 收藏
- 关注
RSS订阅原创 为分析助手实现比较周期澄清
这个月表现比上月怎样？”月初第七天，助手拿本月7天与上月整月比较，下降几乎是预定结果。即使都取7天，星期分布、节假日和数据完整性不同，也可能让比较失去意义。周期澄清的任务，是先把两把尺子放在同一张桌子上。本文从零搭一个比较窗口合同。所有日期方案都是教学示例，具体采用哪种，取决于要回答的业务问题。
2026-11-05 14:31:34
12
原创 让 Text2SQL 从指标定义生成退款关联查询
一笔100元订单，退了10元又退20元，净额应该70元。查询却给出170元？这通常不是减法错误，而是订单与两笔退款连接后，100元出现了两次。Text2SQL若不知道两张表的粒度，很容易写出语法正确、金额翻倍的SQL。以下用构造示例从零搭建退款关联：订单A金额100，退款R1为10、R2为20。目标是在订单粒度得到退款30、净额70。
2026-11-05 14:30:15
31
原创 给自动分析报告接上异常样本引用
异常可能是缺失必填字段、金额为负、超出业务允许范围，或统计模型检测到的偏离。不同类型证据不同，报告应引用规则标识、版本、运行时点和目标集合。不能让模型看完数据后临时挑五条“比较怪”的记录，再声称这是固定规则的异常率。本例5条是全部命中的异常，不是从异常中再抽5条。真实场景如果异常有5000条而只展示5条，必须同时记录全量命中数、展示样本数和抽样策略。优先挑最严重的样本可以用于排查，却不能代表典型分布。
2026-11-05 14:29:01
31
原创 让分析助手为缺失数据波动解释列出可检查假设
昨天收到90条完整记录，今天只收到60条，助手说“业务量下降三分之一”。这句话少了一个前提：收到的记录能不能代表实际发生的业务？如果源端两天都应有100条，只是采集链路变差，下降发生在数据可见性，不是业务本身。本文用这组构造数据，从零搭建缺失波动解释流程。90和60都指已收到且关键字段完整的记录数，源端期望总量各100；真实系统只有获得可信源端对账后，才能知道期望量。
2026-11-05 14:27:47
15
原创 让图表助手输出缺失值展示检查的可解释意见
一条四天的折线，数据是10、缺失、0、12。如果前端把缺失自动填成0，图上就多了一次根本没有证据的归零；如果直接删掉缺失那天再连线，又可能让读者以为趋势连续。图表助手需要检查的不是“有没有空值”，而是空值被表达成了什么。本文用这组构造数据，从数据状态、绘图策略到检查意见搭建一个最小流程。第二天未知，第三天是真零，两个状态不能共用同一种含义。
2026-11-05 14:26:31
34
原创 为分析助手实现新老客定义澄清
用户问“拉新活动效果”，可能想看注册；问“新增购买者”，通常需要首购；问“某品类新客”，则可能已经买过其他品类。助手先列出目录中存在的定义，再用具体例子追问：“10月注册、11月首次支付的人，在本报表里是否算11月新客？”这个问题比“请选择生命周期定义”直观得多。契约至少包含身份实体、首次事件、事件成功状态、业务范围、时间窗口和可见历史。身份实体是账号、手机号还是统一客户ID，会改变去重结果；首次事件是支付成功还是最终未退款订单，也会改变首购日期。同一用户在全站可能是老客，在某品类却是新客。
2026-11-04 20:56:48
78
原创 让 Text2SQL 从指标定义生成多币种汇总查询
100美元加100人民币，能不能得到200？数学当然能相加，业务金额却不能丢掉单位。Text2SQL写出很容易，真正困难的是知道哪些金额允许放进同一个篮子。本文用构造汇率说明实现流程：100 USD按示例汇率7.0 CNY/USD换成700 CNY，再加100 CNY，合计800 CNY。7.0仅为教学示例，既不是实时汇率，也不是任何财务政策建议。
2026-11-04 20:55:34
168
原创 给自动分析报告接上指标计算引用
转化率20%”这句话很短，背后可能是20个支付用户除以100个有效访客，也可能是20笔订单除以100次会话。自动报告只引用一个百分比，读者看不到集合与公式，争论就会从这里开始。下面使用构造示例：符合资格的访客100人，其中去重支付用户20人，转化率20%。目标是搭建一份指标计算引用，让文字、公式和原始集合之间有清晰的连线。
2026-11-04 20:54:27
109
原创 让分析助手为退款集中回补解释列出可检查假设
某天退款突然冲高，助手很容易写“用户不满意导致退款增加”。可如果三天的退款集中在一天入库，图上的尖峰属于数据到达节奏，未必属于用户行为。先把退款成功时间和入库时间拆开，很多故事就不必急着写。以下是构造示例：11月1日、2日、3日每天成功退款10元，三笔都在11月4日入库。按业务日看每天10元，按入库日看11月4日30元。两张图都可以是真实的，却回答不同问题。
2026-11-04 20:53:16
160
原创 让图表助手输出类别遗漏检查的可解释意见
图里只有A、B两个类别，是因为业务只有两类，还是C、D被悄悄漏掉了？没有参照集合，助手看着一张图很难知道少了什么。类别遗漏检查的第一步，是把“应该有哪些”从业务字典与查询范围中拿出来。下面是构造示例：有效类别全集为A、B、C、D；查询结果只有A、B、C；图表最终只画A、B。数据层漏D，展示层漏C，这是两道不同的问题，不能只给一句“图例不全”。
2026-11-04 20:52:00
109
原创 为分析助手实现渠道归因范围澄清
示例旅程为广告点击、自然搜索、支付。首次触点模型归广告，末次非直接触点模型归自然搜索。两套规则各自分配100%的订单价值，不能把两份报表相加得到200%，更不能据此宣称两个渠道各自创造了一笔订单。澄清对象包括转化事件、归因单位、触点范围、回溯窗口、直接访问处理、身份拼接和价值分配规则。转化可以是支付订单，也可以是首购用户；单位变了，归因数量也会变。窗口长度同样需要明确，它决定哪些更早的触点有资格参与，而不是越长越准确。
2026-11-03 23:47:20
144
原创 让 Text2SQL 从指标定义生成缺失渠道分组查询
渠道报表合计80单，订单总表却有100单，最先该查的未必是退款，也可能是那20单没有渠道。NULL、空字符串和几个空格，在数据库里不是一回事；到了业务报表里，它们又可能都表示“暂时不知道”。Text2SQL需要的是明确的缺失政策，而不是一句“按渠道统计”。本文用构造数据从零实现清洗与分组：广告30单、自然50单、NULL10单、空字符串5单、纯空格5单。期望输出广告30、自然50、未知20，总计100。
2026-11-03 23:46:05
153
原创 给自动分析报告接上图表结论引用
报告说“B比A增长10%”，旁边放了一张柱状图，就算有证据了吗？还差几步：图里A和B各是多少、过滤了谁、图版本是否变过、增长公式是不是这两个点算的。截图能证明当时长什么样，却不能独自承担计算依据。下面以构造数据A=100、B=110实现一条图表结论引用链。目标是让读者从文字点回图中的具体数据和定义，不必在十张图之间寻找那句结论到底从哪来。
2026-11-03 23:44:54
150
原创 让分析助手为渠道结构变化解释列出可检查假设
总体转化率涨了，渠道经理都说自己没改什么，哪里不对？可能谁都没说错。高转化渠道占比变大，即使每个渠道自身转化率不动，总体也会上升。分析助手要先把这层算术关系拆开，再讨论为什么结构变化。以下为构造示例：渠道A转化率一直10%，渠道B一直2%。第一期A访客占20%、B占80%，总体为3.6%；第二期A占80%、B占20%，总体为8.4%。增长4.8个百分点，没有任何渠道内转化改善。
2026-11-03 23:43:43
193
原创 让图表助手输出分母变化检查的可解释意见
转化率从20%降到10%，第一反应往往是“成交变差了”。可如果成交人数一直20，访客从100变200，变化主要发生在分母。对业务来说，这可能是新增了大量低意向流量，也可能是分母定义改了。图表助手需要把百分比拆回人数，才有资格提出解释。下面使用构造示例实现分母变化检查：第一期20/100，第二期20/200。我们先确认计算，再给出有依据的审阅意见。
2026-11-03 23:42:28
229
原创 为分析助手实现退款归属日期澄清
示例契约可包含as_of与币种。退款申请时间、审批时间和成功时间不一定相同，必须由业务定义指定。被拒绝的申请不应自动减少成功支付额。as_of尤其重要。11月2日还看不见11月3日的退款，所以“截至11月2日的11月1日净额”是100，而“截至11月4日回看的11月1日净额”是80。若用户要复现旧日报，助手应携带当时的数据快照或可见时点，而不是用今天的最终状态改写当年的知识。实现上可以维护一个选择表：任务为订单批次表现，推荐支付日归属；任务为日常退款处理规模，推荐退款成功日；
2026-11-02 12:42:32
997
原创 让 Text2SQL 从指标定义生成跨日成交查询
23点59分下单，第二天0点02分支付，这笔成交算哪天？如果用户说“看今天成交”，模型很可能顺手用created_at；如果仓库存的是UTC时间，它又可能直接截取日期。两步都很自然，两步也都可能偏离业务定义。让 Text2SQL 可靠处理跨日成交，需要把时间语义先写成契约，再把契约翻译成边界查询。本文使用构造订单和 PostgreSQL 语法，默认成交按支付成功时间、上海业务日归属。
2026-11-02 12:41:21
1112
原创 给自动分析报告接上数据时点引用
同一天的订单数，早上查90单，隔天查100单，自动报告该引用哪一个？如果报告只写“11月1日订单数100”，读者无法知道它是在11月2日还是11月3日看到的数据。对会回补、会修正的数据，业务日期只回答“事情发生在哪天”，还缺“我们什么时候知道”。下面用一组构造示例搭建数据时点引用。11月1日最终有100条记录，11月2日08时只入库90条，11月3日08时补齐100条。两次查询都可能如实反映当时仓库，但不能互相替代。
2026-11-02 12:40:07
1392
原创 让分析助手为小样本异常解释列出可检查假设
某个渠道昨天5个访客成交1人，转化率20%；另一个渠道100个访客成交20人，也是20%。如果助手据此给两个渠道同样确定的评价，问题就来了：前者多一人成交，转化率立刻变成40%，后者多一人只到21%。百分比一样，信息量不同。本文用构造示例实现一份“小样本异常检查单”。目标不是给小渠道贴上不可信标签，而是让助手把不确定性、数据问题与可验证业务假设分开，避免看到一个跳点就写故事。
2026-11-02 12:38:54
1210
原创 让图表助手输出坐标轴截断检查的可解释意见
A是98，B是100，柱子的高度却看起来差了三倍。先别怀疑数字，看看纵轴是不是从97开始。图表助手检查坐标轴截断，不能只背一句“纵轴必须从零开始”，它需要知道图表用什么视觉元素表达数量，以及读者会怎样比较。本文的98和100是构造示例。我们从图表配置与底层数据出发，实现一个能说明理由、给出修改建议的检查过程。
2026-11-02 12:37:46
1192
原创 给自动分析报告接上查询版本引用
自动报告写着“本期净支付额增长10%”，读起来很顺。两天后有人重新运行查询，结果变成8%，报告就像一张没有日期的购物小票：能看见总价，却不知道对应哪次结账。给报告接查询版本引用，解决的是这种追查困难。这里所有编号、金额和版本都是构造示例。设上一期100元，本期110元，报告增长10%。我们要保留的不是一个“SQL见附件”链接，而是从这句话走回产生它的查询、参数和结果的路径。
2026-11-01 19:51:19
1257
原创 让 Text2SQL 从指标定义生成重复订单去重查询
一张订单表里出现三行相同订单号，应该删掉两行吗？先别急。可能是消息重发，也可能是状态更新，还可能是三个商品明细。把这些都叫重复，像看见三个同姓的人就认定是一个人，省事归省事，结果往往不太妙。让 Text2SQL 生成去重查询，关键输入不是“请使用 DISTINCT”，而是数据一行代表什么、业务主键是什么、哪一条记录有效。以下表结构和数值均为构造示例。
2026-11-01 19:50:08
1348
原创 为分析助手实现销售额口径澄清
帮我看一下昨天销售额。”听起来只有一句话，里面却塞着一整袋没拆封的条件。是下单金额、支付金额，还是扣过退款的金额？按哪一个时区算昨天？优惠券由谁承担？如果分析助手直接挑一个字段求和，它可能把 SQL 写对了，把问题答偏了。我是朱大喜。给这类助手加能力，我更愿意先教它问一句有用的话，再教它写十种查询。问得好，像买菜时先确认是毛重还是净重，后面称得再精确才有意义。
2026-11-01 19:48:56
1389
原创 让分析助手为季节性波动解释列出可检查假设
周末又涨了，应该是季节性。”分析助手很容易写出这样一句话。问题是，周末恰好也可能做了促销、补了数据、调整了渠道预算。看到重复的峰，最多说明值得检查周期模式，不能直接把原因填进报告。我是朱大喜。讲季节性时，我喜欢把它比成公交站：每周同一时段都挤，确实可能有固定通勤节奏；但今天突然特别挤，也可能是前一班车没来。模式和解释，要分开拿证据。
2026-11-01 19:47:44
1334
原创 让图表助手输出汇总粒度检查的可解释意见
两家店的客单价分别是100元和20元，连起来求个平均得到60元，看着没有语法错误。可如果第一家只有1单，第二家有9单，总体客单价其实是28元。图表助手若只检查图是否好看，就会把一张漂亮的误导图送上看板。下面都是构造示例。门店A销售100元、1单，门店B销售180元、9单。总体是280除以10；门店客单价的简单平均，则回答“随机挑一家门店，其客单价平均多少”。两个问题都可以问，只是不能拿后者回答前者。
2026-11-01 19:46:31
1361
原创 十月的 Text2SQL 选型笔记：先固定任务，再比较模型和数据库
这个月的数据工具新闻不少：DuckDB 2.0 发布，ClickHouse 介绍新的查询能力与 Agent 评测，类型化模型调用也开始更自然地进入 SQL 工作流。很容易一口气得出“该换一套工具”的结论。我更想先写清楚自己的问题是什么。这是一份基于已公开资料的十月选型笔记。它不是年终盘点，也不预言月底还会发布什么。不同工具的能力可以放在一起讨论，但不能把不同任务、不同引擎、不同预算下的成绩排成一张统一榜单。
2026-10-31 23:07:12
1280
原创 根因分析的四步：先把猜测改写成能够被推翻的判断
可能是渠道质量变差了”，这是一句常见解释，也是一句很难直接验证的话。渠道质量具体指什么？预期会影响哪类用户？如果不是它，我们会看到什么？没有这些问题，根因分析容易变成给曲线配故事。我的四步习惯是：先核对数据，再拆指标，再切人群，最后安排能区分解释的验证。它不是某种模型独有的思维过程，也不保证每次都找到唯一根因。
2026-10-31 23:06:03
1346
原创 一张看板放进不同屏幕：先决定阅读顺序，再分十二列
把桌面上的三栏看板缩到手机里，最容易出现的不是样式难看，而是阅读顺序混乱。指标卡先后颠倒、筛选器藏到详情后面、关键解释被截断，用户就得重新理解整张页面。我通常先写语义顺序：总览、关键异常、原因切片、明细。屏幕变宽时可以把部分区域并排，变窄时仍按这个顺序排列。十二列网格只是布局工具，不能替我们决定什么信息更重要。
2026-10-31 23:04:56
1338
原创 让分析 Agent 提建议，也让执行动作有独立的授权票据
从“这条指标异常”走到“我已经替你改好了”，中间不该只隔一句肯定回答。分析、建议和执行分别需要不同的证据与权限。一个能读报表的 Agent，不应因此自动获得修改业务状态的能力。10 月 9 日 Anthropic 的非预期模型动作调查，讨论了模型越过任务边界的具体案例。这不是所有 Agent 都会失控的证明，却足以说明：授权最好由系统检查，不能只让模型在文本里承诺遵守。
2026-10-31 23:03:50
1253
原创 十月笔记准备怎么收尾：留下复现步骤，也留下还不知道的事
写给月底的这页笔记，我想先给自己定一个收尾方式：不拿文章数量代替学习，也不把尚未发生的工作写成漂亮复盘。哪些东西确实读过、哪些例子确实跑过、哪些问题还停在设想里，分别记清楚。这份月底安排可以随真实进展更新。今天能确认的，是已经公开的资料和手头能验证的小例子；接下来几天的业务结果与产品发布，不能提前填写。
2026-10-31 23:02:40
1335
原创 ChatBI 缓存命中之前，先确认这份答案还能给这个人看
缓存最迷人的地方，是下一次可以少做很多工作；最容易被忽略的地方，是“下一次”未必还是同一个问题。租户变了、授权范围变了、指标升级了，文字看起来相同，答案却不应复用。10 月 7 日发布的 Claude Haiku 5.5 面向高频、成本敏感的任务，这类发布会让人重新计算模型调用账单。但选更便宜的模型和做好缓存，是两件需要分别验证的事。不能拿供应商的定位直接证明自己的工具已经省下多少钱。
2026-10-30 13:18:34
1407
原创 SQL 自动修复最多再试一次：把停止条件写进程序
封面的参数化改写仅是独立示意，还需要绑定参数；下方程序只模拟受限拼写修复，不具备自动修补任意 SQL 注入的能力。SQL 报错后，让模型根据错误信息修改一次，是很自然的功能。但如果每次失败都把更多 Schema、更多样本和更多权限交给它，原本的小修复就会变成没有边界的探索。近期分析 Agent 基准把工具预算作为评测条件，提醒我们“最终答对”不能脱离过程成本和允许动作。对于业务取数，我更愿意先做一个有明确停止点的流程：第一次执行，失败后只允许一次候选修复；
2026-10-30 13:16:38
1352
原创 预测带不是承诺：给容量讨论留出误差的位置
业务同事问“接下来会有多少请求”，我不想只交一条很光滑的线。点预测看起来明确，却容易被当作承诺。更有用的表达，是同时说明参考范围、历史误差、数据质量，以及超出范围时怎么办。这里不预测任何尚未发生的具体业务结果。下面的数字是手写序列，用来说明：评估预测时，不能先看见测试段，再回过头调整基线。真正的大促流量还可能受活动规则、渠道投放和系统容量影响，普通日常序列未必能代表它。
2026-10-30 13:14:29
1420
原创 实时大屏断线后：保留最后观测值，也要把“未知”显示出来
大屏断线后，是清空所有数字，还是继续显示最后一次结果？两种选择都有合理场景。真正容易误导的是第三种：继续展示旧值，甚至自动延伸曲线，却不告诉读者数据已经停止更新。我的做法是把数据状态和数值分开。最后观测值可以保留，但标出对应时间与“已过期”；如果要给出估计，必须使用独立标识，说明生成方法。不能让估计值接在实线后面，伪装成刚到达的事实。
2026-10-30 13:12:35
1375
原创 ROAS 漂亮的时候，也把退款、履约和毛利翻出来看看
看到投放看板上的 ROAS 上升，我会先高兴一下，然后再翻另一页。收入与广告费的比值可以回答一个问题，却不能自动回答“这笔生意赚不赚钱”。退款、商品成本、履约成本和其他费用，可能都还没进画面。我不想把这里写成某次已经结束的活动复盘。接下来业务窗口的结果还没有发生，先把看板口径准备好，更实际一些。六张经营卡是并列关注点，不是全部由收入减成本推导的指标；图标表示主题，不代表真实经营数据。
2026-10-30 13:10:20
1427
原创 Schema 剪枝有没有进步？把同一批问题成对比较
给 Text2SQL 减少 Schema 信息，不只是把提示词变短。删掉无关表可能降低干扰，也可能恰好删掉一张连接桥表。最后该不该上线，需要看相同问题在改动前后分别发生了什么。10 月 20 日的 Agentic Analytics Benchmark 第二轮包含 201 个合成分析问题。它不是我们的生产验收集，也不能借它的结果给自己的剪枝器背书。我更想借用它对任务、引擎、工具预算和答案比较规则的明确约束：条件不固定，提升就很难解释。
2026-10-29 22:26:30
1199
原创 定金转化率怎么算：下单人数、付款人数和订单数别混在一张卡里
封面的 1000 名访客、80 名付款者、120 笔订单为另一组示意数据，不是真实活动战报；PAYER 在本文指符合条件的定金付款用户。正文以下面四名访客的小样本演算。大促准备期的看板很容易塞满“转化率”：访问到下单、下单到付定金、定金到付尾款。它们名字相似，分子和分母却不相同。如果一位用户下了两笔订单，按人数和按订单统计就会得到不同结果。我会先问三个问题：观察的是人还是订单，进入分母的条件是什么，事件是否在相同业务窗口内。具体活动规则和支付状态还要以实际业务定义为准，不能从一个字段名猜出来。
2026-10-29 22:25:03
1136
原创 图表组件不该只接一个数字：把单位、版本和状态一起交给它
value: 88对组件来说很简单，对读者来说却远远不够。88 元、88 人和 88% 不是同一件事；上一小时的数据、正在重算的数据和已经确认的数据，也不应长得一模一样。我更愿意把图表输入看成一个小契约。数值之外，至少要有指标标识、单位、数据版本、实际观测时间和状态。标题可以改写，口径与版本不能只藏在某个开发者的记忆里。
2026-10-29 22:23:42
1229
原创 订单看板亮着的时候，分析师也需要知道自己负责哪一段
屏幕上的数字在刷新，很容易让人产生一种错觉：只要看板没报错，业务链路就都正常。其实订单接收、支付回调、库存扣减和分析汇总，可能属于完全不同的系统。分析师看见的是其中一段，不是全部。我想把这件事写在重要业务窗口之前。它是一份准备清单，不是提前完成的值班故事；没有虚构某个深夜的成交额，也没有让 Null 替我盯盘。
2026-10-29 22:22:03
1400
原创 自助取数率从 18% 到 88%：先说明分母，再写提升幅度
自助取数率提高了”听起来是个好消息，但我会先看这句话怎么算出来的。分母是所有咨询、符合自助条件的请求，还是登录过工具的人？一个问题反复尝试三次，算三次成功还是一次解决？只要口径稍微变动，曲线就能变得很好看。10 月 16 日 Anthropic 的工作变化研究来自其内部环境，讨论了工作方式与注意力的变化。它可以启发我们观察工具使用，却不能作为任何一家公司的效率保证。看自己的 ChatBI 是否有用，同样需要自己的可追溯口径。
2026-10-29 22:20:29
1222
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人