先看证据
从纽约会后的邀约，看见一个具体缺口
Anekha Sokhal在AI Engineer New York介绍了Moshi：一款面向机构交易员、尤其关注能源市场的推荐引擎，试图把不断涌入的市场信息连接到交易员自己的持仓和关切。Sokhal曾在摩根大通交易能源衍生品，她把产品描述为自己做交易时希望拥有的工具。她在访谈中提到，演讲后原定离开纽约的行程不断延长，新增的会面还延伸到休斯敦的能源从业者。
会后排满日程说明市场问题能引起对话，却不能单独证明产品已带来交易收益。更值得技术负责人理解的是问题本身：交易员面对的不是单纯的信息不足，而是难以持续判断哪些信息可信、哪些与自己的交易有关、哪些值得进一步核验。Moshi因此把目标放在注意力筛选上，而不是再造一个能回答问题的聊天框。
把市场流和私有资料放进同一条脉络
按公开材料对产品的描述，Moshi要汇集的并不只有行情。期货数据、基本面与技术指标、新闻和社交媒体信息，要和交易员的订阅内容、邮件、PDF及内部资料一起进入分析流程。系统清洗和转换这些不同形态的数据，再用统计与机器学习方法标记信息，并组织进自建图谱，尝试建立信息之间的关联。
关键一步，是把这些关联映射到用户的持仓：某条新闻不只作为搜索结果出现，还可能被系统判断为与某个交易主题有关，并提示后续影响。公开演讲摘要把这种能力描述为对二阶、三阶影响的关联，但没有披露完整实现细节。这个设计的价值在于减少交易员逐项检索和拼接资料的工作，代价则是产品必须把数据接入、持仓语境和来源管理做在一起，任何一环薄弱都可能让推荐失去意义。
数据规模是输入，不是效果证明
Moshi对外出现过几种数据规模说法：Sokhal称系统每小时处理22万个数据点；另有访谈称监测量超过25亿个数据点，演讲摘要则提到24亿个数据点，并用“读一句话的时间学到300个新东西”来描述发现速度。这些数字来自公司方或演讲摘要，公开材料没有说明“数据点”的统一定义，也没有交代24亿与25亿分别对应什么时间窗口；“300个新东西”同样没有可复核的定义。
公司还公开宣传过一次天然气日历价差案例，称系统在一次重大突破前三天发出提示，并把突破描述为70%。但材料没有提供完整交易记录、对照基准或独立验证，因此这只能视为产品方报告的案例，不能直接读成预测准确率或收益证明。对采购或自建决策而言，这些指标适合说明系统处理和发现信息的规模主张，不足以替代对误报、漏报、提前量和实际工作价值的评估。
推荐与问答的分界，在于谁先承担筛选
Moshi的产品主张不是让交易员反复提示模型，直到问出正确的问题，而是让系统主动整理可能与其持仓有关的信息，再由交易员检查证据并作出决定。Sokhal把它比作Bloomberg、Claude和Netflix的结合：市场数据、处理信息的界面，以及面向个人交易语境的推荐。这个比喻强调的是组合后的工作流，并不意味着它能取代终端、通用模型或交易员本身。
在技术分工上，Sokhal称判断市场信息与用户持仓相关性的部分采用统计方法和确定性模型，LLM只参与其中一层，让结果更自然地表达。这是创始人的产品描述，公开资料没有提供独立审计或模型评测。她也表示系统会显示来源、主张和假设，这有助于用户追问结论依据；但让依据可见，不等于已经可靠解决了来源互相矛盾的问题，材料没有说明其冲突消解算法。
技术负责人该验收的是工作流，而非演示
对金融机构的技术团队来说，Moshi这类产品首先是一项数据与流程工程。公开行情相对容易成为共同输入，真正复杂的是把订阅和内部资料安全接入，维持来源和时间语境，再把结果送到交易员会实际使用的位置。Sokhal称团队用自建视觉语言模型解析上传的PDF，也表示不希望把用户资料交给第三方；这意味着隐私控制是产品主张的一部分，同时也把模型维护和系统集成责任留在团队内部。
评估时，可以先让推荐与现有监测流程并行，逐条检查它关联了什么持仓、依据来自哪里、遇到冲突时如何呈现，并记录哪些提示真正改变了人工核验工作。重点不是预设AI应当替人决策，而是判断它是否稳定减少了筛选负担，且没有把不可见的错误带进交易判断。访谈里关于工程师被告知“你就是整个团队”的压力也值得警惕：能够用AI加速开发，不代表原本由多人承担的数据治理、可靠性和用户协作责任自动消失。