8 万多家商户沉淀了 TB 级交易数据，却几乎没有被用起来。Olsera 在 MOI 上构建商户分析助手，用 Medallion 分层数仓配合 NL2SQL 与 RAG，让商户直接用自然语言问经营问题。
Olsera 是印尼领先的 POS 与经营管理平台，服务 8 万多家零售商户，覆盖餐厅、零售门店等多种业态，平台上沉淀了 TB 级的订单、商品、客户与支付数据。
平台上沉淀了 TB 级的交易数据——订单、商品、客户、支付、渠道一应俱全。对一个 SaaS 平台来说，这本身是一笔可观的资产。
问题在于这些数据从未以洞察的形式回流给商户。中小商户既没有数据分析师，也不会写 SQL，面对后台报表往往只能看到一个总数，看不出总数背后发生了什么。
「上个月哪几款菜品拉低了整体毛利」「周末和工作日的客单价差多少」——这类真正影响经营决策的问题，商户问不出来，平台也答不了。做一个覆盖所有业态的固定报表体系并不现实：餐厅关心翻台率，零售门店关心动销率，同一张报表满足不了两边。
对 Olsera 而言，多年累积的交易数据一直是一项存储成本，而不是产品能力。数据在库里，价值不在。
而在竞争激烈的东南亚 POS 市场，这恰恰是最有可能形成差异化的一块——因为它建立在别人拿不到的数据上。
Olsera 在 MOI 上构建商户智能分析助手，底层是 Medallion 分层数据仓库，把原始交易流水逐层加工为可直接查询的经营指标。分层的意义在于，商户提问命中的是已经清洗对齐的指标层，而不是原始流水。
上层的 AI 助手同时接入两条路径：NL2SQL 负责把商户的经营问题翻译成查询——销量总额、热销商品、订单趋势、渠道对比这类问题直接转为 SQL 执行；RAG 负责回答 POS 系统本身的操作类问题，从帮助文档与知识库中检索答案。
两类问题在商户看来都只是「问一句」，但技术路径完全不同。把它们放在同一个入口后面，商户不需要先判断自己问的是哪一类——这一步判断，本来就不该交给商户。
行级安全策略保证每个商户只能看到自己的数据，多租户隔离在查询层就已生效，无需为 8 万多家商户分别部署。商户的身份上下文由系统自动注入，不依赖提问时的自觉声明。
商户用日常语言提问即可获得有数据支撑的即时回答，全程不需要任何技术能力，也不需要平台配备分析师。
自然语言提问天然覆盖了固定报表无法穷举的业态差异：餐厅和零售门店问的是不同的问题，走的却是同一套能力。
行级安全在查询层生效，一套服务同时支撑 8 万多家商户，随商户增长不产生额外的部署成本。
对 Olsera 而言，原始交易数据被转化为面向商户的增值 AI 服务——一个成本中心变成了新的收入来源，而且这项能力建立在竞争对手无法复制的自有数据之上。