LLM，OCR，TTS，STT，Embedding，Reranker 都準備好了，可以建 RAG 知識庫了。--- 不過，不算標準的RAG。

這台的跟前面的都不一樣：它不用顯示卡，不裝任何模型。它自己只做三件事：把文件灌進來、把知識存起來、把問題送出去，再把答案組回來。會這樣做 是因為計算演算的機器壞了，重建一臺就好。但是知識庫儲存了我們所建立的相關資料，壞掉了就沒了。所以單獨建立，方便管理資料庫。

這台不必大。實際上跑起來的規格很普通：8 個虛擬核心、16 GB 記憶體、系統碟 100 GB，沒有顯示卡。唯一要講究的是資料放哪：知識庫那些檔案要放在另一顆碟上，跟系統分開。理由在最後一段會講清楚，先照做。

ssh 連到 hq，切換到 /opt/claude-working，執行 claude code：
告訴 claude code：

在192.168.0.20 建一台Ubuntu虛擬機，IP：192.168.0.32，這台當知識庫的工作站。

一、做三件事：把文件灌進來、把知識存起來、把問題送出去再把答案組回來。
    - 8 個虛擬核心、16 GB 記憶體，系統碟 100 GB。
    - 另外掛一顆資料碟，知識庫的檔案全部放那顆，不要放系統碟。

二、把外面三個端點接好，寫在設定檔裡，不要寫死在程式碼裡：
    - OCR  → 192.168.0.31
    - 算向量、重新排序 → 192.168.0.31
    - 把答案寫成人話的模型 → 192.168.0.30
    - Database 用 SQLite。
    - 採用 Python serach。
    ⚠️ 這三個端點任何一個不通，這台就要明確報錯，不要安靜地跳過。

三、對外綁 rag.iron30.com，到 NPM 加上去並取得憑證。
        要有登入才進得來 —— 裡面是我們自己的文件。
        
規則：
- 做完把這台寫進 machines.md 和 machines/rag.md，對外開了什麼寫進 exposure.md。
- ⚠️ 這台的備份規格跟前面幾台不一樣，等灌完資料再一起設。

建起來之後,拿一份真的文件來試：

第一份灌進去的文件，是跑著整座機房那台實體伺服器，Dell R530 的原廠手冊：182 頁、英文、8.5 MB，整份是掃描的，切完之後是 496 塊。挑它的理由很實際：半夜換一條記憶體、換一顆電源供應器的時候，沒有人想在 182 頁的英文 PDF 裡面用滑鼠捲。這種文件一年用不到三次，但用到的那次都很急。

灌之前要先決定一件事：東西怎麼分類。很自然會用「文件」當單位，一份 PDF 一個項目，但實際查修的時候你手上只有一台壞掉的機器，不會知道答案落在哪一份文件裡。機房裡那台電話總機就是這樣：簡易手冊一份、系統功能碼一份、常用功能又一份，問「怎麼設定轉接」的時候三份都可能有。所以分類要照壞掉的那個東西分，不是照檔案分。

告訴 claude code：

把Dell R530 手冊灌進知識庫。
檔案在 hq 的 /opt/claude-working/dellr530.pdf,先傳到工作站再灌

一、分類的單位是「機器」不是「文件」：
    先建一台機器的項目，再把手冊掛在它底下。
    一台機器可以掛好幾份手冊，查的時候整台一起查。

二、每一頁分兩種走法：
    - 能直接抽出文字的頁就直接抽，而且抽文字要保留原本的版面。
    - 抽不到什麼字的頁，才送去OCR那台。

三、切塊的時候，每一塊都要記住它來自第幾頁，然後才拿去算向量。
    ⛔ 頁碼一定要在這個時候記，事後補不回來。

四、算好的東西存進本機那顆資料碟，一塊一列。
    ⚠️ 每一列都要記得它屬於哪一份文件 ——
    之後查詢一律先用文件把範圍縮小，不要每次都掃整個庫。

五、⚠️ 這是會跑很久、而且中途一定會被打斷的工作：
    做成可以從斷掉的地方接著跑；連線斷掉也要重試，
    不要只重試伺服器回錯誤的那種情況。

六、灌完回報：總共幾頁、其中幾頁走了OCR、切出幾塊。
    ⛔ 然後拿這些數字跟頁數對一次 —— 少了就是中途掉了，不要當成功。

這裡有一件跟大多數教學不一樣的事：整套東西沒有向量資料庫，也沒有任何向量索引。那些數字就直接存在一顆普通的 SQLite 檔案裡，一個欄位一塊。比對的時候也沒有什麼花招：把兩串數字乘一乘加起來，誰大誰排前面，一行程式。目前整個檔案 2.74 GB，裡面有 43 萬塊。它撐得住的原因只有一個：每次查詢都先把範圍縮到「這幾份文件」。問那台伺服器的手冊，實際上只掃 496 塊，不是 43 萬塊。

