Building a Private RAG System for Landscape Design Decision-Making
這兩年，我一直在想一個問題：
ChatGPT、DeepSeek 這些大模型已經這麼強了，為什麼真正拿進景觀設計公司之後，還是常常覺得「差那麼一點」？
問題其實不在它不會說。反而是它太會說了。
問它一個公園怎麼設計，它可以很快整理出功能分區、生態策略、雨洪管理、植物配置，甚至幫你寫出一篇相當完整的設計說明。但真正做工程的人很快就會發現：它知道的，多半是「一般性的知識」。
一旦問到更具體的問題，例如：
「生態公園到底有哪些規定？」
「這個地方可以不可以這樣做？」
「臺北這種氣候應該用哪些植物？」
「這個節點公司以前怎麼處理過？」
「某個做法到底有沒有違反規範？」
普通大模型就很容易開始模糊。
尤其景觀設計同時牽涉法規、工程、植物、生態、造價與地方條件，靠網路上那些通用知識，很難真正支撐專業決策。更麻煩的是，設計公司真正有價值的東西——過去的中標方案、施工圖、材料經驗、專家評審與項目復盤——通常又不能全部丟到公有雲端，因爲具有一定的私密性。
所以研究團隊這次做的事情很直接：
既然大模型不知道公司的專業經驗，那就自己建立一個知識庫給它。
這就是這項研究的核心。
RAG 到底是什麼？其實可以把它想成「AI 的專業資料室」
我們採用的是 RAG（Retrieval-Augmented Generation，檢索增強生成）。
這個名字聽起來很技術，但概念其實不難。一般的大模型回答問題，大多依賴自己訓練時已經學過的內容。
RAG 則多了一個動作：先找資料，再回答。
例如設計師輸入：
「生態濕地公園有哪些規定？」
系統不是立刻讓 DeepSeek 自己回答，而是先到我們建立的知識庫裡，把《公園設計規範》中真正相關的條文找出來，再把這些內容一起交給大模型，最後才生成答案。
換句話說，大模型負責「理解與推理」，知識庫負責「提供證據」。
我覺得可以很簡單地理解成：
大模型是腦，RAG 是外接的專業記憶。
這也是為什麼它特別適合景觀、建築這種高度依賴規範與專業知識的行業。
景觀公司的知識，到底應該放什麼？
做到這一步之後，真正困難的問題反而出現了：
我們到底要教 AI 什麼？
設計公司裡的資料其實非常亂。
規範是 PDF，施工圖是一套圖紙，植物表是 Excel，會議紀要是 Word，材料照片可能散落在不同人的電腦裡，設計師真正珍貴的經驗甚至只存在腦子裡。
所以我們先把景觀知識重新整理成三大類：
約束、經驗、事實。
這三個層級，我覺得是整個研究裡最值得設計公司參考的部分。
第一層：Constraint｜約束
這些是强制性不能亂來的東西。
例如：
國家強制性標準、地方技術規定、行業規範、上位規劃，以及各種涉及安全與法規的要求。
它們的作用不是幫助 AI「更有創意」，而是告訴 AI：
這條線不能踩。
第二層：Experience｜經驗
這一層最有價值。
因為它代表一家設計公司真正多年累積下來、別人拿不到的東西。
包括：中標方案、競賽文本、施工圖設計說明、成熟節點、植物配置清單、工程造價、材料封樣、歷次專家評審意見，甚至建成後哪些鋪裝容易老化、哪些植物容易死，都可以放進去。
這些資訊以前常常是：
做完一個項目，就跟著項目一起封存。
下一個設計師再遇到類似問題，又重新來一次。
如果 AI 能真正調用這些經驗，公司十幾年的項目就不只是「硬碟裡的舊檔案」，而可能變成可以持續工作的知識資產。
第三層：Fact｜事實
這一層處理的是：
這個場地真實的條件。
例如地形、氣候、土壤、現況植物、動物棲息地、材料性能、苗木規格，甚至人流熱力圖與 GPS 軌跡。
這些資料可以讓 AI 不只是講「應該增加鄉土植物」，而是進一步回答：
在這個地方，到底什麼植物比較適合。
所以我們最後形成的邏輯其實很清楚：
約束告訴 AI 不能犯什麼錯；
經驗告訴 AI 過去怎麼做；
事實告訴 AI 現在這個場地是什麼。
這三個東西放在一起，AI 才開始有一點像真正的「設計助理」。
真正麻煩的，其實不是模型，而是資料整理
做到這裡，我也更加確認一件事：
AI 落地最累的，往往不是 AI。
是資料。
很多公司資料都是掃描 PDF、老 Word、Excel、施工圖說明，直接全部丟進知識庫，其實效果不一定好。
所以研究裡先把非結構化文件重新整理。
例如：把 PDF 轉成層級清楚的 Markdown，去掉頁眉頁腳與無關內容；植物表、材料參數等比較規則的資料，則整理成 JSON 或 CSV。因為電腦不是「看到一份文件就懂」。你必須先把它整理成機器比較容易理解與檢索的知識單元。甚至連文件要切成多大的片段，都會影響結果。
切太大，AI 找回來的內容會夾雜很多無關資訊；切太小，又可能把一條完整規範拆斷。
我們因此採用了帶有 20%～30% 重疊率的切片方式，盡量讓「但是」「除非」這類規範裡很重要的邏輯關係不要被切掉。
這些事情很瑣碎。但其實恰恰決定了最後 AI 到底「真的懂」，還是只是「看起來懂」。
系統怎麼搭？
這次研究使用的核心工具包括：
AnythingLLM + LanceDB + DeepSeek。
AnythingLLM 負責管理知識庫與工作區；
LanceDB 負責把大量文本轉成可以被快速搜尋的向量資料；
DeepSeek 則負責最後的推理與回答。
整個架構最重要的想法並不是一定要用哪個軟體。
而是：
公司自己的資料與大模型本身，可以分開。
知識庫放在企業自己控制的環境裡，大模型則負責推理。這樣既可以利用大型模型的能力，也不必把所有公司歷史資料全部交出去。
那實際效果到底有沒有差？
我們沒有只停留在「搭出一個系統」，而是拿實際景觀項目做測試。
實證案例是：
「螺洲省級歷史文化名鎮旅遊配套基礎設施提升工程」。
同樣的問題，一組直接交給普通大模型回答，另一組則使用掛載私有知識庫的 RAG 系統。
之後找了 5 位具有高級職稱的資深風景園林設計師進行雙盲評審。
評分時，專家不知道哪個答案是哪個 AI 生成的，只按照五個項目打分：
專業準確性、法規符合度、邏輯連貫性、生態可持續性、工程落地性。
最後的結果差距其實蠻大。
| 評價項目 | 普通大模型 | RAG 私有系統 |
|---|---|---|
| 專業準確性 | 2.8 | 4.4 |
| 法規符合度 | 1.6 | 4.6 |
| 邏輯連貫性 | 3.2 | 4.2 |
| 生態可持續 | 2.4 | 4.0 |
| 工程落地性 | 2.0 | 4.0 |
其中最明顯的，就是法規符合度。
普通模型碰到防洪標準、規範條文這些問題時，常常只能給出一些「原則上應該……」的描述。RAG 系統則會真正去找規範。所以它的回答開始變成：
有根據的回答。
這個差別對工程設計來說非常重要。因為設計師最怕的並不是 AI 說「不知道」。
而是：
AI 很有自信地說錯。
但我並不認為 AI 因此可以取代設計師
做完這套系統之後，我更確定：
AI 最適合的位置，是幫設計師把知識找回來，而不是替設計師下最後決定。
目前這套系統還是以文字、規範與表格為主。
它還不能真正看懂 CAD 圖面、GIS、效果圖，也還沒有能力直接判斷一張圖紙裡的空間關係。
這會是下一步真正值得研究的方向。
另外還有一個很有意思的矛盾：
知識庫越嚴格，AI 越可靠；但也可能越不敢創新。
所以未來比較合理的做法，可能不是從頭到尾都把 AI 綁死。
而是：
概念階段，讓 AI 放開一點；
深化階段，再把規範、工程與在地資料逐步加進來。
前期幫忙探索可能性，後期幫忙守住專業底線。
這次研究做完，我最大的感不是：
突然重新看見了設計公司那些被忽略很久的資料。
十年的方案。
十年的施工圖。
十年的評圖意見。
十年的材料踩坑。
十年的植物死亡紀錄。
以前它們只是檔案。
但在 AI 時代，這些東西可能突然變成一家設計公司最重要的競爭力。
因為模型大家都可以買。ChatGPT、DeepSeek，大家都可以用。
真正不容易複製的，是：
你做過什麼，以及你從這些項目裡學到了什麼。
也許未來設計公司的 AI 能力，不是看「用了哪一個模型」。
而是看：
這家公司，有沒有把自己的經驗真正變成知識。
