Life-OS ／記憶系統成效報告

一套會自己長大的第二大腦，
到底找不找得到東西

這份不是講工程怎麼修，是講這套記憶到底有沒有用。
先把記憶套件拆開給你看有幾層、每一層在什麼時候動；再講關鍵字跟語意這兩條腿各自怎麼走；然後直接拿五個生活問題現場查給你看，撈到什麼、撈不到什麼都照實寫；最後一章是我們自己做的那把尺，還有拿它量出來的分數。

2026-08-05 · Asia/Taipei · 所有數字都是當天實際跑出來的

結論先講三句話

一、這套記憶不是一個資料夾，是十四道會自己動的工序。 對話發生的當下只是第一步，之後每十分鐘切一次摘要、每兩分鐘同步一次、每天凌晨兩點到六點還有一整串夜間鏈在把當天的東西沉澱成長期的東西。

二、它靠兩條腿走路，而其中一條長期是瘸的。 一條腿比字面、一條腿比意思。我們今天量出來：現在正式庫的中文斷詞設定讓關鍵字那條腿在七十三道自製題目上七十三題全部空手——等於一直以來都是單腳跳。換掉斷詞之後，前十名命中率從 69.9% 跳到 93.2%。

三、尺是自己做的，所以分數是可以信的。 外面現成的中文題庫，出題的人是看著答案寫問題，字面重疊高，誰去跑都好看。我們改成拿自己的筆記出題、而且交給另一個模型換句話說重寫，字面重疊當場砍掉一半以上，分數也跟著掉下來——掉下來的那個才是真的。

19,532 篇

目前被索引的文件

321,071 段

切出來的向量段落

2,769 份

逐日對話日誌

2,713 條

wiki 人物／作品／概念條目

第一章先講清楚：機器的「記得」跟你的「記得」不是同一件事

這一章給對向量、對檢索完全不熟的人。已經懂的可以直接跳到第二章。

你請朋友想一下「咖哩」，他腦子裡跑出來的東西大概是這樣的：上禮拜煮的那鍋、巷口那家店、還有那部叫《昨夜的咖哩，明日的麵包》的日劇。這三件事字面上只共用「咖哩」兩個字，可是它們在他腦子裡是連在一起的。

機器要做到這件事，只有兩種辦法，而且兩種都不完美。

辦法一：比對字面（關鍵字檢索）

把每一篇筆記拆成一小段一小段的字，建一張倒過來的索引表—— 「咖哩」這兩個字出現在第 12、第 88、第 431 篇。你查「咖哩」，它就把這三篇端出來。

快、準、便宜、而且解釋得清楚：它為什麼給你這篇，因為這篇裡面真的有這兩個字。

它的死穴也很明顯：你講的詞跟筆記裡寫的詞不一樣，它就當作沒有。 你問「把說出來的話變成文字的那個工具」，筆記裡寫的是「語音轉錄」「Whisper」—— 一個字都對不上，於是零筆。

辦法二：比對意思（向量檢索）

把每一段文字丟給一個嵌入模型，它會吐出一串數字——一千零二十四個數字，就是這段文字在「意思空間」裡的座標。意思接近的兩段話，座標就靠得近。

於是「把說出來的話變成文字」跟「語音轉錄」，字面上零重疊，座標上卻是鄰居。 這條腿聽得懂換句話說。

它的死穴同樣明顯：它只懂「像不像」，不懂「是不是」。 你要它找一個精確的型號、一組帳號、一個日期，它會給你一堆「感覺很接近」但其實不對的東西。而且它算起來慢、貴，還吃記憶體。

所以答案不是二選一，是兩條腿一起走。關鍵字那條腿負責「你講的就是這個」，語意那條腿負責「你講的大概是這個意思」，兩張名單各自排序完，再用一個叫 RRF（倒數排名融合）的方法併成一張。在兩張名單上都排前面的，併完就會被推到最上面。

還有一件不那麼直覺的事：文件要先被切碎

一篇兩千字的筆記整篇算一個座標，是沒有用的——那個座標會是全篇的平均值，什麼都像一點、什麼都不夠像。所以要先切成段，一段一段各自算座標。這就是為什麼一萬九千篇文件會長出三十二萬個向量段落：平均一篇被切成十六段。

