1. 內(nèi)容整體設(shè)計與思路拆解做AI應(yīng)用這一年多我最深的感觸是大模型本身幾乎沒有“記憶”可言。你和一個對話機器人聊得再投機只要會話一斷、上下文一清它下次見你又是陌生人。很多團隊把精力全花在模型選型和提示詞調(diào)優(yōu)上卻忽略了最基礎(chǔ)的工程問題——把短期記憶、長期記憶和向量存儲組合成一套可用的記憶體系。這篇文章就圍繞這三層展開講講我實際搭建時踩過的坑、梳理過的設(shè)計思路以及可以直接拿去用的代碼框架。適合正在做對話產(chǎn)品、AI助手或Agent應(yīng)用的開發(fā)者參考哪怕你剛剛?cè)腴T跟著動手也能跑起來。1.1 為什么AI應(yīng)用需要一套自己的“記憶系統(tǒng)”先講一個我真實遇到過的場景。有位同事搭了一個會議助手用戶第一天跟它說“我周五下午都不方便開會”第三天來問“幫我安排周五的復(fù)盤會”。AI很禮貌地給出了下午三點的方案用戶當場就翻臉了。問題出在哪兒不是模型能力不行而是會話之間的信息完全沒打通。大語言模型的本質(zhì)是無狀態(tài)的每次請求都只基于當前輸入做推理過去發(fā)生過什么它并不知道。你可能會說那把歷史記錄全部拼進上下文不就得了。我試過效果更糟。第一是Token預(yù)算撐不住聊個幾十輪之后上下文就爆炸了第二是信息過載幾千條歷史消息堆在一起模型根本分不清哪些重要、哪些過期反而把關(guān)鍵信息淹沒。更麻煩的是成本每輪都把長篇歷史重新發(fā)送一遍費用增長非?？臁Ｋ訟I應(yīng)用需要的是分層記憶。短期記憶負責把當前會話的關(guān)鍵消息留在“工作臺”上保證對話連貫長期記憶負責把用戶偏好、關(guān)鍵事實、歷史結(jié)論沉淀到持久化存儲里跨會話復(fù)用向量存儲則給長期記憶建立語義索引讓系統(tǒng)能在海量信息中快速找回相關(guān)內(nèi)容。三層各司其職才能讓AI看起來“記得住、想得起”。我在最初設(shè)計時犯過一個錯誤把所有聊天記錄直接堆進一個數(shù)據(jù)庫想查的時候全表掃描。結(jié)果數(shù)據(jù)一多性能崩了相關(guān)性也一塌糊涂。后來才明白記憶系統(tǒng)不是“存儲系統(tǒng)”而是“檢索系統(tǒng)”。重點不在于你存了多少而在于該用的時候能不能精準地拿出來。這決定了整套架構(gòu)的走向。1.2 三個核心概念到底指什么先說短期記憶。它對應(yīng)的是“當前對話工作臺”在實現(xiàn)上通常就是一組按時間排列的消息列表。它的特點是讀寫快、跟當前語境貼合但容量有限。聊天過程中臨時出現(xiàn)的數(shù)字、名字、上下文都會先落到這里。它也是模型真正“看得見”的記憶每輪請求都會占用上下文窗口的一大部分。長期記憶就不太一樣。它保存的是跨會話的、經(jīng)過提煉的信息。比如“用戶習慣喝美式咖啡”“用戶所在的項目組每周二開晨會”“用戶希望報告盡量用表格”。這些信息不會因為一次會話結(jié)束就失效它們以結(jié)構(gòu)化文本、鍵值對或摘要的形式存在獨立存儲中。長期記憶是AI“真正記住你”的那部分短期記憶在會話結(jié)束那一刻就基本清空了。向量存儲則是一種索引機制。長期記憶里的文本五花八門如果只靠關(guān)鍵詞匹配遇到“用戶不愛喝甜的”和“今天幫我選杯喝的”這種語義相關(guān)但字面完全不同的場景根本匹配不上。向量存儲先把文本映射成高維向量檢索時用用戶當前問題也映射成向量通過余弦相似度找到語義最近的幾條記憶。你可以把長期記憶想象成一座圖書館向量存儲就是那張索引卡。這三層不是替代關(guān)系而是合作關(guān)系。我見過有人只用短期記憶結(jié)果跨會話能力為零也有人把所有東西一股腦塞進向量庫卻從不維護記憶的時效性導(dǎo)致上一周的過期信息不斷干擾當前決策。只有把三層明確區(qū)分并串聯(lián)起來記憶系統(tǒng)才稱得上完整。1.3 為什么是“向量存儲檢索”而不是暴力全量輸入如果直接讓模型“全量記住”所有歷史問題顯而易見。第一是上下文窗口有限不可能無限塞入第二是模型注意力會分散塞進去的信息越多它對每條信息的敏感度就越低。也就是說你可以把所有歷史全給模型但它反而“不知道”該看哪條。這就像讓一個人一口氣讀一百份資料再去回答一個問題真正有用的那份大概率被忽略。向量檢索的價值在于“篩選”。系統(tǒng)先把用戶的當前問題向量化再到記憶庫里找到語義最接近的三到五條記憶然后只把這些高相關(guān)的記憶放進上下文。模型的注意力被限定在少量高價值信息上回答質(zhì)量自然比全量堆砌高得多。這種“先檢索再生成”的方式本質(zhì)上是把“記什么”的決策權(quán)從模型手里拿回來交給工程系統(tǒng)來控制。我也強調(diào)一點向量檢索不是銀彈。它對抽象語義的匹配很好但對精確數(shù)字、專有名詞、代碼標識符這類內(nèi)容的匹配不一定比得上關(guān)鍵詞。成熟的做法是向量檢索和關(guān)鍵詞檢索各跑一路再做合并排序。我后續(xù)會詳細展開這個混合召回方案這里先記住一個大原則能用語義解決的上向量能用精確字段解決的上結(jié)構(gòu)化存儲兩條腿走路才穩(wěn)。2. 核心細節(jié)解析與實操要點理解了三層結(jié)構(gòu)還不夠具體實現(xiàn)時每個模塊都有大量細節(jié)。這一章我逐個拆解重點講“為什么要這么設(shè)計”而不只是“怎么設(shè)計”。2.1 短期記憶的窗口管理滑動窗口與摘要歸檔短期記憶最樸素的形式是一個消息列表但列表怎么維護有很多講究。我見過最簡單的實現(xiàn)所有消息都留著直到超出限制再丟棄。這個方案在對話輪數(shù)少時還能湊合一旦聊到幾十輪就面臨兩種結(jié)局——要么舊消息被集中截斷恰好丟掉用戶早期的關(guān)鍵需求要么列表無限膨脹Token成本失控。我的建議是采用“滑動窗口摘要歸檔”的組合策略?；瑒哟翱诒ＷC最近N輪原始消息完整保留因為這些是當前語境最需要的內(nèi)容更早的消息觸發(fā)摘要機制壓縮成幾句話留在窗口里既保留了核心信息又控制了體積。實現(xiàn)時有兩個參數(shù)需要調(diào)窗口保留的消息條數(shù)和摘要觸發(fā)時機。具體參數(shù)怎么定取決于模型的上下文長度。以常見的8000 Token窗口為例系統(tǒng)提示大概占1000到1500 Token記憶檢索注入我會留1500到2000 Token短期消息區(qū)放在3000到4000 Token之間還要留出給模型生成回答的空間。如果你把上下文填到頂格模型生成的突發(fā)性會讓請求直接超限這個坑我踩過不止一次。還有一個經(jīng)常被忽略的點短期記憶里每條消息都應(yīng)該帶時間戳和角色標記。時間戳看起來多余但后面跟長期記憶做時效比較時不可或缺。角色標記則能幫模型區(qū)分哪句是用戶說的、哪句是助手自己生成的避免把助手的猜測當成用戶的事實。2.2 長期記憶的沉淀不能只存原始聊天記錄用戶說“我喜歡用表格看數(shù)據(jù)”這是一條有效記憶但如果你把整個聊天記錄都扔進長期存儲等于沒提煉。長期記憶的核心在于“抽取和沉淀”。我在項目里習慣把長期記憶分成三類管理。第一類是事實記憶比如“用戶的職位是產(chǎn)品經(jīng)理”“用戶公司在某市”。這種信息相對穩(wěn)定適合用鍵值對存儲更新邏輯是“新值覆蓋舊值”。第二類是行為偏好比如“回復(fù)要簡潔”“報告用表格”“不喜歡介紹背景”。這類信息需要累積確認只有用戶重復(fù)表達過或明確強調(diào)“以后都這樣”才升級為長期偏好否則容易把一次性的臨時要求固化成永久規(guī)則。第三類是事件摘要比如某次討論的結(jié)論、某個方案的取舍原因。這類是純文本需要定期追加并關(guān)聯(lián)到用戶或項目維度。為什么要把記憶分成這三類因為它們的更新規(guī)則和穩(wěn)定性完全不同。如果不分類所有記憶混合存儲當你需要覆蓋一條舊事實時就可能誤傷仍然有效的偏好當你需要判斷一條信息是否過期時也沒有明確依據(jù)。分類帶來的額外好處是召回時可以按類型做篩選比如“當前是報告場景優(yōu)先取行為偏好里的報告偏好而不是用戶職業(yè)這種與問題無關(guān)的事實”。關(guān)于長期記憶的存儲媒介我不建議一上來就上重型數(shù)據(jù)庫。對于大多數(shù)中小項目一個輕量級文檔型存儲甚至內(nèi)存字典都夠跑很久。關(guān)鍵是先把“抽取→更新→檢索”的循環(huán)打開等數(shù)據(jù)量真到那個規(guī)模再遷移也不遲。2.3 向量存儲的落地細節(jié)切塊、Embedding與元數(shù)據(jù)向量存儲最容易被低估的是“入庫前處理”。很多人以為把文本丟給Embedding接口就能得到好向量其實不然。文本質(zhì)量、切塊方式和元數(shù)據(jù)設(shè)計對檢索效果的影響不亞于Embedding模型本身。先說切塊。事實類記憶通常一條獨立成塊因為原子性就是它的價值。事件摘要和長文檔類記憶則需要按“話題邊界”切塊而不是機械地按字數(shù)截斷。我常用的塊大小在200到500個字符之間如果相鄰塊涉及同一主題還會讓它們重疊50到100個字符防止語義在邊界處斷裂。曾經(jīng)我把一段項目討論記錄按200字硬切結(jié)果“但最終我們放棄了A方案”被切到了下一塊導(dǎo)致召回時模型還以為A方案是最終結(jié)論鬧了大笑話。再說Embedding模型。每個模型都有自己的強項選型時建議直接用你自己的業(yè)務(wù)文本做小樣本評測而不是只看公開榜單。比如你的業(yè)務(wù)中專業(yè)術(shù)語特別多一個通用模型可能理解不了這時換一個在相關(guān)語料上微調(diào)過的模型效果會明顯不同。另外要注意Embedding模型的輸出維度會影響存儲和計算開銷但不用刻意追求高維度重要的是語義相近的文本在向量空間里距離夠近。元數(shù)據(jù)這塊每條向量記錄除了內(nèi)容本身至少要保存記憶類型、來源會話ID、創(chuàng)建時間、更新時間、重要性評分。重要性評分尤其關(guān)鍵它的作用體現(xiàn)在召回排序上當幾條記憶的向量相似度接近時重要性高、更新時間近的記憶應(yīng)該優(yōu)先返回。向量檢索不是只算一個相似度就完事好的召回排序一定是向量相似度、重要性和時效性的綜合結(jié)果。3. 實操過程與核心環(huán)節(jié)實現(xiàn)概念說清楚了接下來是動手環(huán)節(jié)。我盡量用不依賴特定產(chǎn)品的方式寫代碼方便你遷移到自己的技術(shù)棧。核心邏輯很清晰短期記憶管上下文長期記憶管事實向量庫管語義召回。3.1 全局流程記憶如何被寫入和召回先明確整體鏈路。用戶每發(fā)來一條消息系統(tǒng)要做的事情按順序是先從長期記憶庫里檢索與當前問題相關(guān)的記憶再把檢索到的記憶、短期窗口里的歷史消息、當前輸入組合成提示詞交給模型生成回復(fù)回復(fù)完成后更新短期消息列表如果判斷這輪對話產(chǎn)生了值得長期保存的信息再觸發(fā)一次抽取寫入流程。寫入和召回并不是每次對話都做全套。召回是每輪必做只是檢索范圍可以動態(tài)調(diào)整寫入則要設(shè)置條件比如用戶明確表達了偏好、或者出現(xiàn)了新的關(guān)鍵事實時才觸發(fā)。我遇到過不少人把“每輪對話都做抽取”當作默認行為結(jié)果一天下來Token費用高得嚇人長期記憶庫里還沉淀了大量“今天天氣不錯”這類無價值內(nèi)容。流程中還有一個容易被忽略的點記憶召回也可以在對話中途動態(tài)追加。比如用戶聊到一半說“你記得我之前提到的那個需求嗎”這是一個明確的“回憶觸發(fā)信號”此時應(yīng)該做一次更寬松的召回把TopK調(diào)大、閾值降低盡可能找出相關(guān)記憶。3.2 數(shù)據(jù)模型的最小可運行版本先用代碼定義核心數(shù)據(jù)結(jié)構(gòu)。我刻意選了Python標準庫避免引入額外依賴方便你本地直接運行。from dataclasses import dataclass, field from typing import List, Optional import time import math dataclass class MemoryItem: 長期記憶條目 memory_id: str memory_type: str # fact / preference / summary content: str # 必須是一句完整的自然語言描述 metadata: dict field(default_factorydict) importance: int 1 # 1-55 最重要 created_at: float field(default_factorytime.time) updated_at: float field(default_factorytime.time) def to_dict(self) - dict: return { memory_id: self.memory_id, memory_type: self.memory_type, content: self.content, metadata: self.metadata, importance: self.importance, created_at: self.created_at, updated_at: self.updated_at, } dataclass class SessionMessage: 短期記憶里的單條消息 role: str # user / assistant content: str timestamp: float field(default_factorytime.time)這套結(jié)構(gòu)看著簡單但它把長期記憶的核心屬性都表達出來了。memory_type決定更新規(guī)則importance決定召回優(yōu)先級metadata用來記錄場景或項目歸屬。字段不必多夠用就行。3.3 短期記憶管理器的實現(xiàn)短期記憶管理器維護一個消息實例列表并自動執(zhí)行窗口修剪和摘要觸發(fā)。注意事項這里的摘要邏輯需要調(diào)用大模型我寫成接口占位你接上自己的模型即可。class ShortTermWindow: def __init__(self, max_messages: int 12, max_tokens: int 3500): self.messages: List[SessionMessage] [] self.max_messages max_messages self.max_tokens max_tokens def add(self, role: str, content: str) - None: self.messages.append(SessionMessage(rolerole, contentcontent)) self._trim() def _trim(self) - None: # 超出數(shù)量上限時考慮先摘要再丟棄 while len(self.messages) self.max_messages: self._summarize_oldest() def _summarize_oldest(self) - None: # 取最舊的一半做一次性摘要實際應(yīng)調(diào)用大模型接口 old self.messages[: len(self.messages) // 2] remaining self.messages[len(self.messages) // 2:] content \n.join(f{m.role}: {m.content} for m in old) summary summarize_with_llm(content) # 自定義函數(shù)占位 if summary.strip(): self.messages [ SessionMessage(rolesystem, contentf[歷史摘要] {summary}) ] remaining else: # 摘要失敗時直接丟棄最舊一條保證窗口不爆 self.messages remaining def get_recent_messages(self, n: Optional[int] None) - List[SessionMessage]: if n is None: return self.messages return self.messages[-n:]運行時注意一個問題摘要本身也占用Token所以摘要結(jié)果不能太長。我在實操中把摘要控制在100到200字內(nèi)超過就截斷因為摘要的核心功能是“提關(guān)鍵詞”不是“講故事”。另外不要把摘要做得太頻繁超過窗口上限才觸發(fā)否則每輪都調(diào)用大模型成本和延遲都受不了。3.4 向量存儲與召回模塊的實現(xiàn)為了不綁定特定向量庫我用一個簡單的內(nèi)存向量列表來演示。生產(chǎn)環(huán)境你可以換成任意開源的向量檢索組件核心接口大同小異。這里的embedding函數(shù)也需要你接入實際的Embedding模型接口。class MemoryVectorStore: def __init__(self, threshold: float 0.28): self.items [] # 每個元素是 (vector, MemoryItem) self.threshold threshold def add_item(self, item: MemoryItem, vector: List[float]) - None: self.items.append((vector, item)) staticmethod def _cosine_similarity(vec_a: List[float], vec_b: List[float]) - float: dot sum(x * y for x, y in zip(vec_a, vec_b)) norm_a math.sqrt(sum(x * x for x in vec_a)) norm_b math.sqrt(sum(x * x for x in vec_b)) if norm_a 0 or norm_b 0: return 0.0 return dot / (norm_a * norm_b) def search(self, query_vector: List[float], top_k: int 3) - List[MemoryItem]: scored [] for vector, item in self.items: score self._cosine_similarity(query_vector, vector) if score self.threshold: scored.append((score, item)) scored.sort(keylambda x: x[0], reverseTrue) return [item for _, item in scored[:top_k]]search方法的排序邏輯是核心先按閾值過濾掉低相似度的“噪聲記憶”再按相似度排序取TopK。閾值我建議從0.25到0.35之間開始調(diào)。設(shè)得太低召回很多無關(guān)內(nèi)容上下文被污染設(shè)得太高該召回的又召不回來模型顯式失憶。不同Embedding模型產(chǎn)出的分數(shù)分布差異很大換模型后一定要重新校準閾值。這里要強調(diào)一點MemoryVectorStore只是向量索引。真正生產(chǎn)里MemoryItem本身還要落一份持久化存儲比如文檔型數(shù)據(jù)庫因為向量庫里的內(nèi)容可能被重建、遷移而元數(shù)據(jù)和文本本體必須可靠保存。向量庫和存儲要解耦我早期把它們合在一起結(jié)果向量庫一升級全部記憶消失教訓(xùn)非常深刻。3.5 長期記憶的更新與維護寫入長期記憶的邏輯依賴每輪對話后的抽取結(jié)果。抽取可以由模型完成也可以由規(guī)則完成取決于你業(yè)務(wù)里信息結(jié)構(gòu)的穩(wěn)定程度。這里給出一個較通用的更新框架。class LongTermMemoryStore: def __init__(self, vector_store: MemoryVectorStore, embed_fn): self.facts: dict {} # 事實類鍵值對 self.items: list [] # 所有記憶條目 self.vector_store vector_store self.embed_fn embed_fn def add_or_update(self, item: MemoryItem) - None: # 如果是事實類且有相同鍵執(zhí)行覆蓋 key item.metadata.get(key) if item.memory_type fact and key and key in self.facts: old self.facts[key] old.content item.content old.updated_at time.time() item old # 如果是偏好類檢查是否已有同文本記憶 if item.memory_type preference: for existing in self.items: if existing.content item.content: existing.importance min(5, existing.importance 1) item existing break if item not in self.items: self.items.append(item) vector self.embed_fn(item.content) self.vector_store.add_item(item, vector)這段代碼體現(xiàn)了幾個重要細節(jié)事實類記憶用業(yè)務(wù)鍵去重后寫覆蓋偏好類記憶靠文本匹配累加重要性而不是盲目新增。一個偏好被用戶重復(fù)表達三次重要性升到3以上召回排序自然更靠前。摘要類記憶則不做覆蓋而是不斷追加新摘要保持時間線完整。更新長期記憶時還有一個動作不能省被覆蓋的舊值、被合并的舊摘要最好保留一份歷史版本。這樣如果用戶后續(xù)說“我想改回原來的習慣”你還有據(jù)可查。為了節(jié)省存儲歷史版本可以只保留最近幾次或者壓縮成一個變更記錄文本。3.6 提示詞組裝與一組測試結(jié)果記憶檢索出來之后提示詞的拼裝順序直接影響模型采納效果。我的推薦順序是先放系統(tǒng)提示再放檢索到的相關(guān)長期記憶之后是短期歷史消息最后是當前用戶輸入。長期記憶放在歷史消息前面能讓模型在閱讀具體對話前先建立“用戶畫像”如果放在后面模型已經(jīng)讀了大量對話容易把記憶信息當成普通聊天內(nèi)容權(quán)重下降。給記憶內(nèi)容加一個明顯的標記也很有效。例如def build_prompt(system_prompt: str, memories: List[MemoryItem], history: List[SessionMessage], current_input: str) - str: memory_text \n.join( f[長期記憶] {item.content} for item in memories ) history_text \n.join( f{msg.role}: {msg.content} for msg in history[-8:] ) return f{system_prompt}\n\n{memory_text}\n\n{history_text}\n\n用戶: {current_input}我拿一個簡化場景做過測試。用戶第一天說“我周五下午都不方便開會”系統(tǒng)在對話后抽取了一條事實記憶“用戶周五下午不方便開會”寫入長期存儲并向量化。第三天用戶問“幫我安排周五的復(fù)盤會”系統(tǒng)先召回這條事實拼進提示詞模型就能正確避開周五下午。對照組不接記憶系統(tǒng)模型給出的是周五下午開會方案。差別非常直觀。這個測試也暴露出一個關(guān)鍵點長期記憶的抽取質(zhì)量決定了整個系統(tǒng)的上限。如果對話后抽取環(huán)節(jié)沒有抓出這條“周五下午不方便”的事實后面向量召回再準也沒用。所以我在項目里會把抽取結(jié)果做成日志定期抽查看是否有重要信息被漏抽。4. 常見問題與排查技巧實錄這一章要解決的問題基本都是我在真實項目中反復(fù)調(diào)試過的。有些問題看起來很隱蔽但一旦出現(xiàn)會直接影響用戶對產(chǎn)品的信任度。我把它們整理成一份“排障手冊”希望能幫你少走彎路。4.1 為什么檢索出來的記憶驢唇不對馬嘴最典型的現(xiàn)象是用戶明明提過某個偏好檢索結(jié)果卻召回了一條毫不相關(guān)的記憶。排查第一步不是懷疑向量庫而是去看入庫文本本身。很多人保存記憶時用的是碎片化短語比如“咖啡美式不加糖”。這種文本向量化之后就像幾個脫線的點語義極其不穩(wěn)定檢索時根本對不準。正確的入庫格式是完整自然句“用戶習慣喝美式咖啡不加糖”。這句話是一個完整的語義單元向量化之后方向穩(wěn)定。也不要為了省Token把記憶內(nèi)容壓得太短這個“省”的代價最終會以召回不準的形式還回來反而虧得更多。另一個常見原因是切塊的邊界切斷了語義。如果某條記憶是“這個方案的優(yōu)勢是開發(fā)成本低”被切開后變成了“這個方案的優(yōu)勢是”語義直接殘缺。解決方法是按話題邊界切塊而不是按固定字符數(shù)硬切對于從長文檔處理的記憶建議保留重疊區(qū)。4.2 短期窗口和長期記憶互相打架怎么辦一款A(yù)I助手如果同時注入“用戶希望回復(fù)盡量簡短”這條長期偏好而當前對話里用戶又說“這次請詳細一點”模型就會收到矛盾指令。短期窗口代表當下需求長期記憶代表穩(wěn)定偏好兩者沖突時我通常偏向讓短期消息優(yōu)先因為用戶當前的明確指令權(quán)重更高。更可取的是給記憶加“場景限定字段”。比如“回復(fù)盡量簡短”的范圍是“日常問答”“詳細一點”的范圍是“技術(shù)方案解釋”。召回時如果當前對話能識別出場景就優(yōu)先返回匹配場景的記憶識別不出時才返回通用的全局偏好。這種按場景過濾的做法比單純按時間戳“后說覆蓋先說”要穩(wěn)健得多因為用戶的一個偏好并不總是對所有場景成立。4.3 上下文膨脹和成本失控怎么控制短期記憶的Token膨脹是最常見的成本黑洞。如果窗口管理做得不好每輪都攜帶全部歷史費用會一路攀升?？刂剖侄挝仪懊嫣徇^核心是“摘要壓縮數(shù)量上限”。還要注意摘要本身的質(zhì)量摘要太長的結(jié)果是“壓縮了個寂寞”。向量檢索這一環(huán)也會帶來成本。每輪對話都要把用戶輸入向量化一次如果記憶庫很大檢索耗時也會增長。我的做法是加一層向量緩存相同或相似的用戶問題不再重復(fù)Embedding直接命中緩存結(jié)果。還有一個更實用的經(jīng)驗不要每輪都重新Embedding全部記憶文本而是在寫入時就生成好向量并持久化查詢時只Embedding查詢語句本身即可。4.4 常見問題速查表現(xiàn)象可能原因建議處理方式召回的全是無關(guān)內(nèi)容記憶文本碎片化或者切塊切斷語義保證入庫內(nèi)容是完整句子按話題邊界切塊模型不采納已檢索到的記憶記憶在提示詞中的位置太靠后放在系統(tǒng)提示之后、歷史消息之前并加“長期記憶”標記新舊記憶互相矛盾缺少場景限定全用時間戳覆蓋增加metadata.scene字段按場景做過濾召回短期上下文持續(xù)膨脹沒有觸發(fā)摘要只做簡單丟棄設(shè)置“超出窗口上限才摘要”的機制跨天對話像是失憶事實類記憶沒單獨建索引事實記憶用結(jié)構(gòu)化鍵值存儲不依賴向量召回向量召回結(jié)果穩(wěn)定但相似度普遍偏低Embedding模型與業(yè)務(wù)文本不匹配用業(yè)務(wù)樣本做小批量評測必要時更換模型每次寫入都調(diào)用Embedding成本太高沒有做向量持久化緩存寫入時生成向量并落盤查詢時只Embedding用戶輸入5. 進階擴展與個人體會5.1 最小實現(xiàn)原則先用最輕的方式跑通我見過太多團隊在項目第一天就引入重量級分布式存儲結(jié)果花了兩個星期搭建基礎(chǔ)設(shè)施核心的記憶邏輯一行都沒寫。我的建議恰恰相反先用內(nèi)存、字典和一個簡單的向量列表把整個鏈路跑通讓“抽取→寫入→召回→注入”這個過程先形成閉環(huán)。數(shù)據(jù)量到了十萬條以上再考慮換更專業(yè)的向量檢索組件或者分庫方案。這個順序能幫你把注意力放在最核心的準確率問題上而不是過早被工程復(fù)雜度拖垮。5.2 記憶系統(tǒng)的評估需要獨立的測試集如果只用“用戶覺得AI聰不聰明”來衡量記憶系統(tǒng)你很難定位問題。我后來專門建了一套記憶評測集50到100個模擬場景每個場景都寫清楚“應(yīng)該召回哪條記憶、期望模型給出什么行為”。每次調(diào)整切塊策略、換Embedding模型、改閾值都跑一遍評測用召回率和命中率對比效果。這套評測集看起來費功夫但它能讓你的優(yōu)化方向有據(jù)可循。沒有評測集的記憶系統(tǒng)優(yōu)化基本等于盲調(diào)。5.3 關(guān)于記憶更新時機的一個經(jīng)驗最后分享一個讓我省了很多錢的小技巧記憶更新的時機不要放在每一輪對話后而要設(shè)置明確的觸發(fā)器。當用戶說出“記住”“以后都”“我不喜歡”這類指令性表達或者在一個話題的討論告一段落時才觸發(fā)抽取流程。這樣做有兩個好處一是節(jié)省大量模型調(diào)用成本二是避免在無關(guān)閑聊中生成大量垃圾記憶。記憶系統(tǒng)的核心目標永遠是“記得準、想得起、用得上”而不是“存得多”。把握住這個原則你在設(shè)計每個環(huán)節(jié)時都不會走偏。