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

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

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

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

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

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

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

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

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

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

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

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

第二個是怎麼決定送哪幾段。 我們的檢索是四十四行算術：中文按相鄰兩字比對，每個詞用「它出現在幾段裡」加權，再對長度做輕微懲罰。

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

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

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

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

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

這樣做的代價

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

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

詞面比對有天花板。 問法跟頁面上的用字沒有共同的字，就檢索不到。跨過這條線就要 embedding，而 embedding 會帶來一批新的東西要管：模型版本、向量的儲存、重算的時機。

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

接下來

近的一步是把部落格內文放進索引——包括這一篇。文章是長文，不能整篇塞進提示，詞面比對在長文上也會開始漏，所以那一步會逼出 embedding。到時候「索引」那一格的算法會換掉，而它旁邊那三格不會動。

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

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