優(yōu)指南：從延遲排查到配置優(yōu)化，改善內(nèi)存占用與查詢速度)
Hindsight 性能調(diào)優(yōu)指南從延遲排查到配置優(yōu)化改善內(nèi)存占用與查詢速度【免費(fèi)下載鏈接】hindsightHindsight: Agent Memory That Learns項(xiàng)目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight給 AI 代理接上 Hindsight一個(gè)給 Agent 提供持久記憶的內(nèi)存系統(tǒng)之后常見的第一步是跑得通第二步才是要跑得快。典型踩坑場景是這樣的記憶數(shù)據(jù)攢了幾周recall查詢從百毫秒級滑到秒級容器內(nèi)存曲線緩慢爬坡偶爾還出現(xiàn)連接池告警。很多人第一反應(yīng)是加機(jī)器但 Hindsight 的性能瓶頸通常集中在幾個(gè)可配置的點(diǎn)上——數(shù)據(jù)庫連接、向量索引、召回預(yù)算、模型調(diào)用并發(fā)。這篇筆記按先測量、再調(diào)優(yōu)的思路把 Hindsight 性能調(diào)優(yōu)中的內(nèi)存優(yōu)化與查詢速度優(yōu)化拆開講重點(diǎn)落在幾個(gè)高收益配置上。先測量、再調(diào)優(yōu)延遲排查的主線調(diào) Hindsight 之前先回答一個(gè)問題慢在哪一段Hindsight API 內(nèi)置了 OpenTelemetry 指標(biāo)全部暴露在/metrics端點(diǎn)定義見 metrics.py涵蓋五類操作延遲retain/recall/reflect三類操作各一個(gè)直方圖形如hindsight_operation_duration_seconds_bucket{operationrecall}可直接算 p50/p95/p99LLM 調(diào)用延遲與 token 用量按 scope 維度拆分能區(qū)分慢在模型還是慢在檢索進(jìn)程指標(biāo)CPU、內(nèi)存、文件描述符、線程數(shù)數(shù)據(jù)庫連接池池內(nèi)連接數(shù)與等待情況異步操作積壓backlog隊(duì)列深度按租戶、操作類型、bank 拆分排查時(shí)按這張對照表定位現(xiàn)象優(yōu)先懷疑對應(yīng)指標(biāo)recall 整體變慢LLM 延遲正常檢索并發(fā) / 向量索引operation 直方圖 連接池LLM 延遲升高操作延遲同步升高模型并發(fā)上限過低或 provider 限流LLM 延遲直方圖內(nèi)存緩漲、無陡增鞏固consolidation積壓或數(shù)據(jù)膨脹backlog 進(jìn)程內(nèi)存寫入慢、讀正常連接池不足或?qū)懭氪谢B接池等待官方倉庫里帶 Grafana 面板可以直接導(dǎo)入后對照上述指標(biāo)看趨勢monitoring/grafana/。拿到基線之后再動(dòng)配置一次只調(diào)一個(gè)參數(shù)對比同一指標(biāo)的前后數(shù)值。這樣優(yōu)化才不會(huì)變成玄學(xué)。存儲與索引連接池、向量擴(kuò)展、銀行策略為什么先看存儲Hindsight 的核心數(shù)據(jù)都在 PostgreSQL 里向量搜索依賴 Postgres 的向量擴(kuò)展。連接池和索引方式?jīng)Q定了查詢速度的下限。連接池怎么配主池默認(rèn)是min 5 / max 100見 config.py多數(shù)單實(shí)例部署用默認(rèn)值即可。如果你的讀多寫少、或已經(jīng)配了只讀副本讀寫分離是比調(diào)大池子更有效的做法——讀壓力不再擠占寫入連接HINDSIGHT_API_READ_DATABASE_URLpostgres://user:passreplica:5432/hindsight HINDSIGHT_API_READ_DB_POOL_MIN_SIZE5 HINDSIGHT_API_READ_DB_POOL_MAX_SIZE50沒有副本時(shí)優(yōu)先觀察連接池等待指標(biāo)再?zèng)Q定要不要調(diào)大HINDSIGHT_API_DB_POOL_MAX_SIZE盲目調(diào)大只會(huì)把壓力轉(zhuǎn)嫁給數(shù)據(jù)庫。向量索引用哪種擴(kuò)展通過HINDSIGHT_API_VECTOR_EXTENSION選擇默認(rèn)pgvector可選vchord、pgvectorscale、scann校驗(yàn)邏輯在 _vector_index.py。pgvector 生態(tài)最穩(wěn)數(shù)據(jù)量在幾十萬向量以內(nèi)通常夠用規(guī)模更大、或追求更高召回吞吐時(shí)vchord 等 HNSW 類擴(kuò)展的檢索效率通常更好——這類切換建議先在測試庫實(shí)測 p95 延遲再上生產(chǎn)。銀行bank策略bank 是 Hindsight 的隔離單位。單 bank 場景檢索路徑最短、查詢速度快多租戶或多 agent 用多 bank 換取隔離。bank 數(shù)量會(huì)直接影響 schema 級資源bank 越多單查詢的固定開銷越高多 bank 部署時(shí)更值得盯連接池與 bank 統(tǒng)計(jì)緩存相關(guān)指標(biāo)。檢索與召回召回預(yù)算和并發(fā)是最快的查詢速度旋鈕recall 是讀路徑上延遲最敏感的操作相關(guān)默認(rèn)值都在 config.py行為可用 test_recall_config.py 對照驗(yàn)證。召回并發(fā)與連接預(yù)算# 每個(gè) worker 同時(shí)執(zhí)行的 recall 上限默認(rèn) 32 HINDSIGHT_API_RECALL_MAX_CONCURRENT32 # 單次 recall 占用的數(shù)據(jù)庫連接數(shù)默認(rèn) 4 HINDSIGHT_API_RECALL_CONNECTION_BUDGET4為什么這兩個(gè)值要一起看RECALL_MAX_CONCURRENT × RECALL_CONNECTION_BUDGET決定了 recall 對連接池的峰值需求。如果這個(gè)乘積超過池上限r(nóng)ecall 會(huì)排隊(duì)表現(xiàn)是 p95 延遲階梯式變差。調(diào)參方向是保持乘積小于池max_size并留余量而不是單純把并發(fā)拉滿。用 token 預(yù)算控制返回量這是內(nèi)存優(yōu)化里性價(jià)比最高的一檔。內(nèi)部召回如 mental model 刷新返回多少內(nèi)容由 token 預(yù)算決定默認(rèn)fixed函數(shù)按查詢復(fù)雜度給 100/300/1000 token 三檔HINDSIGHT_API_RECALL_BUDGET_FUNCTIONfixed HINDSIGHT_API_RECALL_BUDGET_FIXED_LOW100 HINDSIGHT_API_RECALL_BUDGET_FIXED_MID300 HINDSIGHT_API_RECALL_BUDGET_FIXED_HIGH1000預(yù)算給得過大下游 prompt 膨脹、序列化與傳輸成本上升還會(huì)擠壓 context window給得過小則召回質(zhì)量下降。建議先用默認(rèn)值跑一段時(shí)間按hindsight_operation_duration_seconds_bucket和 token 用量直方圖決定往哪邊調(diào)。HINDSIGHT_API_RECALL_MAX_QUERY_TOKENS默認(rèn) 500則限制查詢語句本身的長度長查詢會(huì)放大檢索開銷對上游傳入的 query 做截?cái)嗤瑯佑行АＤＰ驼{(diào)用LLM 并發(fā)、嵌入、重排序與鞏固記憶系統(tǒng)的慢經(jīng)常不是數(shù)據(jù)庫慢而是 LLM 慢。Hindsight 內(nèi)部有 retain寫入抽取、reflect回答合成、consolidation記憶鞏固三類模型調(diào)用各有獨(dú)立的并發(fā)與超時(shí)配置。LLM 并發(fā)按 provider 限流反推HINDSIGHT_API_LLM_MAX_CONCURRENT10 HINDSIGHT_API_LLM_TIMEOUT120云 providerOpenAI、Anthropic 等上限取決于賬戶限流配高只會(huì)觸發(fā) 429 與重試本地模型Ollama 等通常 1-2 并發(fā)即已打滿。per-operation 變體如RETAIN_LLM_MAX_CONCURRENT、REFLECT_LLM_MAX_CONCURRENT可以單獨(dú)壓制某條路徑避免 consolidate 批任務(wù)把在線 recall 的資源吃光。鞏固consolidation是內(nèi)存優(yōu)化的主戰(zhàn)場它把相似記憶合并、去除冗余長期看直接降低存儲與檢索的數(shù)據(jù)量。HINDSIGHT_API_CONSOLIDATION_BATCH_SIZE控制單輪處理的記憶數(shù)量批次過大單輪耗時(shí)長、過小調(diào)度開銷高默認(rèn)值在多數(shù)規(guī)模下夠用積壓時(shí)再結(jié)合 backlog 指標(biāo)上調(diào)。嵌入與重排序按質(zhì)量-延遲權(quán)衡選擇嵌入模型決定向量檢索質(zhì)量與速度本地小模型如HINDSIGHT_API_EMBEDDINGS_LOCAL_MODEL指定的輕量模型延遲低、幾乎不占外部成本但多語言與長文本表現(xiàn)弱于云嵌入云嵌入則通過HINDSIGHT_API_EMBEDDINGS_MAX_CONCURRENT_REQUESTS控制并發(fā)。重排序器同理云 reranker如 cohere、google質(zhì)量更高但引入一次網(wǎng)絡(luò)往返延遲通常增加數(shù)百毫秒到秒級本地 reranker 資源消耗低、延遲可控。對查詢速度敏感的在線場景重排序器選型往往比任何索引參數(shù)都更影響體感。運(yùn)維保障日志、告警與容量節(jié)奏日志級別生產(chǎn)建議HINDSIGHT_API_LOG_LEVELwarning配 JSON 格式輸出debug 級別的日志 I/O 在高 QPS 下本身就會(huì)吃掉可觀的延遲預(yù)算排查特定問題時(shí)按操作類型開局部日志而不是整機(jī) debug。告警規(guī)則基于操作直方圖設(shè)延遲告警、基于進(jìn)程內(nèi)存設(shè)水位告警、基于 backlog 設(shè)積壓告警。一個(gè)可用的起點(diǎn)- alert: HighRecallLatency expr: histogram_quantile(0.95, rate(hindsight_operation_duration_seconds_bucket{operationrecall}[5m])) 1 for: 5m容量節(jié)奏向量數(shù)據(jù)增長是單調(diào)的建議每月看一次 p95 延遲趨勢與 bank 數(shù)據(jù)量曲線趨勢性上升時(shí)先考慮鞏固參數(shù)和索引擴(kuò)展再考慮橫向擴(kuò)實(shí)例。調(diào)優(yōu)要點(diǎn)匯總維度關(guān)鍵配置解決的問題調(diào)參原則存儲與索引DB_POOL_MAX_SIZE、READ_DATABASE_URL連接等待、讀壓力讀寫分離優(yōu)先于調(diào)大池子存儲與索引VECTOR_EXTENSION向量檢索效率測試庫實(shí)測后切換檢索與召回RECALL_MAX_CONCURRENT、RECALL_CONNECTION_BUDGETrecall 排隊(duì)、p95 劣化乘積不超過連接池上限檢索與召回RECALL_BUDGET_FIXED_*返回量過大、prompt 膨脹從默認(rèn)值出發(fā)小步調(diào)整模型調(diào)用LLM_MAX_CONCURRENT及 per-op 變體限流重試、路徑互相擠占按 provider 限流反推模型調(diào)用CONSOLIDATION_BATCH_SIZE存儲冗余、檢索數(shù)據(jù)量結(jié)合 backlog 指標(biāo)運(yùn)維保障LOG_LEVEL、Grafana 告警I/O 開銷、故障發(fā)現(xiàn)生產(chǎn) warning JSON按部署規(guī)模的選擇建議小規(guī)模單實(shí)例、單 bank保持默認(rèn)池配置與默認(rèn) pgvector重點(diǎn)檢查 recall token 預(yù)算和 LLM 并發(fā)是否符合 provider 限制本地嵌入 本地 reranker 即可架構(gòu)最簡單。中等規(guī)模多 bank、讀多寫少啟用讀寫分離按并發(fā) × 連接預(yù)算 池上限校準(zhǔn) recall 參數(shù)重排序器按延遲預(yù)算在云/本地之間二選一導(dǎo)入 Grafana 面板盯住 p95 與 backlog。大規(guī)模多實(shí)例在中等規(guī)?；A(chǔ)上評估 vchord 等索引擴(kuò)展per-operation 并發(fā)配置保證離線鞏固任務(wù)不擠占在線路徑容量趨勢按月跟蹤。順序上的提醒先有指標(biāo)基線再動(dòng)參數(shù)一次一個(gè)每步用同一指標(biāo)驗(yàn)證。Hindsight 的默認(rèn)配置在多數(shù)場景下已經(jīng)合理真正需要調(diào)的通常只有上面表格里那幾個(gè)。【免費(fèi)下載鏈接】hindsightHindsight: Agent Memory That Learns項(xiàng)目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Hindsight 性能調(diào)優(yōu)指南：從延遲排查到配置優(yōu)化，改善內(nèi)存占用與查詢速度
Hindsight 性能調(diào)優(yōu)指南從延遲排查到配置優(yōu)化改善內(nèi)存占用與查詢速度【免費(fèi)下載鏈接】hindsightHindsight: Agent Memory That Learns項(xiàng)目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight給 AI 代理接上 Hindsight一個(gè)給 Agent 提供持久記憶的內(nèi)存系統(tǒng)之后常見的第一步是跑得通第二步才是要跑得快。典型踩坑場景是這樣的記憶數(shù)據(jù)攢了幾周recall查詢從百毫秒級滑到秒級容器內(nèi)存曲線緩慢爬坡偶爾還出現(xiàn)連接池告警。很多人第一反應(yīng)是加機(jī)器但 Hindsight 的性能瓶頸通常集中在幾個(gè)可配置的點(diǎn)上——數(shù)據(jù)庫連接、向量索引、召回預(yù)算、模型調(diào)用并發(fā)。這篇筆記按先測量、再調(diào)優(yōu)的思路把 Hindsight 性能調(diào)優(yōu)中的內(nèi)存優(yōu)化與查詢速度優(yōu)化拆開講重點(diǎn)落在幾個(gè)高收益配置上。先測量、再調(diào)優(yōu)延遲排查的主線調(diào) Hindsight 之前先回答一個(gè)問題慢在哪一段Hindsight API 內(nèi)置了 OpenTelemetry 指標(biāo)全部暴露在/metrics端點(diǎn)定義見 metrics.py涵蓋五類操作延遲retain/recall/reflect三類操作各一個(gè)直方圖形如hindsight_operation_duration_seconds_bucket{operationrecall}可直接算 p50/p95/p99LLM 調(diào)用延遲與 token 用量按 scope 維度拆分能區(qū)分慢在模型還是慢在檢索進(jìn)程指標(biāo)CPU、內(nèi)存、文件描述符、線程數(shù)數(shù)據(jù)庫連接池池內(nèi)連接數(shù)與等待情況異步操作積壓backlog隊(duì)列深度按租戶、操作類型、bank 拆分排查時(shí)按這張對照表定位現(xiàn)象優(yōu)先懷疑對應(yīng)指標(biāo)recall 整體變慢LLM 延遲正常檢索并發(fā) / 向量索引operation 直方圖 連接池LLM 延遲升高操作延遲同步升高模型并發(fā)上限過低或 provider 限流LLM 延遲直方圖內(nèi)存緩漲、無陡增鞏固consolidation積壓或數(shù)據(jù)膨脹backlog 進(jìn)程內(nèi)存寫入慢、讀正常連接池不足或?qū)懭氪谢B接池等待官方倉庫里帶 Grafana 面板可以直接導(dǎo)入后對照上述指標(biāo)看趨勢monitoring/grafana/。拿到基線之后再動(dòng)配置一次只調(diào)一個(gè)參數(shù)對比同一指標(biāo)的前后數(shù)值。這樣優(yōu)化才不會(huì)變成玄學(xué)。存儲與索引連接池、向量擴(kuò)展、銀行策略為什么先看存儲Hindsight 的核心數(shù)據(jù)都在 PostgreSQL 里向量搜索依賴 Postgres 的向量擴(kuò)展。連接池和索引方式?jīng)Q定了查詢速度的下限。連接池怎么配主池默認(rèn)是min 5 / max 100見 config.py多數(shù)單實(shí)例部署用默認(rèn)值即可。如果你的讀多寫少、或已經(jīng)配了只讀副本讀寫分離是比調(diào)大池子更有效的做法——讀壓力不再擠占寫入連接HINDSIGHT_API_READ_DATABASE_URLpostgres://user:passreplica:5432/hindsight HINDSIGHT_API_READ_DB_POOL_MIN_SIZE5 HINDSIGHT_API_READ_DB_POOL_MAX_SIZE50沒有副本時(shí)優(yōu)先觀察連接池等待指標(biāo)再?zèng)Q定要不要調(diào)大HINDSIGHT_API_DB_POOL_MAX_SIZE盲目調(diào)大只會(huì)把壓力轉(zhuǎn)嫁給數(shù)據(jù)庫。向量索引用哪種擴(kuò)展通過HINDSIGHT_API_VECTOR_EXTENSION選擇默認(rèn)pgvector可選vchord、pgvectorscale、scann校驗(yàn)邏輯在 _vector_index.py。pgvector 生態(tài)最穩(wěn)數(shù)據(jù)量在幾十萬向量以內(nèi)通常夠用規(guī)模更大、或追求更高召回吞吐時(shí)vchord 等 HNSW 類擴(kuò)展的檢索效率通常更好——這類切換建議先在測試庫實(shí)測 p95 延遲再上生產(chǎn)。銀行bank策略bank 是 Hindsight 的隔離單位。單 bank 場景檢索路徑最短、查詢速度快多租戶或多 agent 用多 bank 換取隔離。bank 數(shù)量會(huì)直接影響 schema 級資源bank 越多單查詢的固定開銷越高多 bank 部署時(shí)更值得盯連接池與 bank 統(tǒng)計(jì)緩存相關(guān)指標(biāo)。檢索與召回召回預(yù)算和并發(fā)是最快的查詢速度旋鈕recall 是讀路徑上延遲最敏感的操作相關(guān)默認(rèn)值都在 config.py行為可用 test_recall_config.py 對照驗(yàn)證。召回并發(fā)與連接預(yù)算# 每個(gè) worker 同時(shí)執(zhí)行的 recall 上限默認(rèn) 32 HINDSIGHT_API_RECALL_MAX_CONCURRENT32 # 單次 recall 占用的數(shù)據(jù)庫連接數(shù)默認(rèn) 4 HINDSIGHT_API_RECALL_CONNECTION_BUDGET4為什么這兩個(gè)值要一起看RECALL_MAX_CONCURRENT × RECALL_CONNECTION_BUDGET決定了 recall 對連接池的峰值需求。如果這個(gè)乘積超過池上限r(nóng)ecall 會(huì)排隊(duì)表現(xiàn)是 p95 延遲階梯式變差。調(diào)參方向是保持乘積小于池max_size并留余量而不是單純把并發(fā)拉滿。用 token 預(yù)算控制返回量這是內(nèi)存優(yōu)化里性價(jià)比最高的一檔。內(nèi)部召回如 mental model 刷新返回多少內(nèi)容由 token 預(yù)算決定默認(rèn)fixed函數(shù)按查詢復(fù)雜度給 100/300/1000 token 三檔HINDSIGHT_API_RECALL_BUDGET_FUNCTIONfixed HINDSIGHT_API_RECALL_BUDGET_FIXED_LOW100 HINDSIGHT_API_RECALL_BUDGET_FIXED_MID300 HINDSIGHT_API_RECALL_BUDGET_FIXED_HIGH1000預(yù)算給得過大下游 prompt 膨脹、序列化與傳輸成本上升還會(huì)擠壓 context window給得過小則召回質(zhì)量下降。建議先用默認(rèn)值跑一段時(shí)間按hindsight_operation_duration_seconds_bucket和 token 用量直方圖決定往哪邊調(diào)。HINDSIGHT_API_RECALL_MAX_QUERY_TOKENS默認(rèn) 500則限制查詢語句本身的長度長查詢會(huì)放大檢索開銷對上游傳入的 query 做截?cái)嗤瑯佑行АＤＰ驼{(diào)用LLM 并發(fā)、嵌入、重排序與鞏固記憶系統(tǒng)的慢經(jīng)常不是數(shù)據(jù)庫慢而是 LLM 慢。Hindsight 內(nèi)部有 retain寫入抽取、reflect回答合成、consolidation記憶鞏固三類模型調(diào)用各有獨(dú)立的并發(fā)與超時(shí)配置。LLM 并發(fā)按 provider 限流反推HINDSIGHT_API_LLM_MAX_CONCURRENT10 HINDSIGHT_API_LLM_TIMEOUT120云 providerOpenAI、Anthropic 等上限取決于賬戶限流配高只會(huì)觸發(fā) 429 與重試本地模型Ollama 等通常 1-2 并發(fā)即已打滿。per-operation 變體如RETAIN_LLM_MAX_CONCURRENT、REFLECT_LLM_MAX_CONCURRENT可以單獨(dú)壓制某條路徑避免 consolidate 批任務(wù)把在線 recall 的資源吃光。鞏固consolidation是內(nèi)存優(yōu)化的主戰(zhàn)場它把相似記憶合并、去除冗余長期看直接降低存儲與檢索的數(shù)據(jù)量。HINDSIGHT_API_CONSOLIDATION_BATCH_SIZE控制單輪處理的記憶數(shù)量批次過大單輪耗時(shí)長、過小調(diào)度開銷高默認(rèn)值在多數(shù)規(guī)模下夠用積壓時(shí)再結(jié)合 backlog 指標(biāo)上調(diào)。嵌入與重排序按質(zhì)量-延遲權(quán)衡選擇嵌入模型決定向量檢索質(zhì)量與速度本地小模型如HINDSIGHT_API_EMBEDDINGS_LOCAL_MODEL指定的輕量模型延遲低、幾乎不占外部成本但多語言與長文本表現(xiàn)弱于云嵌入云嵌入則通過HINDSIGHT_API_EMBEDDINGS_MAX_CONCURRENT_REQUESTS控制并發(fā)。重排序器同理云 reranker如 cohere、google質(zhì)量更高但引入一次網(wǎng)絡(luò)往返延遲通常增加數(shù)百毫秒到秒級本地 reranker 資源消耗低、延遲可控。對查詢速度敏感的在線場景重排序器選型往往比任何索引參數(shù)都更影響體感。運(yùn)維保障日志、告警與容量節(jié)奏日志級別生產(chǎn)建議HINDSIGHT_API_LOG_LEVELwarning配 JSON 格式輸出debug 級別的日志 I/O 在高 QPS 下本身就會(huì)吃掉可觀的延遲預(yù)算排查特定問題時(shí)按操作類型開局部日志而不是整機(jī) debug。告警規(guī)則基于操作直方圖設(shè)延遲告警、基于進(jìn)程內(nèi)存設(shè)水位告警、基于 backlog 設(shè)積壓告警。一個(gè)可用的起點(diǎn)- alert: HighRecallLatency expr: histogram_quantile(0.95, rate(hindsight_operation_duration_seconds_bucket{operationrecall}[5m])) 1 for: 5m容量節(jié)奏向量數(shù)據(jù)增長是單調(diào)的建議每月看一次 p95 延遲趨勢與 bank 數(shù)據(jù)量曲線趨勢性上升時(shí)先考慮鞏固參數(shù)和索引擴(kuò)展再考慮橫向擴(kuò)實(shí)例。調(diào)優(yōu)要點(diǎn)匯總維度關(guān)鍵配置解決的問題調(diào)參原則存儲與索引DB_POOL_MAX_SIZE、READ_DATABASE_URL連接等待、讀壓力讀寫分離優(yōu)先于調(diào)大池子存儲與索引VECTOR_EXTENSION向量檢索效率測試庫實(shí)測后切換檢索與召回RECALL_MAX_CONCURRENT、RECALL_CONNECTION_BUDGETrecall 排隊(duì)、p95 劣化乘積不超過連接池上限檢索與召回RECALL_BUDGET_FIXED_*返回量過大、prompt 膨脹從默認(rèn)值出發(fā)小步調(diào)整模型調(diào)用LLM_MAX_CONCURRENT及 per-op 變體限流重試、路徑互相擠占按 provider 限流反推模型調(diào)用CONSOLIDATION_BATCH_SIZE存儲冗余、檢索數(shù)據(jù)量結(jié)合 backlog 指標(biāo)運(yùn)維保障LOG_LEVEL、Grafana 告警I/O 開銷、故障發(fā)現(xiàn)生產(chǎn) warning JSON按部署規(guī)模的選擇建議小規(guī)模單實(shí)例、單 bank保持默認(rèn)池配置與默認(rèn) pgvector重點(diǎn)檢查 recall token 預(yù)算和 LLM 并發(fā)是否符合 provider 限制本地嵌入 本地 reranker 即可架構(gòu)最簡單。中等規(guī)模多 bank、讀多寫少啟用讀寫分離按并發(fā) × 連接預(yù)算 池上限校準(zhǔn) recall 參數(shù)重排序器按延遲預(yù)算在云/本地之間二選一導(dǎo)入 Grafana 面板盯住 p95 與 backlog。大規(guī)模多實(shí)例在中等規(guī)?；A(chǔ)上評估 vchord 等索引擴(kuò)展per-operation 并發(fā)配置保證離線鞏固任務(wù)不擠占在線路徑容量趨勢按月跟蹤。順序上的提醒先有指標(biāo)基線再動(dòng)參數(shù)一次一個(gè)每步用同一指標(biāo)驗(yàn)證。Hindsight 的默認(rèn)配置在多數(shù)場景下已經(jīng)合理真正需要調(diào)的通常只有上面表格里那幾個(gè)。【免費(fèi)下載鏈接】hindsightHindsight: Agent Memory That Learns項(xiàng)目地址: https://gitcode.com/GitHub_Trending/hindsight2/hindsight創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考