商家AI助手平台(商家标签画像、LangGraph、问答数据资产建设)

PART 01

从经营问题到数据底座

这两天，一张外卖平台客服的截图在网上传开了。

有人跑去问 RAG 分块、CNN 和 RNN 的区别，也有人直接咨询 ESP32 开发。客服一边提醒先解决吃饭问题，一边给出学习路径。原本处理订单、退款和售后的入口，被网友临时玩成了一个“不限额大模型”。

网友热议的外卖平台 AI 客服

这个用法很有趣。

不过商家真正关心的是店铺里的具体事实：GMV 是多少，近七天退款为什么升高，某个 SPU 的下单量如何变化等。答案肯定不能让 AI 胡编乱造，数据应当来源真实的经营场景。

要让 AI 自动、准确地回答商家经营过程中的咨询，减少人工客服进线量，提高问题解决效率，同时优化平台客服资源的分配，模型只是其中一环。前面要有商家标签画像和明细数据，中间要有查询与流程编排，后面还要有记忆、校验和评估。

平台规则、开店流程、退款政策一类问题，可以继续使用 FAQ、规则库和知识检索。经营问题的处理方式不同。

“近七天退款金额是多少”需要查询退款事实表；“退款增长来自哪些订单”还要下钻到订单明细；“这些订单对应哪些商品”可能继续关联商品数据。问题从汇总指标一路走到原始明细，知识库无法直接给出结果。

商家身份也是查询条件的一部分。系统接到问题后，先确认当前商家及其数据权限，后续 SQL 必须携带 merchant_id。没有这层隔离，同一句“昨天卖了多少”就可能查到别的商家数据。

整套平台可以分成六个部分：

这六部分需要围绕同一套业务口径工作。标签名称、SQL 字段、Wiki 里的历史表达和最终回复如果各说各话，模型越流畅，错误越难发现。

项目先建设 ADS 商家 AI 助手前置标签画像资产，再处理 Prompt 和页面交互。

商家标签画像覆盖公司信息、订单交易、优惠券、客服、理赔、商家申诉、退货、供应链、商品审核等板块，累计沉淀 200 多个标签。标签除了名称和取值，还需要明确更新频率、数据质量基线和 SLA，并把核心任务提升到较高保障级别。商家助手每天都要读取这些数据，标签延迟或缺失会直接反映在回答里。

核心查询链路由 8 张明细宽表和 1 张商家标签画像宽表组成。明细数据涉及订单、退货、客服工单、赔付、优惠券、商品上架、商家申诉、保证金和供应链全流程等业务域。画像表适合快速判断商家的当前状态，明细表负责解释指标是怎样产生的。

这些数据同步到 Doris 后，按照更新和查询特点配置主键模型与倒排索引。主键模型用于维护同一 Key 下的最新记录，适合商家画像、订单状态等需要更新或去重的数据；倒排索引用于加速关键词、等值和范围过滤。系统生成 SQL 时由服务端统一注入商家 ID，不能让模型自行决定是否添加租户条件；条件允许时，还可配合 Doris Row Policy 和权限控制进一步限制可见数据。

画像表并不预先保存所有经营指标。例如商家询问近 90 天各 SPU 的下单量，ads_merchant_profile 里可能没有这个字段。系统会转到订单明细表，按 spu_id 分组统计，再把计算口径和结果一并返回。派生指标要能追溯到原始字段，不能让模型临时编出一个看似合理的值。

PART 02

LangGraph如何跑通经营问答

产品、研发和数据人员先把正常路径、异常路径、表选择规则和输出形式写清楚，再把流程交给 LangGraph 执行。主链路如下：

用户提问  ↓识别商家身份，加载商家画像  ↓抽取关键词，归一化问题，识别业务意图  ↓读取当前会话、历史问答和长期 Wiki  ↓判断简单问题、单域问题或跨域复杂问题  ↓选择业务分类、指标类型、明细类型和 Doris 表  ↓复杂问题生成 Plan，逐步执行查询  ↓按 merchant_id 过滤，取得 SQL 结果  ↓语义层核对问题、数据和准备生成的回答  ↓输出说明、明细表、指标图表和经营建议  ↓写入问答记录，接收采纳、点赞或点踩

MerchantQaLangGraph 负责主流程编排，WikiMemoryService 处理长期记忆压缩，SemanticLayerService 在输入和输出阶段做语义检查，AttachmentService 处理上传文件。模块分开以后，意图识别错误、表选择错误、记忆污染和结果表达偏差可以分别排查。

