1. 項(xiàng)目緣起為什么“事后復(fù)盤(pán)”才是Agent記憶的真正入口“hindsight”這個(gè)詞本身就很說(shuō)明問(wèn)題——它指的是對(duì)已經(jīng)發(fā)生的事情的理解也就是“事后之明”。把這個(gè)詞放在Agent Memory的語(yǔ)境里指向非常明確讓Agent能夠回看自己做過(guò)的事、走過(guò)的路徑、犯過(guò)的錯(cuò)并從中提取出可復(fù)用的經(jīng)驗(yàn)。這和當(dāng)前主流Agent記憶方案有一個(gè)根本性的差異?，F(xiàn)在市面上大多數(shù)Agent記憶方案本質(zhì)上都是“前瞻式”的。用戶(hù)問(wèn)一個(gè)問(wèn)題Agent去檢索歷史對(duì)話(huà)、檢索知識(shí)庫(kù)、檢索工具調(diào)用記錄然后拼進(jìn)上下文。這套邏輯的核心是“在行動(dòng)之前找到可能有用的信息”。但hindsight要解決的是另一個(gè)問(wèn)題Agent做完一件事之后它能不能自己判斷哪些環(huán)節(jié)值得記住、哪些路徑是死胡同、哪些工具組合是高效的。我最初接觸這個(gè)方向是因?yàn)橐粋€(gè)很具體的痛點(diǎn)。當(dāng)時(shí)在做一個(gè)基于LLM的自動(dòng)化運(yùn)維助手它能通過(guò)MCP協(xié)議調(diào)用Docker相關(guān)的工具去查看容器狀態(tài)、重啟服務(wù)、拉取日志。跑了一段時(shí)間之后發(fā)現(xiàn)一個(gè)尷尬的情況同一個(gè)問(wèn)題比如“某個(gè)容器反復(fù)重啟”Agent每次都要從頭排查一遍——先看容器列表再看日志再看資源占用最后才定位到是內(nèi)存限制的問(wèn)題。第二次遇到幾乎一樣的情況它還是走同樣的流程。對(duì)話(huà)歷史里明明有記錄但那些記錄是“原始流水賬”不是“經(jīng)驗(yàn)”。hindsight要做的就是把這本流水賬變成一本“錯(cuò)題本”加“解題思路集”。它關(guān)注的是Agent在完成任務(wù)后如何對(duì)自身的執(zhí)行軌跡進(jìn)行結(jié)構(gòu)化反思并將反思結(jié)果寫(xiě)入長(zhǎng)期記憶。這個(gè)記憶不是簡(jiǎn)單的文本追加而是帶有因果標(biāo)注、路徑評(píng)估和場(chǎng)景標(biāo)簽的結(jié)構(gòu)化知識(shí)。適合誰(shuí)來(lái)參考這個(gè)方向如果你正在做Agent應(yīng)用尤其是那種需要多輪工具調(diào)用、需要跨會(huì)話(huà)保持行為一致性的場(chǎng)景比如自動(dòng)化運(yùn)維、代碼助手、數(shù)據(jù)分析Agent、客服工單處理那hindsight這套思路值得仔細(xì)看看。如果你只是做一個(gè)單輪問(wèn)答的聊天機(jī)器人那可能用不上因?yàn)樗膬r(jià)值在“重復(fù)性任務(wù)的經(jīng)驗(yàn)積累”上才體現(xiàn)得出來(lái)。2. 核心設(shè)計(jì)拆解hindsight到底在記什么、怎么記2.1 從“對(duì)話(huà)歷史”到“執(zhí)行軌跡”的認(rèn)知轉(zhuǎn)變傳統(tǒng)Agent記憶的存儲(chǔ)單元是“消息”。用戶(hù)說(shuō)一句助手回一句工具調(diào)用一次結(jié)果返回一次這些都是平鋪的消息記錄。檢索的時(shí)候按相似度找相關(guān)的消息片段。這套方案在簡(jiǎn)單場(chǎng)景下夠用但一旦任務(wù)鏈條變長(zhǎng)問(wèn)題就暴露了消息之間的因果關(guān)系丟失了。舉個(gè)例子。Agent執(zhí)行了一個(gè)任務(wù)用戶(hù)說(shuō)“幫我看看為什么測(cè)試環(huán)境掛了”Agent先調(diào)用了Docker的容器列表接口發(fā)現(xiàn)有一個(gè)容器狀態(tài)是exited然后調(diào)用了日志接口發(fā)現(xiàn)是數(shù)據(jù)庫(kù)連接超時(shí)然后調(diào)用了配置查詢(xún)接口發(fā)現(xiàn)連接池配置被改小了最后給出結(jié)論。這一串消息在歷史記錄里是散落的。下次遇到“測(cè)試環(huán)境掛了”檢索出來(lái)的可能是“日志接口返回了什么”這種中間片段而不是“從容器狀態(tài)到日志到配置的完整排查路徑”。hindsight的核心設(shè)計(jì)就是把存儲(chǔ)單元從“消息”升級(jí)為“軌跡”。一條軌跡包含任務(wù)描述、執(zhí)行步驟序列、每步的工具調(diào)用與結(jié)果摘要、最終結(jié)論、以及一個(gè)事后評(píng)估標(biāo)簽。這個(gè)評(píng)估標(biāo)簽是hindsight的關(guān)鍵創(chuàng)新——它不是在任務(wù)執(zhí)行中生成的而是在任務(wù)完成后由Agent自己或者一個(gè)專(zhuān)門(mén)的評(píng)估模塊來(lái)標(biāo)注這條路徑是高效的、還是繞了彎路的、還是失敗的。2.2 為什么選擇“事后寫(xiě)入”而不是“實(shí)時(shí)寫(xiě)入”這是一個(gè)很關(guān)鍵的設(shè)計(jì)決策。很多記憶方案是實(shí)時(shí)寫(xiě)入的——每產(chǎn)生一條消息就存一條。hindsight選擇在任務(wù)完成后才寫(xiě)入記憶理由有三。第一實(shí)時(shí)寫(xiě)入會(huì)產(chǎn)生大量噪聲。Agent在排查問(wèn)題時(shí)中間步驟有很多是試探性的、被推翻的。比如它先懷疑是網(wǎng)絡(luò)問(wèn)題查了一圈發(fā)現(xiàn)不是這個(gè)“查網(wǎng)絡(luò)”的過(guò)程如果實(shí)時(shí)寫(xiě)入下次檢索時(shí)就會(huì)被當(dāng)成一個(gè)可能的排查方向但實(shí)際上它已經(jīng)被證偽了。事后寫(xiě)入可以在寫(xiě)入前做一次過(guò)濾把被證偽的路徑標(biāo)記為“低優(yōu)先級(jí)”或者直接丟棄。第二事后評(píng)估需要全局視角。只有任務(wù)完成了Agent才知道最終哪個(gè)步驟是決定性的。在任務(wù)進(jìn)行中它沒(méi)有這個(gè)信息。事后寫(xiě)入允許Agent在擁有完整信息的情況下對(duì)每個(gè)步驟的重要性進(jìn)行重新評(píng)估。第三寫(xiě)入頻率可控降低存儲(chǔ)和檢索壓力。實(shí)時(shí)寫(xiě)入意味著每輪對(duì)話(huà)都要做一次向量化、一次索引更新。事后寫(xiě)入是批量操作可以在任務(wù)結(jié)束后一次性完成軌跡的壓縮、摘要和索引。對(duì)于高頻使用的Agent來(lái)說(shuō)這個(gè)差異在成本上非常明顯。2.3 軌跡的結(jié)構(gòu)化表示hindsight的數(shù)據(jù)模型hindsight的軌跡數(shù)據(jù)模型大致是這樣的。一條軌跡有一個(gè)唯一的trace_id包含task_description任務(wù)的自然語(yǔ)言描述、steps步驟數(shù)組、outcome結(jié)果標(biāo)簽如success/failure/partial、evaluation事后評(píng)估文本、embedding用于檢索的向量表示。每個(gè)step包含step_index、action_type如tool_call/llm_reasoning/user_input、action_detail具體調(diào)用了什么工具、傳了什么參數(shù)、observation工具返回的結(jié)果摘要、step_evaluation這一步在事后看是必要的還是多余的。這個(gè)結(jié)構(gòu)看起來(lái)簡(jiǎn)單但實(shí)際落地時(shí)有幾個(gè)細(xì)節(jié)需要特別注意。observation的摘要長(zhǎng)度要控制。如果把工具返回的完整JSON都存進(jìn)去一條軌跡的token量會(huì)爆炸。我的做法是只存關(guān)鍵字段和狀態(tài)碼比如Docker容器列表只存容器名和狀態(tài)日志只存錯(cuò)誤行和前后三行。step_evaluation的標(biāo)注粒度要適中。太粗了沒(méi)有指導(dǎo)意義太細(xì)了標(biāo)注成本太高。我一般只標(biāo)注“必要”、“冗余”、“錯(cuò)誤方向”三種。3. 實(shí)操落地從零搭建一個(gè)hindsight風(fēng)格的Agent記憶模塊3.1 環(huán)境準(zhǔn)備與依賴(lài)選型這套東西跑起來(lái)需要幾個(gè)基礎(chǔ)組件。我用的是Docker Compose來(lái)編排因?yàn)锳gent本身、向量數(shù)據(jù)庫(kù)、以及可能用到的MCP工具服務(wù)都需要獨(dú)立運(yùn)行環(huán)境?；A(chǔ)鏡像選python:3.11-slim原因是LLM相關(guān)的庫(kù)對(duì)Python版本比較敏感3.11在兼容性和性能上比較平衡。向量數(shù)據(jù)庫(kù)我選的是Qdrant原因是它支持payload過(guò)濾這對(duì)hindsight很重要——檢索軌跡時(shí)經(jīng)常需要按outcome標(biāo)簽過(guò)濾比如只看成功的軌跡。Qdrant的Docker鏡像拉取和啟動(dòng)都很直接。MCP工具服務(wù)這塊如果你的Agent需要調(diào)用外部工具比如查Docker狀態(tài)、查數(shù)據(jù)庫(kù)那需要單獨(dú)跑MCP server。MCP協(xié)議本身是軟件協(xié)議不是硬件協(xié)議它定義的是模型和工具之間的通信格式。一個(gè)MCP server就是一個(gè)獨(dú)立的進(jìn)程通過(guò)標(biāo)準(zhǔn)輸入輸出或者SSE和Agent通信。我一般會(huì)把常用的工具服務(wù)用Docker Compose管理起來(lái)和Agent主程序在同一個(gè)網(wǎng)絡(luò)里這樣Agent通過(guò)服務(wù)名就能訪問(wèn)。docker-compose.yml的核心片段大概是這樣services: agent: build: ./agent environment: - QDRANT_HOSTqdrant - QDRANT_PORT6333 depends_on: - qdrant qdrant: image: qdrant/qdrant:latest ports: - 6333:6333 volumes: - qdrant_data:/qdrant/storage mcp-docker-tools: build: ./mcp-docker-tools volumes: - /var/run/docker.sock:/var/run/docker.sock volumes: qdrant_data:這里有個(gè)坑要注意mcp-docker-tools掛載了docker.sock這意味著這個(gè)容器可以控制宿主機(jī)上的Docker。在生產(chǎn)環(huán)境里要謹(jǐn)慎最好限制它的權(quán)限或者用Docker的API代理來(lái)做一層隔離。我本地開(kāi)發(fā)時(shí)為了方便直接掛載了但上線前一定要改。3.2 軌跡采集與事后評(píng)估的實(shí)現(xiàn)軌跡采集的核心是在Agent的執(zhí)行循環(huán)里埋點(diǎn)。我用的是一個(gè)裝飾器模式在每個(gè)工具調(diào)用和LLM推理步驟前后記錄時(shí)間和輸入輸出。這些記錄先存在內(nèi)存里任務(wù)結(jié)束后統(tǒng)一處理。事后評(píng)估這一步我試過(guò)兩種方案。一種是讓同一個(gè)LLM在任務(wù)結(jié)束后把完整軌跡重新讀一遍然后輸出每個(gè)步驟的評(píng)估標(biāo)簽。另一種是單獨(dú)跑一個(gè)小的評(píng)估模型專(zhuān)門(mén)做步驟分類(lèi)。實(shí)測(cè)下來(lái)第一種方案效果更好因?yàn)橥粋€(gè)模型對(duì)任務(wù)上下文的理解更連貫。但成本更高因?yàn)橐淹暾壽E再喂一遍。我的折中方案是只把軌跡的摘要版本喂給評(píng)估模型。摘要版本里每個(gè)步驟只保留action_type、action_detail的前50個(gè)字符、observation的前100個(gè)字符。這樣一條10步的軌跡摘要后大概只有800到1000個(gè)token評(píng)估成本可以接受。評(píng)估的prompt大概是這樣你是一個(gè)Agent執(zhí)行軌跡的評(píng)估員。下面是一個(gè)Agent完成任務(wù)的步驟記錄。 請(qǐng)對(duì)每個(gè)步驟標(biāo)注以下標(biāo)簽之一 - necessary: 該步驟對(duì)最終結(jié)論有直接貢獻(xiàn) - redundant: 該步驟的結(jié)果沒(méi)有影響最終結(jié)論 - misleading: 該步驟引導(dǎo)了錯(cuò)誤方向但后來(lái)被糾正 - failed: 該步驟本身執(zhí)行失敗 最后給出整體評(píng)估這條軌跡是否值得作為未來(lái)類(lèi)似任務(wù)的參考。這個(gè)prompt的關(guān)鍵在于標(biāo)簽定義要互斥且可操作。我一開(kāi)始用了“重要/不重要”這種模糊標(biāo)簽結(jié)果模型標(biāo)注的一致性很差。改成上面這種帶行為描述的標(biāo)簽后一致性明顯提升。3.3 軌跡寫(xiě)入與檢索的工程細(xì)節(jié)寫(xiě)入這塊一條軌跡處理完后我會(huì)做三件事。第一把軌跡的task_description和evaluation拼成一個(gè)文本做embedding存入Qdrant的trajectory集合。第二把每個(gè)step單獨(dú)做embedding存入step集合payload里帶上trace_id和step_evaluation。第三如果軌跡的outcome是failure額外寫(xiě)入一個(gè)failure_pattern集合用于后續(xù)的“避坑檢索”。檢索的時(shí)候分兩層。第一層是按任務(wù)描述檢索相似的軌跡拿到top 3的trace_id。第二層是在這些trace_id下檢索step集合里標(biāo)記為necessary的步驟按step_index排序還原出當(dāng)時(shí)的執(zhí)行路徑。這個(gè)路徑會(huì)作為“參考經(jīng)驗(yàn)”注入到當(dāng)前任務(wù)的上下文里。這里有個(gè)性能上的注意點(diǎn)step集合的數(shù)據(jù)量會(huì)增長(zhǎng)很快。一條10步的軌跡就是10條step記錄。如果每天跑1000個(gè)任務(wù)一天就是10000條。所以step的embedding維度可以適當(dāng)降低我用的是384維的小模型而不是1536維的大模型。檢索精度會(huì)降一點(diǎn)但速度提升很明顯。另外Qdrant的payload索引要提前建好。我一開(kāi)始沒(méi)建索引按outcome過(guò)濾時(shí)全表掃描慢得離譜。后來(lái)在outcome和step_evaluation兩個(gè)字段上建了keyword索引檢索時(shí)間從秒級(jí)降到了毫秒級(jí)。4. 踩坑記錄與排查技巧4.1 軌跡污染當(dāng)Agent把錯(cuò)誤經(jīng)驗(yàn)當(dāng)成寶這是hindsight落地過(guò)程中最危險(xiǎn)的問(wèn)題。如果評(píng)估環(huán)節(jié)沒(méi)做好一條失敗的軌跡可能被標(biāo)記為“值得參考”下次遇到類(lèi)似任務(wù)時(shí)Agent會(huì)照著錯(cuò)誤路徑再走一遍。我遇到過(guò)一次典型情況。Agent在排查一個(gè)數(shù)據(jù)庫(kù)連接問(wèn)題時(shí)走了一條很繞的路先重啟了應(yīng)用容器又重啟了數(shù)據(jù)庫(kù)容器最后發(fā)現(xiàn)是網(wǎng)絡(luò)策略的問(wèn)題。這條軌跡的outcome是success因?yàn)樽罱K問(wèn)題解決了。但評(píng)估時(shí)如果只看outcome就會(huì)把“重啟容器”這個(gè)步驟標(biāo)記為necessary實(shí)際上它是完全多余的。解決方案是在評(píng)估prompt里強(qiáng)制要求區(qū)分“相關(guān)”和“因果”。我加了一條規(guī)則一個(gè)步驟只有在“如果去掉它最終結(jié)論就無(wú)法得出”的情況下才能標(biāo)記為necessary。重啟容器這個(gè)步驟去掉它最終結(jié)論網(wǎng)絡(luò)策略問(wèn)題依然可以通過(guò)日志分析得出所以它應(yīng)該被標(biāo)記為redundant。這個(gè)規(guī)則的加入讓軌跡質(zhì)量提升了很多。但代價(jià)是評(píng)估模型的推理負(fù)擔(dān)變重了需要更仔細(xì)地分析步驟間的依賴(lài)關(guān)系。我的做法是把評(píng)估模型換成推理能力更強(qiáng)的版本雖然貴一點(diǎn)但值得。4.2 檢索到的經(jīng)驗(yàn)“水土不服”另一個(gè)常見(jiàn)問(wèn)題是檢索出來(lái)的歷史軌跡和當(dāng)前任務(wù)表面相似但實(shí)際環(huán)境不同。比如歷史軌跡是在Docker環(huán)境下排查的當(dāng)前任務(wù)是在Kubernetes環(huán)境下雖然都是“容器反復(fù)重啟”但排查路徑完全不同。我的應(yīng)對(duì)策略是在軌跡的payload里增加環(huán)境標(biāo)簽。寫(xiě)入時(shí)自動(dòng)提取環(huán)境特征比如“docker”、“k8s”、“bare-metal”檢索時(shí)先按環(huán)境標(biāo)簽過(guò)濾再按語(yǔ)義相似度排序。這樣能避免大部分“水土不服”的情況。如果環(huán)境標(biāo)簽匹配不上那檢索結(jié)果會(huì)降權(quán)處理。具體做法是在注入上下文時(shí)加一句提示“以下經(jīng)驗(yàn)來(lái)自不同環(huán)境僅供參考請(qǐng)結(jié)合當(dāng)前環(huán)境判斷”。實(shí)測(cè)下來(lái)加了這句提示后Agent盲目照搬歷史路徑的情況少了很多。4.3 常見(jiàn)問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方法解決措施軌跡檢索結(jié)果不相關(guān)embedding模型不適合該領(lǐng)域人工檢查top 5結(jié)果的task_description換用領(lǐng)域微調(diào)的embedding模型或增加關(guān)鍵詞過(guò)濾評(píng)估標(biāo)簽一致性差prompt標(biāo)簽定義模糊同一軌跡跑兩次評(píng)估對(duì)比標(biāo)簽差異細(xì)化標(biāo)簽定義增加示例寫(xiě)入速度慢逐條寫(xiě)入Qdrant查看寫(xiě)入日志的耗時(shí)分布改為批量寫(xiě)入每50條一批檢索時(shí)延高payload字段未建索引用Qdrant的explain功能查看查詢(xún)計(jì)劃在過(guò)濾字段上建keyword索引Agent忽略歷史經(jīng)驗(yàn)注入位置太靠后檢查prompt中經(jīng)驗(yàn)注入的位置把經(jīng)驗(yàn)放在system prompt之后、用戶(hù)輸入之前軌跡存儲(chǔ)量暴漲step粒度太細(xì)統(tǒng)計(jì)每條軌跡的平均step數(shù)合并連續(xù)的同類(lèi)型step或只存關(guān)鍵step4.4 一個(gè)容易被忽略的細(xì)節(jié)時(shí)間衰減Agent的記憶和人的記憶一樣舊的經(jīng)驗(yàn)應(yīng)該逐漸降低權(quán)重。我一開(kāi)始沒(méi)做時(shí)間衰減結(jié)果半年前的一條軌跡還在影響當(dāng)前決策而那條軌跡對(duì)應(yīng)的系統(tǒng)架構(gòu)早就變了。實(shí)現(xiàn)時(shí)間衰減很簡(jiǎn)單在Qdrant的payload里存一個(gè)timestamp檢索時(shí)對(duì)相似度分?jǐn)?shù)做一個(gè)衰減計(jì)算。衰減函數(shù)我用的是指數(shù)衰減半衰期設(shè)成30天。也就是說(shuō)30天前的軌跡其相似度分?jǐn)?shù)會(huì)乘以0.5。這個(gè)參數(shù)可以根據(jù)你的系統(tǒng)變更頻率來(lái)調(diào)整。如果系統(tǒng)很穩(wěn)定半衰期可以設(shè)長(zhǎng)一點(diǎn)比如90天。但要注意失敗軌跡的衰減應(yīng)該比成功軌跡慢。因?yàn)槌晒Φ慕?jīng)驗(yàn)可能因?yàn)榄h(huán)境變化而失效但失敗的教訓(xùn)往往更持久。比如“不要在沒(méi)有備份的情況下直接改生產(chǎn)數(shù)據(jù)庫(kù)配置”這種教訓(xùn)放一年也依然有效。所以我在衰減計(jì)算時(shí)對(duì)failure類(lèi)型的軌跡用了更長(zhǎng)的半衰期。5. 與MCP生態(tài)的配合讓hindsight成為Agent的“經(jīng)驗(yàn)層”MCP協(xié)議現(xiàn)在被越來(lái)越多的工具服務(wù)支持這對(duì)hindsight來(lái)說(shuō)是個(gè)好消息。因?yàn)镸CP把工具調(diào)用的接口標(biāo)準(zhǔn)化了hindsight采集軌跡時(shí)不需要為每個(gè)工具寫(xiě)適配器只需要解析MCP的標(biāo)準(zhǔn)消息格式就行。具體來(lái)說(shuō)當(dāng)Agent通過(guò)MCP調(diào)用一個(gè)工具時(shí)消息里會(huì)包含工具名、參數(shù)、返回結(jié)果。hindsight的采集模塊直接監(jiān)聽(tīng)這些消息就能拿到結(jié)構(gòu)化的步驟數(shù)據(jù)。這比之前每個(gè)工具一套解析邏輯要省事得多。我現(xiàn)在的做法是在MCP client和MCP server之間加一個(gè)輕量的代理層。這個(gè)代理層負(fù)責(zé)轉(zhuǎn)發(fā)消息同時(shí)把消息復(fù)制一份給hindsight的采集模塊。代理層用Python的asyncio實(shí)現(xiàn)對(duì)原有通信的延遲影響在毫秒級(jí)基本無(wú)感。這個(gè)代理層還有一個(gè)好處可以在轉(zhuǎn)發(fā)前對(duì)工具調(diào)用做攔截和修改。比如如果hindsight檢索到當(dāng)前任務(wù)和某條失敗軌跡高度相似代理層可以在Agent實(shí)際調(diào)用工具前注入一個(gè)提示“注意歷史上有類(lèi)似任務(wù)在調(diào)用XX工具時(shí)失敗了原因是YY請(qǐng)謹(jǐn)慎操作”。這種“事前預(yù)警”比“事后參考”的價(jià)值更大。不過(guò)這個(gè)攔截功能要慎用。如果攔截太頻繁Agent會(huì)變得畏手畏腳什么都不敢做。我的策略是只對(duì)failure_pattern集合里高頻出現(xiàn)的模式做攔截而且攔截提示要具體不能只說(shuō)“小心”要說(shuō)清楚“小心什么、為什么、建議怎么做”。6. 一些實(shí)測(cè)數(shù)據(jù)和調(diào)優(yōu)經(jīng)驗(yàn)跑了一段時(shí)間之后我統(tǒng)計(jì)了一些數(shù)據(jù)供參考。在一個(gè)自動(dòng)化運(yùn)維場(chǎng)景下引入hindsight之前Agent完成一個(gè)典型排查任務(wù)平均需要12輪工具調(diào)用。引入之后降到8輪左右。原因是Agent能直接參考?xì)v史軌跡里的高效路徑跳過(guò)了很多試探性步驟。但也不是沒(méi)有代價(jià)。每次任務(wù)結(jié)束后的事后評(píng)估增加了大約2到3秒的延遲以及額外的token消耗。如果任務(wù)本身執(zhí)行時(shí)間很短比如5秒那評(píng)估的 overhead 就顯得很大。所以我的建議是只對(duì)執(zhí)行時(shí)間超過(guò)一定閾值比如30秒或者工具調(diào)用次數(shù)超過(guò)一定數(shù)量比如5次的任務(wù)做事后評(píng)估。短任務(wù)直接跳過(guò)因?yàn)樗鼈兊慕?jīng)驗(yàn)價(jià)值本身就不高。另一個(gè)調(diào)優(yōu)點(diǎn)是軌跡的摘要長(zhǎng)度。摘要太短檢索時(shí)區(qū)分度不夠摘要太長(zhǎng)embedding質(zhì)量下降。我試過(guò)50字、100字、200字三個(gè)檔位最后發(fā)現(xiàn)100到150字之間效果最好。這個(gè)長(zhǎng)度大概能覆蓋任務(wù)的核心描述和關(guān)鍵步驟同時(shí)不會(huì)引入太多噪聲。最后說(shuō)一個(gè)我個(gè)人的體會(huì)。hindsight這套東西技術(shù)上的難點(diǎn)其實(shí)不在存儲(chǔ)和檢索而在評(píng)估的準(zhǔn)確性。如果評(píng)估環(huán)節(jié)把冗余步驟標(biāo)成必要步驟那后續(xù)的檢索就是在傳播錯(cuò)誤經(jīng)驗(yàn)。所以我在評(píng)估prompt上花的精力比在存儲(chǔ)和檢索上加起來(lái)還多。如果你要落地這套方案建議先把評(píng)估環(huán)節(jié)做扎實(shí)再考慮擴(kuò)展存儲(chǔ)和檢索的規(guī)模。