邊界也要講清楚：如果你要的是「全部知識一起搜」，這個做法就會撞牆，那時候才需要真正的向量索引。換句話說：知識庫不等於一定要架一套向量資料庫。範圍夠小的時候不必，而範圍夠不夠小，是由你怎麼分類決定的。

手冊這種東西，純文字的答案用處有限。真正有用的是「翻到第 47 頁那張接線圖」——人要的是回到原始那一頁，自己看一眼。所以切塊的時候如果沒有把頁碼一起記下來，這套東西的價值會少掉一半。

灌完，弄個網頁來工作。告訴 claude code：

依據所有功能，形成一個  webui：
  - login 保護，
  - 分頁：
     - 檔案上傳，判定是否 OCR 或直接切片入庫
     - 知識庫查詢：問答頁
     - 管理：用戶  crud，theme 配置
     - 檔案庫：檔案，書籍管理 
問答頁：選一台機器，問問題，答案出來，而且看得出答案是從哪裡來的。
每個分頁都實際操作一次,有錯就找原因修到正確為止

一、查的順序：
   - 先把範圍縮到選定那台機器底下的所有文件。
   - 比對向量抓一批候選，再送去重新排序那個服務重排，只留最前面幾筆。
   - ⚠️ 這兩層的分數不是同一把尺，不要互相比較，也不要混在一起訂門檻。

二、⛔ 答案有三條規則，一條都不能少：
   1. 每一句話後面都要標出處：哪一份文件、第幾頁。標不出來的句子就不要寫。
   2. 查不到就說查不到，並且說明查到最接近的是什麼。
   ⛔ 寧可說不知道，也不要生一份看起來很合理的操作步驟 ——
   使用者會拿著它去動真的機器。
   3. 分數低的時候不要硬答，換一個比較會遵守指令的模型再答一次。

三、答案裡的頁碼要能點，點了直接看到那一頁的原圖。

四、驗收拿三種問題各問一次：手冊裡明明有的、手冊裡沒有的，
再加一個荒謬的問題。三種都要回得合理，尤其是後面兩種。

Dell R530 手冊查詢：

灌完之後第一個意外是：手冊是英文的，而問題是用中文問的，它照樣查得到。問「記憶體插槽要怎麼安裝，有順序規則嗎」，3.9 秒回來，答案是繁體中文，而且每一條後面都掛著頁碼，指到第 80 頁。更好的是它主動說了一句：插槽數量在第 8 頁有寫，但安裝順序的規則，手冊裡沒有提供。會這樣是因為比對的是意思不是字面，所以文件不必先翻譯。

接著撞到一件跟設計時的假設相反的事。這套東西本來有一道防線：相似度低於門檻就直接回「查不到」，連模型都不呼叫。但真的拿三題去問，分數分別是 0.58、0.52、0.47，而最後那題問的是「這台伺服器可以煮咖啡嗎」。一個荒謬的問題也拿得到 0.47，是因為比對永遠找得到「最像」的東西 —— 它找到了溫度規格那幾頁。所以那道門檻幾乎不會被觸發，寫在程式碼註解裡的那句「初值是保守猜測」是誠實的。

真正擋住幻覺的是另外兩件事：規則裡明寫「寧可說查不到，也不要給不確定的步驟」，以及每一句話都要掛頁碼 —— 掛不上頁碼的句子，它自己就寫不出來。

分數低不代表要放棄，但代表要換人回答。分數落在中間那一段的時候，這套東西會把問題升級給雲端的模型，理由是它比較聽得懂「查不到就說查不到」這種指令，比較不會硬答。實測那一題確實換了模型，答案一樣是查不到、一樣附上最接近的內容。代價是時間：本地那兩題 2.7 秒，升級那題 7.2 秒。便宜的模型負責大部分，不確定的時候才付貴的那筆。

最讓人難受的失敗不在模型身上：灌一本書灌到一半，整個中止。原因是重試只涵蓋伺服器回錯誤的情況，連線本身斷掉的時候第一次就放棄。而例行維護重啟一個容器只斷三秒，三秒就足夠殺掉一本正在灌的書。更糟的是它不會吵：你以為灌完了，實際上少了後面幾十頁，而少掉的那幾頁在你查到那裡之前不會有人告訴你。長時間的匯入要當成「一定會被打斷」來設計，而且做完要對數量下一次斷言。

回頭看這台機器：普通的核心數、普通的記憶體、沒有顯示卡，上面跑的東西全部可以重裝，一下子就好。真正不能重來的只有一樣：那顆 2.74 GB 的檔案。灌它花掉的是好幾天的時間，而且原始的掃描檔散在各處，真要重來一次不只是慢而已，是不一定找得回來同一批文件。所以這台機器的備份規格不是照機器訂的，是照那顆檔案硬碟訂的。

到這裡，我們可以：上傳文件，解讀資料，形成知識庫，詢問知識庫。

明天，來依據文件內容，生成影片。