第二章記憶套件由哪些東西組成

很多人以為「AI 的記憶」就是一個資料庫。實際上這套東西有五層存放處、十四道工序，各層存的東西性質完全不同。

五層存放處：從最生的到最熟的

量測時間 2026-08-05。第①層不列數字，因為它是隨對話長的原始檔，不是可數的「篇」。
層	放什麼	目前的量	誰在寫
① 逐字層	對話的原始逐字紀錄，一個字都不改	每條線各自累積	對話當下自動落檔
② 切片層	每十分鐘一份摘要，帶情緒標注與焦點轉場標記	2,769 份	排程，每 10 分鐘
③ 條目層	人物／作品／概念的 wiki 條目、外部資料擷取原料	2,713 ＋ 1,830	夜間鏈＋對話中手動建
④ 洞見層	使用者說過的話裡值得留的原句、以及系統自己的夢境日誌	46 ＋ 130	對話中偵測到就落卡
⑤ 規則層	記憶卡：這個人是誰、他怎麼要求做事、正在進行什麼	218 張	對話中沉澱

第⑤層的組成其實透露了一件事。218 張記憶卡裡，「使用者給的做事指導」佔 58%、「進行中的工作脈絡」19%、「外部資源指標」19%，而「這個使用者本人是什麼樣的人」只佔 3%。這不是設計成這樣，是自然長成這樣——每天在動的是工作，不是自我描述。這種偏斜要靠人回頭看才會發現，機器自己不會抱怨。

十四道工序：每一道在什麼時候動

底下每一條都是真的在跑的排程，時間是台北時間。

當下逐字落檔　訊息進來、回覆出去，整段對話寫進當線的原始紀錄。這一步不做任何加工。
每 2 分鐘記憶同步　把散在各處的記憶卡與索引狀態對齊，避免多條線同時寫造成分家。
每 10 分鐘切片＋摘要＋情緒標注　讀原始紀錄的新增段落，交給一顆小模型壓成摘要，同時標出這段的情緒（五種情緒 × 三種強度）與焦點轉場點，寫成一份帶時間戳的切片。這是整套系統裡最關鍵的一道——沒有它，長對話會整段沉底再也撈不出來。
每 10 分鐘近況滾動　同一道工序順手更新每條線的「近況」檔，只留最近的條目，讓下一輪對話一開場就知道剛剛在幹嘛。
每 15 分鐘任務板投影　把任務狀態同步到使用者看得到的清單。
02:00偏好沉澱　把當天標記過的品味與立場條目，沉澱進長期的使用者檔案。
02:30wiki 夜間鏈　新擷取的原料自動長成條目、補欄位、接上關聯。
03:00夢境生成　系統自己回顧當天，寫一篇帶敘事的日誌。這不是裝飾——它是把零碎事件重新組織成有因果的故事，隔天可以被引用回來。
03:05作品錄同步　把夢境裡引用過的作品抽出來建帳，供之後對話取用，並防止同一部作品被反覆引用。
03:40條目補完掃描　掃出資訊不完整的條目，排隊補。
03:45對話封存　當天的對話歸檔成可檢索的日檔。
04:20召回索引重建　重建中日韓文專用的全文索引，供對話開場時的自動回想使用。
04:30使用者檔案沉澱　當天的新資訊寫進長期的使用者流水帳。
05:00 ／ 06:10記憶稽核與索引修剪　檢查記憶卡有沒有互相矛盾、清掉已經沒有對應內容的索引殘留。

還有一道不在排程上、但每一輪對話都會發生的： 使用者送出訊息的那一瞬間，系統會先拿這句話去撈一次過去的相關紀錄，把撈到的東西當成背景脈絡塞在前面，然後才開始想怎麼回。也就是說——回答之前，它已經先讀過一次自己的過去了。

第三章兩條腿怎麼各走各的，又怎麼併在一起

兩條腿的實際流程。融合用的是 RRF——不看兩邊的分數絕對值（那本來就不同單位），只看各自的名次。這是它比「把分數加權相加」穩的地方。

還有一個小動作：先讓模型自己編一個答案

