1. 項(xiàng)目概述當(dāng)對話智能體擁有了“時間感”最近在折騰大語言模型應(yīng)用時我一直在思考一個問題我們?nèi)绾巫屢粋€對話智能體Conversational Agent真正記住過去并基于這些記憶進(jìn)行有意義的對話這不僅僅是記住“用戶喜歡咖啡”這么簡單而是要讓智能體理解事件之間的時間順序、因果關(guān)系和長期演變。比如用戶上周說“我打算開始健身”今天問“我上周的計劃進(jìn)展如何”一個理想的智能體應(yīng)該能回憶起那個“開始健身”的意圖并基于此展開對話。這正是“Chronos: Temporal-Aware Conversational Agents with Structured Event Retrieval for Long-Term Memory”這個項(xiàng)目標(biāo)題所指向的核心領(lǐng)域。簡單來說Chronos 是一個為對話智能體賦予“長期記憶”和“時間感知”能力的框架。它的目標(biāo)不是簡單地堆砌聊天記錄而是像人類一樣結(jié)構(gòu)化地存儲和檢索與時間緊密相關(guān)的事件Event讓AI在對話中能主動關(guān)聯(lián)歷史形成連貫的、有深度的交互體驗(yàn)。想象一下一個能記住你三個月前提到的職業(yè)規(guī)劃并在今天詢問你面試結(jié)果的客服機(jī)器人或者一個能追蹤你健康數(shù)據(jù)變化并給出階段性建議的個人助手其價值不言而喻。這個項(xiàng)目直擊了當(dāng)前大模型應(yīng)用的一個痛點(diǎn)上下文窗口有限且模型本身缺乏對長序列中時間關(guān)系的結(jié)構(gòu)化理解。即使有了超長的上下文模型也可能無法精準(zhǔn)定位到“上周三下午提到的那個會議修改”具體是哪條信息。Chronos 的思路是通過一個專門的“事件檢索”模塊將非結(jié)構(gòu)化的對話歷史轉(zhuǎn)化為帶有時間戳、實(shí)體、動作和狀態(tài)變化的結(jié)構(gòu)化事件記錄然后根據(jù)當(dāng)前對話的上下文和時間線索高效、準(zhǔn)確地召回最相關(guān)的歷史事件。從網(wǎng)絡(luò)熱詞中頻繁出現(xiàn)的“OutOfMemoryError”、“insufficient memory”、“memory access violation”可以看出內(nèi)存管理是AI系統(tǒng)尤其是涉及長期記憶的系統(tǒng)普遍面臨的挑戰(zhàn)。Chronos 在設(shè)計中必須精打細(xì)算確保事件檢索和存儲既高效又節(jié)省資源避免成為系統(tǒng)的性能瓶頸。這對于我們實(shí)際部署這類智能體具有重要的參考意義。2. 核心架構(gòu)與設(shè)計思路拆解要理解 Chronos我們不能把它看成一個黑盒而是需要拆解其核心組件和設(shè)計哲學(xué)。它的架構(gòu)可以概括為“一個核心兩大支柱”核心是時間感知的對話管理兩大支柱分別是結(jié)構(gòu)化事件提取與基于時間的向量檢索。2.1 為什么是“結(jié)構(gòu)化事件”而非原始對話這是 Chronos 設(shè)計的第一性原理。原始對話記錄是線性的、非結(jié)構(gòu)化的文本流直接將其存入向量數(shù)據(jù)庫進(jìn)行語義搜索會遇到幾個致命問題信息冗余與噪聲對話中包含大量問候語、語氣詞、重復(fù)確認(rèn)等無關(guān)內(nèi)容會稀釋關(guān)鍵信息的向量表示。時間關(guān)系模糊“之前”、“后來”、“上周”這類相對時間表述在原始文本中無法被機(jī)器直接理解。事件邊界不清一個復(fù)雜的用戶意圖可能跨越多個對話輪次簡單的按句切割會破壞事件的完整性。因此Chronos 引入了“結(jié)構(gòu)化事件”的概念。一個事件通常包含以下幾個關(guān)鍵字段事件ID唯一標(biāo)識符。時間戳事件的絕對發(fā)生時間或?qū)υ捿喆涡蛱?。觸發(fā)詞/動作核心動詞或意圖如“購買”、“預(yù)約”、“決定”。主體與客體誰用戶或系統(tǒng)對什么實(shí)體執(zhí)行了動作。狀態(tài)/結(jié)果事件導(dǎo)致的狀態(tài)變化如“從未完成變?yōu)檫M(jìn)行中”。原始上下文摘要關(guān)聯(lián)的原始對話片段摘要。例如用戶輸入“幫我訂下周一上午10點(diǎn)飛往北京的機(jī)票”經(jīng)過事件提取模塊可能生成如下結(jié)構(gòu)化記錄{ “event_id”: “e_20240527_001”, “timestamp”: “2024-05-27 14:30:00”, “action”: “BOOK_FLIGHT”, “subject”: “user”, “object”: {“type”: “flight”, “destination”: “北京”, “time”: “下周一 10:00”}, “status”: “REQUESTED”, “context_summary”: “用戶請求預(yù)訂飛往北京的航班?！?}這種結(jié)構(gòu)化的表示為后續(xù)的精準(zhǔn)檢索和推理奠定了堅(jiān)實(shí)基礎(chǔ)。2.2 時間感知檢索不僅僅是語義相似度傳統(tǒng)的基于向量相似度的檢索主要關(guān)注“語義上像不像”。但在長期記憶的語境下“時間相關(guān)性”和“邏輯連貫性”同樣重要甚至更重要。Chronos 的檢索模塊因此需要是多路召回、綜合排序的。語義檢索路將當(dāng)前查詢和結(jié)構(gòu)化事件中的關(guān)鍵字段如動作、客體、摘要進(jìn)行向量化通過向量數(shù)據(jù)庫如 Milvus, Pinecone召回語義相關(guān)的事件。這是基礎(chǔ)。時間過濾與衰減路這是體現(xiàn)“Temporal-Aware”的關(guān)鍵。系統(tǒng)會識別當(dāng)前查詢中的時間提及如“上周”、“去年”、“我上次提的時候”并將其轉(zhuǎn)換為具體的時間區(qū)間。檢索時會優(yōu)先考慮時間上更接近的事件。同時可以引入時間衰減函數(shù)讓太久遠(yuǎn)的事件除非語義高度相關(guān)否則排名自動降低。會話/邏輯鏈檢索路系統(tǒng)會維護(hù)事件之間的邏輯鏈接。例如一個“提出問題”的事件可能會鏈接到一個后續(xù)的“解決問題”的事件。當(dāng)用戶追問“那個問題后來怎么處理的”系統(tǒng)可以通過這種邏輯鏈直接定位到后續(xù)事件而不是單純做語義匹配。最終這三路或更多路的召回結(jié)果會通過一個重排序模型Re-ranker進(jìn)行綜合打分選出最相關(guān)、最及時、最符合邏輯的若干個歷史事件注入到大語言模型的上下文窗口中供其生成最終回復(fù)。實(shí)操心得在設(shè)計檢索策略時不要追求一路召回解決所有問題。語義、時間、邏輯多路并行再融合排序是更穩(wěn)健的方案。初期可以用規(guī)則如時間范圍過濾和簡單加權(quán)來實(shí)現(xiàn)融合后期可以收集用戶反饋數(shù)據(jù)訓(xùn)練一個輕量級的重排序模型。3. 核心模塊實(shí)現(xiàn)細(xì)節(jié)與實(shí)操要點(diǎn)理解了設(shè)計思路我們來看看如何動手實(shí)現(xiàn)一個簡化版的 Chronos 核心流程。這里我會以 Python 為例結(jié)合一些主流開源工具進(jìn)行說明。3.1 事件提取模塊的實(shí)現(xiàn)事件提取是源頭質(zhì)量決定一切。我們可以采用“大模型微調(diào)小模型”的混合策略。第一步用大模型進(jìn)行高質(zhì)量數(shù)據(jù)標(biāo)注與范式定義。我們不需要一開始就訓(xùn)練模型。可以先利用 GPT-4、Claude 3 或國內(nèi)主流的 DeepSeek、通義千問等大模型的 API設(shè)計詳細(xì)的提示詞Prompt讓大模型從一批原始對話歷史中按照我們定義的格式抽取出結(jié)構(gòu)化事件。這能快速得到一批高質(zhì)量的種子數(shù)據(jù)。示例提示詞設(shè)計你是一個事件信息提取專家。請從下面的對話片段中識別出用戶或系統(tǒng)完成的具有明確動作和狀態(tài)改變的事件并按照指定JSON格式輸出。 對話歷史 [此處粘貼若干輪對話] 請?zhí)崛∈录總€事件格式如下 { “event_id”: “自動生成的唯一ID格式e_日期_序號”, “timestamp”: “事件發(fā)生的大致時間如2024-05-27 14:30:00如果對話中沒有明確時間則用‘未知’代替”, “action”: “核心動作使用英文大寫動詞短語如BOOK_HOTEL, SET_REMINDER, CHANGE_PLAN”, “subject”: “動作發(fā)起者通常是‘user’或‘system’”, “object”: {“type”: “對象類型”, “details”: “關(guān)鍵細(xì)節(jié)如目的地、商品名、時間等”}, “status”: “事件狀態(tài)如REQUESTED, CONFIRMED, CANCELLED, COMPLETED”, “context_summary”: “與該事件最相關(guān)的1-2句原始對話摘要” } 注意只提取確實(shí)改變了某些狀態(tài)或表達(dá)了明確意圖的事件日常寒暄不提取。第二步基于種子數(shù)據(jù)微調(diào)專用的小模型。大模型API調(diào)用成本高、延遲大不適合生產(chǎn)環(huán)境實(shí)時處理。我們可以用第一步得到的高質(zhì)量數(shù)據(jù)去微調(diào)一個參數(shù)規(guī)模較小的、專門用于信息抽取的模型。例如BERT/ChatGLM CRF傳統(tǒng)但有效的序列標(biāo)注方法可以識別事件中的實(shí)體和動作類型。UIE (Universal Information Extraction)百度開源的統(tǒng)一信息抽取框架schema 定義靈活非常適合這種結(jié)構(gòu)化抽取任務(wù)。微調(diào)一個輕量級LLM使用 QLoRA 等技術(shù)在 ChatGLM-6B、Qwen-7B 等模型上做指令微調(diào)讓其學(xué)會按照固定格式輸出事件JSON。注意事項(xiàng)事件提取的 schema有哪些字段字段取值有哪些需要根據(jù)你的垂直領(lǐng)域精心設(shè)計。電商領(lǐng)域的事件瀏覽、加購、支付、售后和健康管理領(lǐng)域的事件記錄體重、服藥、出現(xiàn)癥狀完全不同。Schema 設(shè)計是核心業(yè)務(wù)邏輯的體現(xiàn)。3.2 向量數(shù)據(jù)庫與混合檢索的實(shí)現(xiàn)存儲和檢索是性能的關(guān)鍵。我們選擇將結(jié)構(gòu)化事件的關(guān)鍵文本字段如actionobject.detailscontext_summary拼接起來生成一個“事件描述文本”然后將其向量化存儲。工具選型向量數(shù)據(jù)庫Milvus或Qdrant。兩者都支持高性能向量檢索和標(biāo)量過濾。Qdrant 的過濾語法對于時間范圍查詢非常直觀。Pinecone是全托管服務(wù)省心但成本較高。嵌入模型建議使用專門為檢索優(yōu)化的模型如BGE-M3、text2vec系列或 OpenAI 的text-embedding-3。它們生成的向量在語義相似度任務(wù)上表現(xiàn)更好?；旌蠙z索查詢示例偽代碼import qdrant_client from datetime import datetime, timedelta # 1. 解析用戶查詢中的時間信息 current_query “我上周說的那個健身計劃第一步是什么來著” time_window parse_time_mention(current_query) # 解析出“上周”對應(yīng)的時間范圍如 [‘2024-05-20’, ‘2024-05-26’] # 2. 構(gòu)建 Qdrant 搜索請求 search_result client.search( collection_name”chronos_events”, query_vectorembedding_model.encode(current_query), # 語義向量 query_filterFilter( must[ FieldCondition(key”timestamp”, rangeRange( gtetime_window[0], ltetime_window[1] )), # 可以添加其他過濾條件如 subject“user” ] ), limit10, # 每路召回數(shù)量 with_payloadTrue # 返回完整的事件數(shù)據(jù) ) # 3. 語義召回結(jié)果search_result已經(jīng)包含了時間過濾 # 4. 可選邏輯鏈召回如果查詢涉及“計劃的第一步”可以額外查詢 action“CREATE_PLAN” 且與當(dāng)前用戶相關(guān)的初始事件然后獲取其鏈接的后續(xù)事件。 # 5. 將多路召回結(jié)果合并、去重送入重排序環(huán)節(jié)。參數(shù)調(diào)優(yōu)心得向量檢索的limit參數(shù)不宜過小避免遺漏時間過濾的范圍可以適當(dāng)放寬如解析出“上周”可以前后多擴(kuò)一天以防時間解析誤差。重排序模型初期可以用Cross-Encoder如BGE-Reranker來實(shí)現(xiàn)它比雙塔式的向量模型更能把握查詢和候選之間的細(xì)微相關(guān)性。4. 內(nèi)存管理與系統(tǒng)優(yōu)化實(shí)戰(zhàn)正如網(wǎng)絡(luò)熱詞所反映的內(nèi)存問題是工程落地的攔路虎。一個持續(xù)運(yùn)行、不斷積累事件的 Chronos 系統(tǒng)必須考慮內(nèi)存和存儲的優(yōu)化。4.1 事件存儲的冷熱分層不是所有事件都需要被高頻檢索。我們可以采用分層存儲策略熱存儲最近30天的事件、狀態(tài)為“進(jìn)行中”如PENDING,IN_PROGRESS的事件、被標(biāo)記為重要的用戶事件。這部分?jǐn)?shù)據(jù)常駐內(nèi)存或高速SSD支持低延遲檢索。溫存儲30天至1年的事件。存儲在性能稍低的數(shù)據(jù)庫或磁盤上檢索延遲可以接受。冷存儲/歸檔1年以上的歷史事件?？梢詨嚎s后存入對象存儲如 S3、OSS僅用于全量分析或非常罕見的深度歷史查詢。實(shí)現(xiàn)上可以給事件表增加一個storage_tier字段并有一個后臺任務(wù)定期根據(jù)時間和事件狀態(tài)遷移數(shù)據(jù)。4.2 向量索引的優(yōu)化與壓縮全量事件的向量全部加載到內(nèi)存是不現(xiàn)實(shí)的。必須利用向量數(shù)據(jù)庫的索引和量化功能。使用 IVF 類索引如 Qdrant 的HNSW或 Milvus 的IVF_FLAT。它們通過聚類建立導(dǎo)航圖大大加速檢索速度雖然會損失極小精度但可接受。創(chuàng)建索引時需要根據(jù)數(shù)據(jù)量調(diào)整mHNSW 的層間連接數(shù)和ef_construction索引構(gòu)建參數(shù)等參數(shù)在構(gòu)建速度和召回率之間權(quán)衡。啟用標(biāo)量量化將原始的 float32 向量量化為 int8可以減少75%的內(nèi)存占用對精度影響很小是性價比極高的優(yōu)化手段。在 Qdrant 中可以在創(chuàng)建集合時指定quantization_config。分片如果事件量極大數(shù)億以上需要將向量集合進(jìn)行分片分布到不同節(jié)點(diǎn)。4.3 防止內(nèi)存泄漏與訪問沖突那些“0xC0000005內(nèi)存訪問沖突”錯誤往往是底層C庫或驅(qū)動問題。在部署時需注意依賴版本鎖定確保向量數(shù)據(jù)庫客戶端、GPU驅(qū)動、CUDA版本、PyTorch等深度學(xué)習(xí)框架版本嚴(yán)格兼容。使用 Docker 鏡像或 Conda 環(huán)境固化版本是最佳實(shí)踐。資源限制與監(jiān)控為 Chronos 的服務(wù)進(jìn)程設(shè)置明確的內(nèi)存上限如通過 Docker 的-m參數(shù)。在代碼中對處理單次查詢消耗的臨時內(nèi)存進(jìn)行預(yù)估和控制避免處理超長歷史時爆內(nèi)存。優(yōu)雅降級當(dāng)系統(tǒng)內(nèi)存壓力大時應(yīng)能自動降級。例如暫時關(guān)閉重排序模型僅用向量檢索或縮小檢索的時間窗口范圍優(yōu)先保證核心服務(wù)可用。一個簡單的內(nèi)存監(jiān)控與降級策略可以是import psutil import resource def check_memory_pressure(): process psutil.Process() mem_usage process.memory_info().rss / 1024 / 1024 # MB if mem_usage WARNING_THRESHOLD_MB: # 觸發(fā)降級策略 current_config.USE_RERANKER False current_config.MAX_RETRIEVAL_YEARS 1 # 只檢索一年內(nèi)事件 logging.warning(f“內(nèi)存使用率高 ({mem_usage}MB)已啟用降級模式?！?5. 典型應(yīng)用場景與效果調(diào)優(yōu)Chronos 這類系統(tǒng)不是空中樓閣最終要落到具體的業(yè)務(wù)場景中創(chuàng)造價值。下面以兩個典型場景為例說明如何針對性調(diào)優(yōu)。5.1 場景一高端客戶服務(wù)助手在這個場景下核心需求是提供精準(zhǔn)、連貫、個性化的服務(wù)。用戶可能間隔數(shù)周甚至數(shù)月再次咨詢客服助手需要立刻“想起”之前的工單、承諾和偏好。事件Schema設(shè)計重點(diǎn)action需要細(xì)化CREATE_TICKET,ESCALATE,PROMISE_CALLBACK,PROVIDE_SOLUTION,USER_PREFERENCE_UPDATED。object需要包含工單ID、產(chǎn)品型號、問題分類。status至關(guān)重要OPEN,IN_PROGRESS,RESOLVED,FOLLOW_UP_NEEDED。對于未關(guān)閉的事件檢索優(yōu)先級要調(diào)至最高。檢索策略調(diào)優(yōu)強(qiáng)過濾檢索時必須帶上customer_id嚴(yán)格隔離不同用戶的數(shù)據(jù)。時間衰減敏感對于已解決RESOLVED的工單時間衰減因子要加大讓系統(tǒng)更關(guān)注近期和未解決的互動。邏輯鏈強(qiáng)化工單的創(chuàng)建、升級、解決應(yīng)形成強(qiáng)邏輯鏈。當(dāng)用戶問“我上次那個電腦問題的工單怎樣了”系統(tǒng)應(yīng)能直接通過工單ID或主題關(guān)聯(lián)到整個事件鏈。效果評估指標(biāo)事件召回準(zhǔn)確率人工評估系統(tǒng)召回的歷史事件是否與當(dāng)前查詢真正相關(guān)。用戶滿意度直接調(diào)查或通過對話結(jié)束后的好評率來衡量。問題解決輪次引入長期記憶后平均需要多少輪對話能解決一個復(fù)雜問題理論上應(yīng)該減少。5.2 場景二個人健康管理伴侶在這個場景下核心需求是追蹤趨勢、提供洞察、主動關(guān)懷。系統(tǒng)需要從用戶零散記錄的癥狀、用藥、運(yùn)動中提煉出健康模式。事件Schema設(shè)計重點(diǎn)action類型RECORD_SYMPTOM,TAKE_MEDICATION,LOG_EXERCISE,LOG_WEIGHT,LOG_MOOD。object需要結(jié)構(gòu)化數(shù)值如{“type”: “symptom”, “name”: “headache”, “intensity”: 7}{“type”: “exercise”, “name”: “running”, “duration_minutes”: 30}。需要新增metric字段用于記錄具體的生理指標(biāo)值。檢索策略調(diào)優(yōu)基于指標(biāo)的相似檢索當(dāng)用戶說“我今天又感覺有點(diǎn)頭暈”系統(tǒng)不僅要檢索“頭暈”這個癥狀事件還應(yīng)檢索歷史上所有metric如血壓、睡眠數(shù)據(jù)異常的事件看是否存在關(guān)聯(lián)。周期性模式檢索后臺可以運(yùn)行離線任務(wù)檢測事件發(fā)生的周期性如每周一記錄頭痛并將這種“模式”本身作為一個高級別的事件存入在相關(guān)時間點(diǎn)主動觸發(fā)關(guān)懷或提醒。檢索結(jié)果后處理返回給大模型的不僅是事件列表還可以附帶簡單的統(tǒng)計圖表描述如“過去一周您的頭痛頻率較前一周增加了50%”增強(qiáng)模型的洞察力。效果評估指標(biāo)趨勢發(fā)現(xiàn)準(zhǔn)確性系統(tǒng)發(fā)現(xiàn)的健康模式如“睡眠不足后次日必頭痛”是否被用戶確認(rèn)。用戶依從性在系統(tǒng)提醒下用戶記錄數(shù)據(jù)、服藥、運(yùn)動的依從性是否有提升。對話深度對話是否從簡單的問答進(jìn)階到基于歷史數(shù)據(jù)的分析和建議討論。6. 常見踩坑點(diǎn)與排查指南在實(shí)際開發(fā)和運(yùn)維 Chronos 系統(tǒng)的過程中我遇到了不少坑。這里總結(jié)一份問題排查清單希望能幫你節(jié)省時間。問題現(xiàn)象可能原因排查步驟與解決方案檢索結(jié)果完全不相關(guān)甚至混亂1. 事件提取錯誤生成了噪聲數(shù)據(jù)。2. 向量嵌入模型不適合領(lǐng)域。3. 向量索引未正確構(gòu)建或已損壞。1.檢查數(shù)據(jù)源頭抽樣查看存入向量庫的“事件描述文本”是否準(zhǔn)確、干凈。2.測試嵌入模型用一些標(biāo)準(zhǔn)句對測試嵌入模型的相似度判斷是否合理。考慮更換或微調(diào)嵌入模型。3.重建索引嘗試在向量數(shù)據(jù)庫中刪除并重新創(chuàng)建集合Collection和索引。系統(tǒng)響應(yīng)緩慢延遲高1. 單次檢索事件數(shù)量limit設(shè)置過大。2. 向量索引類型選擇不當(dāng)如對小數(shù)據(jù)集用了需要大量計算的索引。3. 未使用標(biāo)量過濾進(jìn)行了全表掃描。4. 服務(wù)端資源CPU/內(nèi)存不足。1.優(yōu)化查詢參數(shù)逐步調(diào)低limit觀察精度和延遲的平衡點(diǎn)。2.評估索引對于千萬級以下數(shù)據(jù)HNSW通常是速度和精度兼顧的好選擇。確保ef_search參數(shù)未設(shè)置過高。3.強(qiáng)制使用過濾確保查詢時使用了有效的時間或ID過濾大幅縮小搜索空間。4.監(jiān)控資源使用top,htop,nvidia-smi等工具監(jiān)控考慮橫向擴(kuò)展或升級硬件。遇到 “Out of Memory” 或 “0xC0000005” 崩潰1. 處理批量事件時內(nèi)存激增。2. 向量數(shù)據(jù)庫服務(wù)或嵌入模型推理服務(wù)內(nèi)存泄漏。3. 系統(tǒng)依賴庫沖突或不兼容。1.實(shí)現(xiàn)流式處理對大批量事件進(jìn)行提取或向量化時采用分批次處理及時釋放內(nèi)存。2.隔離服務(wù)將向量數(shù)據(jù)庫、嵌入模型推理服務(wù)分別部署在獨(dú)立容器中并設(shè)置嚴(yán)格的內(nèi)存限制。3.統(tǒng)一環(huán)境使用 Docker 鏡像確保開發(fā)、測試、生產(chǎn)環(huán)境的一致性。檢查 CUDA、驅(qū)動、框架版本匹配性。長期運(yùn)行后最近的事件似乎被“遺忘”1. 時間衰減函數(shù)過于激進(jìn)新事件權(quán)重過低。2. 檢索邏輯中對“狀態(tài)”為進(jìn)行中的事件沒有給予額外權(quán)重。3. 新事件向量尚未成功索引異步索引延遲。1.調(diào)整衰減參數(shù)讓時間衰減曲線在近期如7天內(nèi)更加平緩。2.修改排序公式在重排序模型中為statusPENDING/IN_PROGRESS的事件添加固定的權(quán)重加分。3.檢查索引機(jī)制確認(rèn)向量數(shù)據(jù)庫的索引是否是實(shí)時或近實(shí)時更新的。對于增量數(shù)據(jù)確保調(diào)用了upsert并觸發(fā)了索引刷新。用戶感覺對話“跳躍”關(guān)聯(lián)生硬1. 注入到LLM上下文中的歷史事件過多或過雜干擾了主要指令。2. 事件之間的邏輯關(guān)系未被LLM理解。1.精簡上下文嚴(yán)格控制注入事件的數(shù)量如3-5個并確保在Prompt中清晰說明這些事件的用途“以下是相關(guān)的歷史背景”。2.增強(qiáng)事件表示在給LLM的事件描述中可以人工添加一句關(guān)系說明如“【該事件導(dǎo)致了后續(xù)的XXX事件】”。或者嘗試使用圖數(shù)據(jù)庫存儲事件關(guān)系檢索時返回子圖。最后我想分享一點(diǎn)最深的體會構(gòu)建一個擁有長期記憶的對話系統(tǒng)技術(shù)實(shí)現(xiàn)只是一半另一半是對業(yè)務(wù)和用戶需求的深刻理解。事件Schema的設(shè)計本質(zhì)上是在用數(shù)據(jù)模型定義你希望AI關(guān)注世界的哪些方面。檢索策略的調(diào)優(yōu)則是在教AI如何像人一樣根據(jù)當(dāng)下的情境從紛繁的記憶中提取出最有價值的片段。這個過程沒有一勞永逸的銀彈需要不斷地與真實(shí)用戶對話觀察、分析、迭代。當(dāng)你看到AI終于能自然地提起“你上周提到的書買到了嗎”那種感覺就像教會了一個孩子如何真正地傾聽和回憶。