文件太大塞不進 prompt 怎麼辦？RAG 檢索增強生成入門

你手上有一份幾百頁的報告，想直接問 AI「這家公司有哪些風險」。最直覺的做法是把整份文件貼進去，但你很快會發現：要嘛塞不下，要嘛又貴又慢，答案還不見得比較好。

這篇是酒Ann 的 RAG 系列第一篇。我們先把「為什麼需要 RAG」想清楚，之後再談切片、embedding 與檢索品質時，你才知道每個步驟到底在解決什麼問題。

一份 800 頁的文件，要怎麼問它問題

情境很具體：你有一份 800 頁的財務文件，想問「這家公司有哪些風險因子」。問題來了，模型又沒讀過這份文件，你得想辦法把相關內容送到它面前。而 prompt 能放的文字量是有上限的，這就是整件事的起點。

做法一：整份塞進 prompt

第一種做法最直覺：把文件的全部文字抽出來，連同使用者的問題一起塞進 prompt。長得大概像這樣：

Answer the user's question about the financial document.

<user_question>
{user_question}
</user_question>

<financial_document>
{financial_document}
</financial_document>

看起來沒毛病，但實際跑起來有四個硬傷：

• 長度有上限：prompt 的長度是有硬性限制的，文件太長就是塞不進去。
• 效果會變差：prompt 拉得非常長的時候，模型的表現反而會下降。
• 比較貴：prompt 越大，處理的費用越高。
• 比較慢：prompt 越大，處理的時間也越長。

換句話說，就算勉強塞得下，你也是在用更高的成本與更長的等待，換一個不見得更好的答案。而且這筆帳每問一次就要付一次：同一份 800 頁的文件，使用者問十個問題，你就把整份文件送進模型十遍，量一大，成本與延遲都會失控。

做法二：先切塊，提問時只送相關的

RAG 換了一個聰明的思路。第一步，在前處理階段先把文件切成一塊一塊的小段落（chunk）。第二步，等使用者提問時，先在這些切塊裡搜尋出跟問題最相關的幾塊，只把這幾塊放進 prompt。

拿剛才的例子來說：有人問「這家公司面臨哪些風險」，系統就去切塊裡搜尋，找到「風險因子」那個章節，然後只把這一段連同問題送給 Claude。模型讀的不是 800 頁，而是真正相關的那幾頁。

值得注意的是，這兩個步驟發生的時間點不一樣。切塊是前處理，文件進系統時做一次就好；搜尋則是每次提問時即時發生。這個分工正是 RAG 撐得起規模的關鍵：昂貴的整理工作事先做完，使用者提問的當下，系統只需要一次快速的檢索加一個小 prompt。

好處與代價，一次看清楚

RAG 不是免費的午餐。它給你的好處，跟你要付出的工程代價，可以放在同一張表上看：

「切塊可能缺少完整脈絡」是實務上最常被低估的一項。段落被單獨抽出來之後，原本靠前後文才說得通的內容可能變得斷頭斷尾，模型只拿到片段，答案的品質就跟著受限。而切塊的方式非常多：可以照固定長度切，也可以照標題、章節這種文件結構切，每種切法都有取捨。

這個主題夠重要，我把它留到系列的下一篇專門講。

什麼時候值得用 RAG

RAG 牽涉很多技術決策，也比「全部塞進 prompt」多出不少工。所以判斷準則很務實：先評估好處有沒有大過複雜度。當你面對非常大的文件、多份文件，或需要把成本與速度壓下來的時候，RAG 特別有價值；反過來說，文件本來就不大，直接放進 prompt 就好，別為了用技術而用技術。

另一個常見的適用場景是知識庫問答：資料不是一份文件，而是幾十份、上百份的手冊、報告與會議紀錄。這種量級不可能靠塞 prompt 解決，RAG 幾乎是唯一走得通的路。

下一篇我們就從整條管線的第一站開始：文本切片（chunking）。切得好不好，直接決定後面檢索的品質。