知識放進索引，模型才能留在你的機器裡

一間做精密零件的公司來問：二十年的維修手冊、報價單和客訴紀錄，能不能做成一個「問了就會答」的東西。第二句話跟著來：這些檔案不能放到外面的服務上。

這兩句話，做 AI 助理的人聽過很多次。它們聽起來是一個需求的兩半，實際上是兩個會互相打架的要求——只要你把「知道公司的事」理解成「模型要把公司的事背下來」。因為背得多的模型都很大，而大的模型都在別人的機房裡。

這篇要講的是，這個衝突是假的。它來自一個可以放下的假設：知識必須住在模型的權重裡。把知識放進一個索引、讓模型只負責讀選出來的那幾段，「知道公司的事」和「東西不出門」就變成同一個架構的兩個結果，而不是兩個要用預算去調和的目標。這個做法叫檢索增強生成（retrieval-augmented generation，下面就叫 RAG）。下面每一個關於它的主張都有出處；關於我們自己產品的部分，會講清楚哪些量過、哪些還沒有。

模型背不住長尾的事，也背不住上週改的事

先講為什麼「讓模型背」不是一個好主意，即使模型很大。

Kandpal 等人在 2023 年量了一件很直接的事：一個模型能不能答對某個事實，跟它在預訓練資料裡看過多少份跟那個事實相關的文件，有很強的關係。相關文件少的「長尾」事實，模型答得明顯差；作者的估計是，光靠放大模型來補這個缺口，需要的規模遠超過現在的模型，而加上檢索能明顯降低模型對「預訓練時看過相關文件」的依賴^[1]。

你公司的維修手冊，在網路上出現的次數是零。它是長尾裡的長尾。

Mallen 等人從另一個方向看到同一件事。他們建了一組問熱門與冷門實體的問題，發現模型對熱門實體答得好、對冷門實體答得差；檢索對冷門實體幫助最大，對熱門實體反而可能幫倒忙，所以他們提出的做法是只在需要的時候才檢索^[2]。

第三件事是時間。Vu 等人在 FreshQA 上發現，大多數模型在「答案會隨時間改變」的問題上表現差，而把搜尋結果接進提示之後表現大幅改善^[3]。價格、庫存、誰負責哪條線——公司裡最常被問的，剛好都是會變的事。

三篇論文，三個方向，指向同一個結論：權重擅長記形式，不擅長記冷門、會變的事實。而公司內部的知識，幾乎全是冷門、會變的事實。

把「找」和「答」分開，這就是 RAG

RAG 這個名字來自 Lewis 等人 2020 年的論文。他們把一個生成模型接上一個可以檢索的文件庫：回答之前先從庫裡找出相關的段落，再讓模型根據那些段落寫答案。模型的權重是「參數記憶」，文件庫是「非參數記憶」；後者可以直接打開來看，也可以整個換掉——他們示範了把 2016 年的維基百科索引換成 2018 年的，模型的世界知識就跟著更新，沒有重新訓練^[4]。

「找」這一步本身也是研究題目。Karpukhin 等人用兩個編碼器把問題和段落各自變成向量、比距離，在開放領域問答的前二十名段落命中率上，比傳統的 BM25 關鍵字檢索高出 9 到 19 個百分點^[5]。Guu 等人更早一步，把檢索器和模型放在一起預訓練，讓模型自己學會該去找什麼，而且找到的文件是人看得到的^[6]。這個領域後來長出很多變形，Gao 等人的綜述把它們分成三代：直接把找到的段落塞進提示、在檢索前後加上重寫與重排、以及把檢索拆成可以組合的模組^[7]。

但對一個要導入的人來說，最重要的不是這些變形，是那條分界線本身：

小模型讀對的段落，追得上大模型

如果模型不必背，它需要多大？

Borgeaud 等人 2022 年的 RETRO 給了一個直接的數字。他們讓模型在生成時從一個兩兆 token 的文字庫裡檢索，結果一個參數量只有 GPT-3 二十五分之一的模型，在 Pile 這個語言建模基準上拿到跟 GPT-3 和 Jurassic-1 相當的表現^[8]。

Ram 等人 2023 年做了一個更省事的版本：模型完全不動，只是把現成的 BM25 檢索到的文件接在輸入前面，就在不同大小的模型上都看到明顯的改善^[9]。這一篇對要導入的人特別重要，因為它證明的是：你不需要改模型，也不需要訓練檢索器，就能拿到大部分的好處。

這兩篇合起來的意思是：當「知道什麼」被搬到索引裡之後，模型剩下的工作是「讀懂幾段文字並且好好回答」——而這件事，一台工作站裝得下的開放權重模型已經做得到。