流程信息、数据表和异常分支确认后，可以在 Codex 中以 xhigh 推理强度生成 LangGraph 代码骨架。代码生成节省的是工程录入时间，业务规则仍由系统设计决定。后续出现新问题时，调整对应节点、路由和 Wiki，避免把全部规则继续堆进一个总 Prompt。

所有问题都交给大模型，响应时间和 Token 成本都会迅速增加。关键词抽取、固定问候、高频口径查询和简单历史匹配，可以由算法模型或规则模型处理；跨业务、需要多步取数的问题再交给大模型规划。

例如商家问：“找出这笔交易订单，再查它的退货时间和退货用户。”

这个问题跨越交易和退货两个业务域，执行顺序不能颠倒：

1. 在交易明细表中找到目标订单。
2. 取得订单号。
3. 把订单号作为下一步输入。
4. 在退货明细表查询退货时间和退货用户。
5. 合并两次查询结果后生成回答。

早期流程只能给问题选择一个业务分类，这类问题要么被错误归到交易，要么被错误归到退货。V2 增加 Plan 后，一次问题可以拆成多个串行步骤，上一步的结果进入下一步。每一步都有明确输入和输出，查询失败时也知道停在哪个节点。

日常打招呼可以直接回复，无效意图不会写入业务问答记录。SQL 执行失败、数据源不可用或问题超出平台能力时，系统停止生成经营结论，并引导商家提交客服工单。

经营问题大致分为指标查询和明细查询。

指标查询需要时间范围、聚合口径和维度。例如 GMV 可以按天、城市或商品统计，少一个维度都会改变结果。明细查询则要保留订单号、商品、用户、状态和时间等字段，适合使用表格展示。

一个指标在画像表中不存在时，系统先判断能否从明细表计算。能够计算，就生成对应 SQL，并把计算口径写入回答；无法计算或缺少必要字段，才进入失败分支。这样既避免把所有新指标推给人工客服，也不允许大模型凭语言常识补数据。

明细查询还要控制页面负载。在线结果最多展示 200 行，超过部分不继续堆在对话框里，而是生成 CSV 文件。页面保留摘要、字段说明和前 200 行结果，完整数据交给商家下载后继续分析。

这种限制也影响回答方式。查询返回明细时，模型不能把几百行记录概括成一个没有依据的结论；返回汇总指标时，也不能把单个总数写成趋势判断。

PART 03

如何让系统记得住，答得准

商家经营问题常常连续出现。上一轮问“近七天退款金额”，下一轮只说“把异常订单列出来”，第二句话里的时间范围和“异常”口径都来自前文。

当前会话需要短期记忆，长期使用还需要把有效问答沉淀成业务知识。早期版本虽然会把每次有效问答写入 merchant_ai_answer，但 Wiki 压缩只有调用 /api/wiki/compress 时才会执行。接口没人调用，历史问答就一直停留在数据库里，无法自动进入后续会话。

V2 把记忆沉淀改成独立任务。主问答完成后，记忆子 Agent 异步整理本轮问题、业务分类、使用的 Doris 表、语义备注、后续问题、CSV 结果和最终答案，再读取该商家近期约 80 条历史问答，压缩到对应业务域的 Markdown Wiki。用户先收到回答，记忆任务在后台继续执行，两条流程互不阻塞。

电商交易、电商退货、电商退款等业务域分别维护 Wiki。当前会话负责“这几句话在说什么”，长期 Wiki 负责“这个商家过去确认过什么口径”。稳定答案可以复用，失败结果和无效意图不能进入长期记忆。

运营人员还会人工补充历史问题和标准表达，用来覆盖刚上线时样本不足的阶段。现阶段“猜你想问”仍主要取自原始历史问题，没有完全切换到抽象后的 Wiki，这也是后续要继续修正的地方。原始问题容易重复，还可能把偶然问法长期保留下来。

系统在两个位置执行语义校验。

第一次发生在查询前，检查归一化问题是否保留了商家的真实意图，业务分类、指标、时间范围和维度是否完整。第二次发生在查询后，对照原问题、SQL 结果和最终回答，检查模型有没有扩大结论。

