農場病蟲害文件庫要用哪種 AI 技術？
某有機農場累積了十年的病蟲害防治紀錄文件，包含不同作物的病害症狀描述、防治方法和效果評估。農場主希望建立一個 AI 助手，能根據農民描述的作物症狀，快速提供相關的防治建議和歷史案例。下列哪一種技術最適合解決這個需求？
一家有機農場累積了十年的病蟲害防治文件，記錄了不同作物的病害症狀、防治方法和效果評估。農場主想建一個 AI 助手：農民描述作物症狀，AI 就能從這批文件裡找出相關建議和歷史案例。
問你：要讓 AI 助手能查閱農場自己的十年文件庫來回答農民的問題，該用哪種技術？
一句話總結
有一大批私有文件、需要 AI 查完再回答時，RAG（Retrieval-Augmented Generation，檢索增強生成）是標準做法：先把文件變成向量資料庫，用戶問問題時先搜尋相關文件片段，再把片段交給大語言模型組成回覆。
先感受問題：農場累積了十年文件，農民怎麼快速查？
「綠野有機農場」的場主陳大明，十年來把每一次病蟲害的情況都記錄下來：2015 年 6 月番茄葉片出現黃斑、原因是早疫病、處理方式是施用某種有機銅劑、效果評估等等，總共累積了 3,000 份文件。
現在一個年輕農民阿志跑來說：「我的稻子葉尖變黑，有點像燒焦，最近雨水多，怎麼辦？」
陳大明腦海裡隱約記得幾年前有類似案例，但 3,000 份文件他翻不完。他希望建一個 AI 助手，阿志輸入症狀描述，系統能自動找出最相關的歷史案例並給出建議。
關鍵問題：這 3,000 份文件是農場私有的，ChatGPT 這類通用模型訓練資料裡沒有。要讓 AI 能查這些文件，得想辦法讓它「存取」這批資料。
沒有 RAG 之前，私有文件庫怎麼用？
- 直接問通用 AI：ChatGPT 有農業通識，但不知道綠野農場的具體記錄。回答是通用知識，不是農場自己的案例，對阿志的情況未必適用
- 把文件全貼進提示詞：3,000 份文件幾百萬字，大語言模型的輸入長度有限制（通常幾萬到幾十萬 token），根本塞不下。即使塞得下，成本也極高
- 人工整理 FAQ：請人把 3,000 份文件整理成問答，費時費力，而且整理完又過時了
- Fine-tuning（微調模型）：把文件用來訓練模型，但農場每週都有新紀錄，訓練一次要花大量資源，無法即時更新
- 關鍵字搜尋：阿志說「葉尖變黑」，但文件裡寫的是「葉片末端褐化」，關鍵字對不上就搜不到
以上方法都有共同問題：要嘛資料用不到，要嘛成本太高，要嘛無法即時更新。
RAG 怎麼解
RAG（Retrieval-Augmented Generation，檢索增強生成）把這個問題分成兩個階段：
第一階段：建庫（Indexing）。把 3,000 份文件拆成段落，每段話用嵌入模型（Embedding Model）轉成一串數字（向量）。這些向量存進向量資料庫（Vector Database）。這個過程就像把每段文字都「翻譯成坐標」，意思相近的句子坐標會很近。
第二階段：查詢與生成（Retrieval + Generation）。阿志輸入「稻子葉尖變黑，像燒焦，雨水多」，系統先把這句話也轉成向量，在資料庫裡找出最相近的 5-10 段文件片段。找到之後，把這些片段和阿志的問題一起送進大語言模型，模型根據這些「相關的證據」組合成一個有依據的回覆。
這樣，農場的私有文件庫就變成了 AI 助手的「即時查閱資料」。新增文件只要重新嵌入存入向量庫，不需要重新訓練模型。
這就是選項 C 講的：採用 RAG 技術，將農場文件建立向量資料庫，結合大語言模型生成回答。
技術版：RAG 在生成式 AI 應用架構中的位置
RAG 屬於生成式 AI 應用設計的「知識擴充」模式，解決的是大語言模型的核心限制：訓練資料有截止日期、無法存取私有資料、輸入長度有限制。
RAG 的完整流程：
- 文件前處理：把 PDF、Word、純文字等文件切成合適長度的段落（通常 200-500 字）
- 向量化（Embedding）：用嵌入模型把每個段落轉成高維度向量（如 1536 維），語意相近的段落向量距離近
- 向量儲存：向量存進向量資料庫，常見工具有 Pinecone、Weaviate、Chroma、pgvector
- 查詢時檢索（Retrieval）：使用者輸入問題，問題也轉成向量，計算與資料庫中所有段落的相似度，取前 K 個最相關段落
- 增強生成（Augmented Generation）：把檢索到的段落作為「上下文」放入提示詞，讓大語言模型基於這些資料生成回覆
RAG vs. Fine-tuning 的差別：Fine-tuning 是把知識「燒進」模型權重，更新需要重新訓練；RAG 是每次查詢時即時撈資料，資料更新不需要重新訓練模型，適合頻繁更新的私有文件庫。
為什麼初級考這題：AI 應用規劃師在規劃企業 AI 助手時，最常面對的場景就是「公司有一堆文件，希望 AI 能依據這些文件回答問題」。RAG 是這類需求的標準解法，能正確識別 RAG 的適用場景是規劃師的基本能力。
為什麼其他選項是錯的
A直接使用 ChatGPT 的預訓練知識回答農業問題
不做任何額外設定，直接用 ChatGPT 等通用模型回答農業問題，靠它在訓練時學到的農業知識。
ChatGPT 的訓練資料不包含「綠野有機農場的十年記錄」這類私有資料。它能給出通用農業建議，但無法引用農場自己的歷史案例。題目明確說要「提供相關的防治建議和歷史案例」，通用模型做不到這一點。
對 RAG 不熟、以為 ChatGPT 什麼都知道的人。通用模型的強項是廣泛知識，弱項是私有、即時、特定組織的資訊。
B將所有文件內容加入 ChatGPT 的系統提示詞中
把 3,000 份文件全部貼進每次對話的系統提示詞（System Prompt），讓 AI 直接「看到」所有資料。
大語言模型的 Context Window（輸入上限）有限制，3,000 份文件根本放不下。即使未來模型支援更長 Context，每次請求都傳送全部文件，API 費用極高，回應速度也會很慢。RAG 只傳送「最相關的幾段」，效率高很多。
知道「要把資料給 AI 看」但不知道向量檢索做法的人。B 方向對，但工程上不可行。
D使用少樣本學習（Few-shot Learning），在提示詞中提供 3-5 個病害案例
每次問問題時，在提示詞裡放 3-5 個相關病害案例作為範例，讓 AI 學習這個格式後給出回覆。
Few-shot Learning 是讓模型學習「回覆的格式與風格」，不是讓它查閱完整的 3,000 份文件。3-5 個例子遠不夠覆蓋所有病蟲害情況。農場有 3,000 份歷史紀錄，目的是讓 AI「查得到」這些紀錄，不是「模仿格式」。
混淆 Few-shot（示範格式）和 RAG（查閱資料庫）兩個概念的人。Few-shot 是提示技巧，RAG 是知識存取架構，兩者解決不同問題。
同個考點下次怎麼變形
某公司有一千份內部合約文件，希望員工能用自然語言查詢合約條款，應選哪種技術架構？
跟農場案例幾乎一模一樣，只是場景換成法律文件。
RAG。把合約文件建成向量資料庫，員工自然語言查詢時先檢索相關條款片段，再由大語言模型組合成回覆。關鍵判斷：私有文件庫 + 即時查詢 = RAG。
RAG 系統中「向量資料庫」的主要用途是什麼？
考 RAG 各元件的功能，常見出題角度。
存放文件段落的向量表示，並支援語意相似度搜尋（Semantic Search）。使用者查詢時，系統把查詢也轉成向量，在資料庫裡找語意最近的段落，不是用關鍵字比對。
RAG 和 Fine-tuning 的主要差別是什麼？什麼情況下選哪個？
兩者都能讓模型「懂特定領域知識」，但原理不同。
RAG 是查詢時即時取用外部資料，資料更新不需重新訓練，適合文件頻繁更新的場景；Fine-tuning 是把知識融入模型本身，適合固定的領域風格或特定任務格式。農場的文件每週都有新紀錄，選 RAG 更合適。
為什麼把「所有文件塞進提示詞」不是 RAG 的替代方案？
感覺直接塞進去更簡單，為什麼不行？
Context Window 限制（目前主流模型通常 8k-128k tokens，百萬字的文件庫放不下）、成本問題（每次請求都傳大量 token 費用高）、品質問題（模型處理過長上下文時注意力分散，準確率下降）。RAG 只傳相關片段，三個問題都解決。
企業要建立 RAG 系統，最核心的前置工作是什麼？
直接接 API 就能用嗎？還是要先做什麼？
文件的向量化與索引建立（Indexing）。必須先把所有文件切段、用嵌入模型轉成向量、存進向量資料庫，後續查詢才能運作。這一步做得好不好直接決定 RAG 系統的品質，文件切法和嵌入模型選擇都很關鍵。
想再往下看，這 5 個
- RAG（Retrieval-Augmented Generation，檢索增強生成）結合「檢索」與「生成」兩個步驟，讓大語言模型能基於即時查詢的外部文件給出有依據的回覆
- 向量資料庫（Vector Database）存放文字嵌入向量的特殊資料庫，支援語意相似度搜尋，常見工具有 Pinecone、Chroma、Weaviate
- 嵌入模型（Embedding Model）把文字轉成高維度向量的模型，語意相近的句子向量距離近，是 RAG 系統的核心元件
- Context Window（上下文視窗）大語言模型單次能處理的輸入文字上限，是把「所有文件塞進提示詞」方案不可行的根本原因
- Few-shot Learning（少樣本學習）在提示詞中給少量範例讓模型學習格式與風格，與 RAG 解決不同問題：一個教「怎麼回」，一個教「查什麼資料」