深度查詢的時候，系統會先請模型憑空寫一段「如果這題有答案，答案大概長這樣」的假文字，然後拿那段假文字去比對意思，而不是拿原本的問句。

原因是：問句跟答案在文字形態上本來就不像。「上次那個掃地機叫不醒是怎麼回事」是一個問句，而筆記裡寫的是一段陳述。先把問句改寫成陳述句的樣子再去比，命中率會明顯上升。

兩條腿的分工，量出來長這樣

底下是同一批七十三道題目、同一支計分程式跑出來的。 R@10 的意思是「正確答案有沒有出現在前十筆裡」。

第一列不是畫錯——現在正式庫的中文斷詞設定，讓關鍵字那條腿在這批題目上七十三題全部撈不到東西。所以第三列那個 69.9%，實際上是向量腿一條腿撐出來的。

為什麼關鍵字腿會全滅？ 因為中文句子沒有空白，而現在的設定是把字面切成三個字一組去比對，再要求查詢裡的每一組都要出現。真人問句裡的「那篇」「哪個」「怎麼」這種口語填充詞，筆記本文根本不會這樣寫——一個填充詞就把整句判死。 改成兩個字一組、而且改成「命中任何一組就算」，同一批題目從全滅變成 84.9%。

第四章五個生活例子，現場查給你看

底下每一題都是 2026-08-05 當天真的丟進系統跑出來的，不是示意。撈到什麼、撈不到什麼都照實寫——包含兩題失敗的。

我說到咖哩，你想到什麼

命中關鍵字腿跨領域聯想

這是最能看出「第二大腦」跟「搜尋框」差在哪的一題。它撈回來的東西橫跨三個完全不同的領域：

兩份存過的食譜：無水咖哩、日式牛絞肉咖哩。都是從社群平台擷取後長成的條目，連原始出處的貼文也一併留著。wiki／entities ＋ raw
一家去過的餐廳：武田咖哩（Toriaezu Curry），資料豐富化的工作規格還在。餐廳資料
一位日本編劇：木皿泉。因為他寫過《昨夜的咖哩，明日的麵包》（ゆうべのカレーあしたのパン）。 wiki／entities
一份備餐輪替計畫：咖哩排在 Week A 的主菜位。長期照管線的工作檔

這說明什麼：系統沒有一張叫「咖哩」的表。這四筆分別住在條目庫、擷取原料、餐廳資料、工作檔四個地方，是被同一次查詢拉在一起的。那位編劇之所以會出現，是因為作品名裡有咖哩—— 這正是一個人腦會做、而一般搜尋不會做的跳躍。

上次掃地機叫不醒是怎麼回事

命中關鍵字腿踩過的坑

撈回來的不只是「怎麼操作」，還包括當初踩過的坑跟後來的修正：

技能文件裡明寫著：叫醒指令只對淺睡有效，閒置四十分鐘以上的深睡，腳本叫不醒，唯一可靠解是開一次官方 App 或按機身鍵。skills／narwal
還附了一條反向警告：機器「有未完成任務又沒在跑」的時候，別為了查狀態去喚醒它—— 會讓它接著把被打斷的任務跑完。同上，2026-07-20 現場驗證
當初把這件事做對的施工紀錄，包含審查時被打回來的六個問題與各自的修法。 worktickets
連「這條測試用例本身出過錯」都記著——第一版的測試字串剛好在原文裡自成一個詞，所以測試會亮綠燈但其實什麼都沒測到。tests

這說明什麼：對工程類的問題，這套記憶真正值錢的不是「答案」，是「上次為什麼會錯」。第四筆那種「量具自己是壞的」的紀錄，是最容易被忘記、也最容易重犯的一類。

有哪些電影是看完會不舒服、但很好的

命中語意腿品味

這題沒有任何一個精確的關鍵字可以查——「不舒服」不是分類標籤。走的是語意腿：

一份從社群平台存下來的片單：主題就叫「有人想不舒服一下」。raw ＋ wiki／entities
片單裡的個別作品條目，例如《我唾棄你的墳墓》。wiki／entities
電影討論群的脈絡檔——這個題目在哪個群、跟誰聊過。群組脈絡