例如商家要求查看 7 月 9 日至 7 月 11 日各城市的 GMV，查询结果却只有 7 月 11 日的总 GMV，并且没有城市字段。此时能够确认的只有单日总量。系统应明确说明缺少另外两天的数据和城市维度，不能继续生成三日趋势、城市排名或异常判断。

数据维度不足时，系统明确说明无法完成分析

如果输入意图和最终结果不一致，语义层会带上当前 Session、历史记忆和关键词识别结果再分析一次。新词可以补进语义层，避免同类表达反复识别失败。重试次数需要限制，二次识别后仍无法确认，就返回失败提示，不能在循环中持续消耗 Token。

语义层的价值不在于把回答润色得更像人，而是让一句话里的每个判断都能在查询结果中找到依据。

PART 04

从问答页扩展为经营工作台

V2 处理的是记忆、跨域查询、指标派生、结果上限和答案可信度。V3 继续处理前端交互和多模态输入。

页面从单一对话区域扩展成三栏工作台。左侧可展示满足可视化条件的指标图表，中间保留问题处理步骤、自然语言回答和明细表，右侧显示经营建议与“猜你想问”。对话区增加目录导航，背景、按钮图标和整体布局也重新整理，长回答不再只能在一个窄窗口里上下翻找。

一次自然语言查询返回经营数据、明细和建议

图表由结果字段决定。包含连续日期时可以使用折线图，适合比较构成比例时使用饼图，分类指标对比可以使用柱状图。数据只有一个总数、缺少时间序列或分类维度时，左侧不应硬画一张图。

输入框支持图片、PDF、Excel 和 CSV。图片及扫描 PDF 先做 OCR，再由语义层识别其中的问题、订单号或指标；表格文件解析字段后，可以和已有经营数据一起查询。

附件解析独立于主问答流程，解析失败时只返回文件处理错误，不让错误内容继续进入 SQL 生成节点。

商家助手除了被动回答，还会在每天 10 点读取商家标签画像，推送昨日经营数据。

首页展示 GMV、总订单量、交易成功订单量、退货量和退货金额等核心指标，再结合近 7 天数据生成两条经营建议。商家可以直接采纳建议，也可以继续追问某个指标，进入明细查询。

商家 AI 助手首页与昨日经营日报

主动推送和问答使用同一套指标口径。日报显示的 GMV 与对话里查询出的 GMV 如果来源不同，商家很快会失去信任。建议是否被采纳也要回写记录，作为后续评估数据。

PART 05

用评估数仓形成迭代闭环

每次有效问答落入 MySQL，再经过数据集成进入数仓，形成 DWD 商家 AI 助手问答记录表。评估看板关注回复采纳率、回复准确率、平均思考时长、问题命中率和回答失效率。

这些指标分别回答不同问题：

• 采纳率反映商家是否愿意使用这次结果。
• 准确率检查答案与标准结果或人工校验是否一致。
• 平均思考时长反映链路性能和复杂问题成本。
• 问题命中率检查意图是否进入正确业务域。
• 回答失效率统计查询失败、数据不足和语义校验未通过的比例。

项目经过多轮 LangGraph 调整后，阶段性记录中的回答采纳率达到 83%，准确率提升到 81%，回答失效率由 32% 降到 5% 以内。这组数字来自当前项目的测试和迭代过程，意义在于说明失败问题能够被记录、分类并继续修正。

模型效果因此不再依赖几条精心挑选的问答截图。某类问题连续点踩，可以回查关键词和业务分类；明细查询频繁失败，可以检查 Doris 表和字段映射；答案与 SQL 不一致，可以定位语义层和生成节点。

商家 AI 助手的落地顺序很重要。

先确定商家能查哪些数据，建立标签、明细表、质量监控和租户边界；再设计问题进入系统后的节点、路由和失败分支；随后加入短期记忆、长期 Wiki 和语义校验；页面交互、附件和主动推送建立在这条稳定链路之上；问答记录进入数仓后，系统才具备持续改进的依据。

网友可以把外卖客服当作通用大模型来玩，但经营问答仍要由大模型理解问题，再由数据库提供真实、可核验的数据。

Y Data 已将相关代码、表设计、V2/V3 问题记录和交付 Demo 整理进知识星球，对应项目为《项目专项65-商家AI助手平台（商家标签画像、LangGraph、问答数据资产建设）》，适合准备把大模型接入真实经营数据系统的同学继续研究。

我是语兴，关注语兴数据，从数据侧拓展 AI 视界。