网站建设的色彩搭配云盘搜
背景
正常的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。