只送幾段，不是把整份塞進去

有人會問：模型的上下文越來越長，直接把整份手冊丟進去不就好了？

兩篇論文說不好。Liu 等人 2024 年發現，把相關資訊放在長上下文的開頭或結尾時模型答得最好，放在中間時表現明顯下滑；而且上下文越長整體表現越差，連專門為長上下文設計的模型也一樣^[10]。Shi 等人 2023 年則量了另一種傷害：在數學題裡加進無關的句子，模型的正確率就大幅下降——它會被無關的東西帶著走^[11]。

所以「找」這一步不是為了省錢才做的。它決定了模型看到的是三段對的，還是三十段裡藏著三段對的。前者它答得出來，後者不一定。

為什麼這件事跟地端模型特別合

到這裡可以回答開頭那間公司的問題了。上面那條路的四步裡，只有一步認得模型是誰。這帶來三個結果，每一個都在講「地端」。

第一，文件不出門。 切段、計分、選段都是程式，在你的機器上跑。接地端模型時，整條路沒有任何一段文字離開你的環境；就算接外部 API，出去的也只有那幾段，不是整份文件。開頭那個「不能放到外面」的要求，在這個架構裡不是限制，是預設。

第二，提示長度是你自己的帳單。 用外部 API 時，多送幾段是多付一點錢；自己跑模型時，多送幾段是佔用你自己的顯示卡、拉長你自己的排隊。上一節那兩篇論文說「只送對的幾段」答得比較好，這一節說它同時也跑得比較動。兩個理由指向同一個做法。

第三，更新是重建索引，不是重新訓練。 Ovadia 等人 2023 年直接比了兩條路：用無監督微調把新知識塞進模型，或是用檢索把它接進來。結果檢索一致地贏，不管是模型本來就看過的知識還是全新的事實；而且他們發現模型很難靠微調學會新的事實，除非同一個事實用很多種寫法反覆出現^[12]。在地端，這個差別是實際的：微調要有人準備資料、跑訓練、驗證沒有順便忘掉別的事；重建索引是一個排程。

我們把它做成了 HangRui Index

上面那條路，我們先做在自己的站上。這個站的助理把站上的頁面切成幾十段、逐段對問題計分、只送分數最高的幾段進模型，再把答案裡的每個引用對回真正送出去的來源；每個答案下面印著三個數字——讀了幾段、送了幾段、引用驗了幾個——都是那一次真的跑出來的。怎麼切、怎麼計分、為什麼沒接框架，以及為什麼知識該放在索引而不是權重裡，前兩篇寫過了。

HangRui Index 是同一條路，指向你的文件。它把 PDF、Word、說明中心、工單系統裡的東西按原本的結構切段建索引；模型那一格可以接你機房裡的開放權重模型，也可以接外部 API，換一家是換一行設定；每個答案帶出處，每個出處驗過，數字一樣印在畫面上。文件改了，索引重建一次就是新的。

它賣的不是一個更聰明的模型。它賣的是那條路上模型以外的三步，以及「模型那一格由你決定放在哪裡」這件事。

這樣做的代價

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

地端模型讀得懂，但寫得比較平。 上面引的研究量的是答不答得對，不是寫得好不好。一台工作站裝得下的模型，句子通常不如最大型的 API 模型順。如果你的用途是「查得到、答得準」，這是可以接受的交換；如果是「寫得漂亮」，可能不是。

硬體要有人顧。 顯示卡、驅動、模型版本、量化格式，每一個都會變。外部 API 把這些收進帳單裡；地端把它們還給你。

引用的研究有它們的範圍。 這篇引的基準幾乎都是英文的公開資料集：維基百科問答、Pile、數學應用題。它們證明的是機制成立，不是「在你的中文維修手冊上一定成立」。哪些數字是在什麼資料上量的，上面每一句都有寫；我們自己在地端模型上的數字，還沒有。

沒有寫進來的東西。 檢索器本身怎麼訓練、要不要用向量而不是關鍵字、怎麼評估一條 RAG 管線——這篇都沒碰。它只講一件事：知識放哪裡、模型放哪裡，以及這兩個決定為什麼綁在一起。

接下來

這篇是那條路的第三篇。第一篇講程式怎麼驗引用，第二篇講知識為什麼放索引，這篇講模型為什麼可以留在你的機器上。

下一步是把它真的接上一個地端模型，然後量：同一組問題、同一份索引、換一格模型，三個數字各自變成什麼。量到了再寫。在那之前，你可以先在這個站上問一題，看那三個數字怎麼動。