這說明什麼：「不舒服的電影」這個概念，在筆記裡從來沒有被定義成一個欄位。能撈到，是因為那份片單的標題與內文在意思空間裡跟這個問句靠得近。 這是關鍵字腿做不到的事。

把說出來的話變成文字的那個工具叫什麼

兩條腿都沒撈到誠實記錄

這題兩條腿都失敗。關鍵字腿端回來幾封完全無關的信件，語意腿端回來的也是一樣的東西，分數低到 12–25%。而正確答案其實就在庫裡——語音轉錄的技能文件、模型選型的紀錄、實際跑過的批次，全都有。

這說明什麼：這正是這份報告最後兩章要處理的那個問題。關鍵字腿失敗，是因為斷詞設定讓它在中文口語問句上等於沒作用（第三章那個 0.0%）；語意腿失敗，是因為現在的索引裡有三分之二是無主的殘留向量—— 真正該被撈出來的段落，被一堆早就不存在的舊內容擠掉了。兩件事都在修，一件已經量出修法有效，一件正在跑。

五月的時候我談最多的是什麼

語意腿答不了切片層答得了結構問題

先講失敗的那半：把這句話直接丟給語意檢索，它端回來的是七月和八月的東西。 原因很單純——意思空間裡沒有「五月」這個維度。「五月」跟「七月」在語意上幾乎一樣近，向量分不出來。時間範圍不是語意問題，是結構問題。

但這題其實答得出來，只是要走第二章的第②層。每十分鐘一份的切片，除了摘要之外還留下了「焦點轉場」標記——每次話題實際換軌，就記一行。 整個五月留下 276 個焦點轉場，把它們歸類之後：

歸類是用關鍵詞比對做的，所以有將近一半落在「其他」——這個數字照登，不是把它藏起來湊出一張漂亮的圓餅圖。它代表五月的話題很分散，長尾比主幹還長。
五月的話題	場景數	佔比
擷取管線與社群內容存檔	40	14.5%
技能開發與紅隊審驗	27	9.8%
影音字幕與翻譯配音	20	7.2%
通訊系統維運	15	5.4%
筆記庫與條目整理	14	5.1%
人際關係時間線整理	12	4.3%
其他（未落入以上任何一類）	131	47.5%

這說明什麼：兩條腿不是萬能的，而且知道哪一類問題該繞過它們，比把它們調到更準更重要。「五月談最多什麼」「上禮拜三下午在幹嘛」這種帶時間範圍的問題，正確做法是走有時間戳的切片層，不是去問向量。一套記憶系統的成熟度，有一半體現在它知不知道自己什麼時候不該用向量。

第五章尺是自己做的

這一章是整份報告裡最不好看、但最值錢的部分。因為它講的是：我們怎麼確保自己不是在自己給自己打分數。

第一把尺：外面現成的

先用了一份公開的繁體中文閱讀理解資料集當題庫——一千段語料、三千四百九十三道題，每題都有標準答案該落在哪一段。這是第一次讓「我們這套記憶找不找得到東西」有了一個可重跑的數字。

結果非常好看。混合腿的前五名命中率直接撞到 100% 的天花板。

好看到讓人起疑。

為什麼那個數字不能信

問題出在出題方式：那份資料集的問句，是出題者看著答案段落寫出來的。 所以問句跟答案之間有大量逐字重疊——而比對字面的引擎在這種題目上天生佔便宜。

真人不是這樣問問題的。真人會說「上次那個…是怎麼回事」，而筆記裡寫的是完全不同的措辭。

第二把尺：自己出題，而且不讓自己出

做法是這樣：

草堆拿自己的知識筆記 3,185 篇，攤平複製成一份用完即丟的副本。個人日誌、洞見、夢境一律排除——那些不外送。
出題從裡面抽 80 段，交給另一個廠商的模型（Codex）「換句話說」重新出題。刻意不讓自己出題給自己考。
剔除出完之後人工剔掉 7 題「段落太空泛、硬出會汙染分數」的，剩 73 題。
驗尺量問句與答案的字面重疊，證明這批題目真的不像抄的。

