思考题一：站在数据团队立场来看并没有，目前能接触到的就是各平台评论以及企微聊天信息，原理上来讲是都可以接入大模型处理的。但是呢，一个是接入成本与收益权衡，当量级不大的时候运营团队更倾向于集中不分时间手动处理，而在运营和产研没有“双向奔赴”的前提下去做很可能会演变为自娱自乐而被弃置一边；二是诉求并没有完全想明白，也许是只想要个正负面评论分类，但是评判标准又没有界定，比如说我遇到一个场景用户在内容评论中抒发了自己的负面情绪，直接喂给大模型大概率会被判定为负面评论（也可能是提示词不够好），而运营也说不清这个属于中性评论还是其他。所以，我认为实践中大模型处理的考量也应将业务运营的视角纳入其中。 思考题二：API更合适。当前AI实际主要场景是内容生成和代码辅助开发这两个，代码开发来讲可以由专门IDE解决这一问题，那么剩下的就是内容生成。而内容生成来讲喂给AI的数据并没有那么敏感，同时在文生文领域最新的模型并非是必需品，而音视频类的自己部署模型可能也玩不好（我个人感觉是这块要求更高）。并且正如老师所讲，当前国内大模型API调用成本还是较低的，所以选择的是前者。 思考题三：我感觉数据湖会逐渐成为一种标配，理由是我认为这部分原始数据的存储成本往往比结构化数据更高，全部放在业务数据库中大概率吃不消，同时还会有与结构化数据整合后分析与洞察的诉求，目前学习下来对应方案便是数据湖。另一点老师在架构图中提到了在数据存储层和结果存储层之间加入了大模型处理层，那么这部分数据处理可能会演化成另一种数据仓库逐层处理的形式，缘由是之前学习大模型课程时提到多轮对话场景，即如果轮数过多那么每次喂给AI的token数会快速膨胀，一种可行的方式是每几轮对话后让AI为其生成小结作为下一轮对话的提示词（而非把历史对话全部灌入），这和dws层出现的原理是类似的，所以我的另一个推测是未来结构化数据由数仓处理，非结构化数据由类似数仓分级的大模型层处理，而后在结果层整合并应用。 从我个人来说上面提到的两点都是我尚未触及的领域，所以理解可能浮于表面，还望老师指点一二。