知識放在索引裡，不是放在權重裡

「可以幫我們訓練一個自己的模型嗎？」

問這句話的人，十次有九次真正想解決的是下一句：「它要知道我們公司的事，而且不要亂講。」

這兩句聽起來是同一件事，其實不是。訓練決定模型怎麼講話——語氣、格式、它願不願意照你的規矩輸出。它不太決定模型知道什麼，尤其是那些下週就會變的事：價格、條款、還有幾個名額。把會變的事塞進權重，等於把它寫進一個要重新訓練才能改的地方。所以我們的預設是反過來的：能力放在模型裡，事實放在索引裡。

事實會過期，權重不會自己更新

上一篇講的是我們站上那個助理怎麼運作：站上的頁面切成三十五段，逐段對問題計分，只送分數最高的幾段進模型，最後把引用對回真正送出去的來源。

那篇沒講的是，這個安排讓「改一件事實」變成什麼樣的動作。

隱私政策改了一句話，下一次 build 那一段就換了，助理下一次回答就是新的。沒有訓練、沒有評估、沒有回歸測試，因為根本沒有東西被學進去。反過來，如果那句話是靠微調記住的，改它的成本不是編輯一行文字，而是準備資料、跑一次訓練、再驗證它沒有順便忘掉別的事。

這是同一個問題的兩種擺法，而擺法決定了誰能改它：索引可以由寫文案的人改，權重不行。

索引不是資料庫，是一個決定

「做個 RAG」聽起來像是接一個東西上去。實際上要做的決定只有兩個，而且兩個都跟資料庫無關。

第一個是怎麼切。 我們按頁面本來的結構切——一個產品一段、一則常見問題一段、隱私政策每一節一段。切得太大，一段裡有五件事，模型會挑錯；切得太小，一句話離開上下文之後誰也看不懂。這條線沒有通則，它取決於你的內容本來長什麼樣子。

第二個是怎麼決定送哪幾段。 這一步是算出來的，不是模型挑的：每一段都對問題打一次分，分數最高的那幾段才往下走。怎麼算是我們自己的事，但「它是算出來的」這件事決定了後面所有的東西——同一個問題永遠選同一批段落，選錯了回頭看得出來是哪一段贏了。

這兩個決定加起來，就決定了模型看得到什麼。模型再強，也答不出它沒看到的東西——這是整件事裡最容易被忽略、但影響最大的一格。花力氣調提示詞而不動切法和計分，通常是在調錯的東西。

模型是這條路上可以抽換的一格

自建模型的處境，把上面那件事放大了。

一個你自己跑的模型，不知道你公司的事，而且明天也不會知道。這不是它不夠強，是那些事從來就不在它的訓練資料裡。你可以微調，但你微調的是形式；價格改了，你還是得再訓練一次。索引則是每次 build 都重建一次的東西。

還有一件只有自建才會遇到的事：提示長度是你自己的帳單。用外部 API 的時候，多送幾段是多付一點錢；自己跑的時候，多送幾段是佔用你自己的顯示卡、拉長你自己的排隊。這讓「只送最相關的幾段」從省錢的優化，變成能不能跑得動的問題。

這樣做的代價

索引錯了，模型救不回來。 送錯段落，模型只會很有自信地根據錯的段落回答。這把責任從「模型會不會亂講」搬到「你的資料對不對、切得好不好」——搬到一個你能修的地方，但它還是得有人修。

切法決定上限。 我們按頁面結構切，是因為這個站的文案本來就是結構化的。換成一堆 PDF 或幾年份的工單，這個切法會直接失效，那是另一個工程。

找的那一格有天花板。 問法跟頁面上的用字對不上的時候，就檢索不到。跨過這條線要換一種找法，而那會帶來一批新的東西要管：多一個模型的版本、多一份要存的東西、以及什麼時候該重算。

還有一個我們沒有數字的角落，就是上面那個 Aside 講的：自建模型上這套工序表現如何，我們還沒量。

接下來

近的一步是把部落格內文放進索引——包括這一篇。文章是長文，不能整篇塞進提示，所以那一步會逼著「索引」那一格換一種找法。換的是那一格，它旁邊那三格不會動。

遠一點的一步是把同一條路接到一個自己跑的模型上，然後量。真的量到了再寫，這篇會補上。

2026-09-02：那一步做完了。 同一條路接上本機的四個開放權重模型，檢索的命中率、送出段數與答不出來的召回四個模型完全相同，差別全在它把答案寫成什麼樣。數字在〈換模型不會改變它有沒有找到對的那份文件〉裡。