兩個口徑都指向同一件事：字面比對在這批題目上拿不到便宜。第一版報告寫的是「字面優勢被拿掉了」，審查判定這句超出證據——低一半以上不等於歸零，已改。這種修正照原樣留在紀錄裡，不默默改掉。

換上這把尺之後，所有分數都下修。前五名 100% 那個天花板不見了，混合腿的前十名掉到 69.9%。
這不是壞消息。是先前那個分數本來就偏高，現在才看得到真的。

八種組態，同一支計分程式重算

73 題，note-level 檢索。最後三格彼此的差距經過配對顯著性檢定，**多數落在雜訊裡**——所以這張表能證明「該換掉現在的設定」，不能證明「該換成哪一格」。要定案得把題數加大。這句話是被審查打回來之後補的；第一版拿 86.3% 對 83.6% 那 2.7 分當推薦理由，那是拿雜訊當證據，已收回。
組態	R@1	R@5	R@10	完全空手
關鍵字 · 三字一組＋全部要命中（現在正式庫）	0.0%	0.0%	0.0%	73 / 73
關鍵字 · 三字一組＋命中任一	5.5%	19.2%	24.7%	47 / 73
關鍵字 · 兩字一組＋全部要命中	47.9%	63.0%	67.1%	10 / 73
關鍵字 · 兩字一組＋命中任一	58.9%	80.8%	84.9%	0 / 73
向量（單獨跑）	35.6%	53.4%	63.0%	0 / 73
兩腿併 · 三字一組（現在正式庫）	38.4%	67.1%	69.9%	0 / 73
兩腿併 · 兩字一組＋全部要命中	47.9%	83.6%	89.0%	0 / 73
兩腿併 · 兩字一組＋命中任一	43.8%	86.3%	93.2%	0 / 73

這份評測自己的三個限制，一併寫出來：
① 題目出自單一段落，但計分是以「整篇筆記」為單位——同一篇的其他段落也提供了額外線索，所以這是篇層級的成績，不是段落層級的。
② 抽樣偏向長篇散文型筆記（中位字數 2,584，全庫中位 1,283），成績不外推到短筆記。
③ 草堆與題目來自同一批筆記，這本身是一種同源性，只是比「自己出題自己考」輕一級。
這三條是外部審查打出來的，全部照收。一份不寫自己射程的評測報告，不值得信。

第六章為什麼要換向量、怎麼換、跑分結果

第一步：先把尺加大到一千題

要比兩顆嵌入模型的優劣，七十三題不夠——差距小的時候，題數太少會被雜訊蓋過。所以拿外部資料集跑了一千題，兩顆模型跑同一批、同一支計分程式：

兩顆模型在「排第一名」這件事上幾乎一樣，差距全部集中在第二名之後的排序深度。中間的 R@3 差 +5.6、R@5 差 +7.0，也都是極顯著。

這裡有一個判斷上的岔路，值得記下來。
原本訂的換模門檻寫的是「R@1 要多五分才換」。照字面判，答案是不換。
但那道門檻只看第一名，而新模型贏的地方全部在第二名之後—— 也就是「答案有沒有進到前十筆」這件事上多贏了九分。
而對一個會把前十筆全部讀進去再回答的系統來說，那才是真正影響體感的指標。 門檻改成看 R@10，換。

換之前先問一句：這顆模型會不會把我的東西送出去

這是換模型前唯一真正該擔心的事。查了三層，三層要能互相對得起來：

層一權重是本機檔案　跑它的是本地的推論函式庫，行程內直接算，沒有起伺服器、沒有 API 金鑰。
層二讀原始碼　整條路徑上唯一會連外的，是手動下載模型那一步；那一步送出去的只有網址，沒有任何被嵌入的內容。
層三斷網實跑　用作業系統的沙盒起一個完全禁止網路的環境，在裡面跑嵌入——兩份文件兩秒完成、正常結束。而且量具先校準過：同一條連線測試在沙盒裡連網址都解析不出來、沙盒外正常，確認沙盒真的有生效。

為什麼第三層才算數：前兩層都是推論——「我讀了程式碼，它應該不會連外」。第三層是事實——「我把網路拔掉，它照樣跑完」。這兩者的差別，就是這整套工作方法的核心。

換的過程：開跑三次，前兩次都是壞的

