背景

正常的chat/im通常是有單點(diǎn)登錄或者利用類似廣播的機(jī)制做多設(shè)備間內(nèi)容同步的。而且由于長連接的存在，數(shù)據(jù)同步（想起來）相對(duì)簡單。而llm的chat在缺失這兩個(gè)機(jī)制的情況下，沒見到特別好的做到了數(shù)據(jù)同步的產(chǎn)品。
llm chat主要兩個(gè)特點(diǎn)：1. chat的輸出過程是耗時(shí)的，并不是正常chat的完整回復(fù)；2. 業(yè)務(wù)形態(tài)不適合跨輪長連接。

原則和場景

llm的對(duì)話歷史由于會(huì)直接影響模型的下一輪推理，同時(shí)用戶在流式過程中的操作和模型輸出的結(jié)果會(huì)有明顯時(shí)間差。故形成一個(gè)簡單原則：前端無錯(cuò)誤時(shí)以前端為準(zhǔn)，用戶看到的必須和模型看到的一致。
場景上會(huì)有兩大部分：1. 前端操作，對(duì)需要對(duì)模型輸出進(jìn)行覆蓋；2. 后端數(shù)據(jù)比前端要新，需要擇機(jī)同步給前端。這部分又有幾種情況：a. 多點(diǎn)登錄的情況下，另一個(gè)設(shè)備有新聊天；b. 推理被觸發(fā)，但前端沒有收到數(shù)據(jù)，隨后恢復(fù)。恢復(fù)可能是流中和流結(jié)束后。

解決

整體話術(shù)遵循該DDD的定義。
整體上可以認(rèn)為是redis主從模式的變種，本文的數(shù)據(jù)同步已經(jīng)上線，方案可以直接拿來抄，問題不大。
總體上，redis的runid與對(duì)話的thread_id對(duì)等，offset與入庫時(shí)間戳對(duì)等。廣義的循環(huán)不變式是數(shù)據(jù)和時(shí)間戳一一對(duì)應(yīng)，前后端均根據(jù)時(shí)間戳計(jì)算出diff，相互傳遞數(shù)據(jù)做更新。

場景1

在發(fā)生任何前端修改消息的操作時(shí)（停止推理、修改等）。此時(shí)遵循原則前半句。前端為master，后端為slave。數(shù)據(jù)是前端在上次時(shí)間戳之后有變化的消息。這些變化可以做為run接口的額外更新數(shù)據(jù)傳遞到后端，或者一個(gè)獨(dú)立接口。
然后轉(zhuǎn)換為后端master，前端slave，要求返回后端更新和此次時(shí)間戳。

場景2.a

此時(shí)遵循原則后半句，僅在下次推理開始時(shí)同步。后端master，前端slave。在推理流的開頭返回需要更新到message數(shù)據(jù)，并直接在store/model更新數(shù)據(jù)。更新后需要攜帶此次更新的時(shí)間戳，由前端記錄。數(shù)據(jù)更新后正常進(jìn)行本次推理。

場景2.b

是2a的更復(fù)雜版本，是需要續(xù)流的。如果由歷史觸發(fā)，只需要接受流。如果是多輪觸發(fā)，還需要將本次推理做pending，等上一輪流結(jié)束后再觸發(fā)新一輪的推理。

細(xì)節(jié)

• 每一個(gè)內(nèi)容類step都關(guān)聯(lián)一個(gè)messageid，默認(rèn)支持多消息的交錯(cuò)更新。
• 控制類step要有創(chuàng)建message、結(jié)束message之類的行為，來做多輪或者multiagent。
• 借由這個(gè)更新機(jī)制，歷史和推理可以直接統(tǒng)一成一個(gè)處理模式，甚至所有可能更新數(shù)據(jù)的都可以同一個(gè)模式，盡可能增加數(shù)據(jù)同步的時(shí)機(jī)。
• 存儲(chǔ)和推理應(yīng)該是兩個(gè)模塊，由node做整合。推理依賴和理解存儲(chǔ)，其間流轉(zhuǎn)的數(shù)據(jù)應(yīng)該都是存儲(chǔ)定義的格式。
• 存儲(chǔ)分靜態(tài)和流式，流式用redis的list就行。流式存儲(chǔ)的是一個(gè)run，靜態(tài)存儲(chǔ)的是thread和message。