云主机搭建asp网站,wordpress用什么主机好,厦门做网站优化多少钱,安康市网站建设公司背景
正常的chat/im通常是有单点登录或者利用类似广播的机制做多设备间内容同步的。而且由于长连接的存在#xff0c;数据同步#xff08;想起来#xff09;相对简单。而llm的chat在缺失这两个机制的情况下#xff0c;没见到特别好的做到了数据同步的产品。 llm chat主要两…背景
正常的chat/im通常是有单点登录或者利用类似广播的机制做多设备间内容同步的。而且由于长连接的存在数据同步想起来相对简单。而llm的chat在缺失这两个机制的情况下没见到特别好的做到了数据同步的产品。 llm chat主要两个特点1. chat的输出过程是耗时的并不是正常chat的完整回复2. 业务形态不适合跨轮长连接。
原则和场景
llm的对话历史由于会直接影响模型的下一轮推理同时用户在流式过程中的操作和模型输出的结果会有明显时间差。故形成一个简单原则前端无错误时以前端为准用户看到的必须和模型看到的一致。 场景上会有两大部分1. 前端操作对需要对模型输出进行覆盖2. 后端数据比前端要新需要择机同步给前端。这部分又有几种情况a. 多点登录的情况下另一个设备有新聊天b. 推理被触发但前端没有收到数据随后恢复。恢复可能是流中和流结束后。
解决
整体话术遵循该DDD的定义。 整体上可以认为是redis主从模式的变种本文的数据同步已经上线方案可以直接拿来抄问题不大。 总体上redis的runid与对话的thread_id对等offset与入库时间戳对等。广义的循环不变式是数据和时间戳一一对应前后端均根据时间戳计算出diff相互传递数据做更新。
场景1
在发生任何前端修改消息的操作时停止推理、修改等。此时遵循原则前半句。前端为master后端为slave。数据是前端在上次时间戳之后有变化的消息。这些变化可以做为run接口的额外更新数据传递到后端或者一个独立接口。 然后转换为后端master前端slave要求返回后端更新和此次时间戳。
场景2.a
此时遵循原则后半句仅在下次推理开始时同步。后端master前端slave。在推理流的开头返回需要更新到message数据并直接在store/model更新数据。更新后需要携带此次更新的时间戳由前端记录。数据更新后正常进行本次推理。
场景2.b
是2a的更复杂版本是需要续流的。如果由历史触发只需要接受流。如果是多轮触发还需要将本次推理做pending等上一轮流结束后再触发新一轮的推理。
细节
每一个内容类step都关联一个messageid默认支持多消息的交错更新。控制类step要有创建message、结束message之类的行为来做多轮或者multiagent。借由这个更新机制历史和推理可以直接统一成一个处理模式甚至所有可能更新数据的都可以同一个模式尽可能增加数据同步的时机。存储和推理应该是两个模块由node做整合。推理依赖和理解存储其间流转的数据应该都是存储定义的格式。存储分静态和流式流式用redis的list就行。流式存储的是一个run静态存储的是thread和message。