第一次：印了綠燈，其實 96% 失敗

跑完印「完成」、退出碼 0，看起來很漂亮。實際上十三萬段裡只有五千段成功。看不到失敗原因，因為那個工具的三個錯誤處理區塊是空的——只把錯誤計數加一，連印都不印。

當時拿獨立探針去重現，得到一個「顯示記憶體被吃光」的相似症狀，就把它當成了成因。

第二次：修了那個成因，失敗率一模一樣

顯示記憶體問題修掉了、運算單元全建成、還剩六 GB，失敗率還是 96%。

同一個症狀在完全不同的記憶體狀況下重現，代表那不是成因。這次先把錯誤輸出補上再跑，一輪就拿到直接證據：工作階段被中止了。

真正的原因

順著呼叫堆疊找到源頭：這個工具的嵌入呼叫有三十分鐘硬上限，時間到就把整個工作階段中止，之後每一次嵌入都在毫秒內失敗，被空的錯誤處理接住，最後照樣印綠燈。

兩次收工時間是 30 分 6 秒與 30 分 7 秒。那個巧合就是答案。

也就是說——全庫三十萬段想用一次呼叫嵌完，在這個版本上從來就不可能，跟換不換模型、記憶體夠不夠都沒有關係。

第三次：兩層保險

把上限關掉（讓行程自己印一行參數自證，不靠推論），外加一個外層迴圈——每輪跑完比對筆數，有長就再跑一輪，沒長才停。 停止條件看筆數不看退出碼，因為退出碼當天已經騙過我們兩次。

這一段真正的教訓有兩條。
一、收工旗標只證明腳本跑完，不證明事情做成——它就在 96% 失敗的情況下印了綠燈。
二、量具要比修法先做。第一次沒有錯誤輸出，只能拿探針重現一個「看起來像」的失敗，然後把它當成現場的成因，白修一輪。探針重現得出相似症狀，不等於現場就是那個原因。

過程中挖到的第三件事：驗收標準本身是錯的

驗收條件原本寫「重嵌的副本要追到三十萬段」。量現役索引的成長速度時撞到一件怪事：它一天長二十幾萬筆向量，一個一萬九千篇的庫不可能真的每天長那麼多新內容。

拆開來看——

這也回頭解釋了第四章例四為什麼會失敗：真正該被撈出來的段落，被三分之二的舊殘留擠在後面。驗收條件已改成用「乾淨副本自己列舉出來的總段數」當目標，不依賴現役索引任何數字。

現在跑到哪

75,200 ／ 134,159 段

重嵌進度 56%

13,235 ／ 18,470 篇

文件完成度 72%

1024 維

已確認是新模型嵌出來的

0 筆

累計錯誤

現役索引全程沒有被碰過，這段期間記憶搜尋照常運作。維度是唯一能信的憑據——那個工具畫面上印的模型名稱是寫死的假值，換了模型它照樣印舊的名字。

還沒做完的事，照實列

換過去之後要拿同一把一千題的尺再跑一次，前十名命中率掉超過兩分就回滾。
會查這個索引的呼叫點有十個，每一個都要單獨驗過用的是新模型那條路。 其中三個會把錯誤吞掉、安靜降級成只用關鍵字腿——所以「漏了會當場爆掉」這個安全網不成立，已經撤回。
斷詞設定的更換還沒上線。第三章那個 93.2% 是實驗索引上量到的，正式庫還沒換。
回滾路徑要真的跑一次，不是紙上寫的。

收尾一套記憶系統值不值得信，看的是它敢不敢寫下自己的失敗

這份報告裡有兩個例子是失敗的、一整章在講開跑三次死了兩次、一張分數表下面寫著「這張表不能證明該換成哪一格」、還有兩處是自己推翻自己、一處是被外部審查打回來之後改的。

那些都刻意留著。因為一套會自己長大的記憶系統，最危險的失效模式不是「找不到」—— 找不到你當場就發現了。最危險的是它給了你一個看起來很合理的答案，而你沒有辦法知道那是不是真的。

唯一的解法是：每一個數字都要能重跑，每一個結論都要標明射程，每一次改口都留在原地不擦掉。

這就是這套東西目前的樣子。