先說結論:
目前本地端 AI 模型在處理複雜任務上，智慧程度與雲端模型（如 Claude, GPT-4）存在巨大代價。
痛點： 本地模型運算力不足，導致正確性低下。
代價： 若要維持本地化，必須投入極高精準度的 Prompt Engineering 或高度自動化的流程輔助。
專案架構
1-資料層優化 (Data Engineering)-簡化限縮到單一資料表做銷售月報表
2-語義強化-欄位名改用中文方便AI識別
3-用PYTHON寫搭claude做出SERVER、CLIENT程式
4-透過AI模型查詢銷售月報表並整理內容
但問題不在程式而是AI模型
嘗試以下的幾種做法
1-AI改用LOCAL端
發現很明顯的變笨
原本用雲端AI回覆的很快又正確
整理的資料也很完整
改LOCAL就錯誤連篇
2-查詢時，載入全部資料或下SQL語法
在雲端都沒問題
但在LOCAL端都做不好
下SQL語法常下不對語法，找一些不存在的資料表、欄位名
就算用PROMPT限制提問
LOCAL的AI還是錯
另外用載入的方式去整理
看載入內容是正確
但經AI整理後就錯誤
可能載入的資料量太大(超過10萬筆)
LOCAL的AI運力不夠
因為有公司的隱私資料
所以還是會用LOCAL的AI
只是要架算力更強的模型才能解決正確性的問題了.
本地端 AI 遇到的三大難關 (The Roadblocks)
難關類型具體表現專業加註說明邏輯退化改用 Local 端後，模型明顯變笨，錯誤連篇。
本地模型參數通常較小（如 7B/14B），邏輯推理與指令遵循能力遠弱於雲端千億級模型。
SQL 語法失敗常下錯 SQL 指令，甚至虛構（幻覺）不存在的資料表或欄位。
此為典型的 Text-to-SQL 失敗。
小模型對複雜 Schema 的理解力不足，容易產生「幻覺」。
處理容量極限載入超過 10 萬筆 資料時，模型無法有效整理。
這是「脈絡長度（Context Window）」與「運算力」的限制。小模型在長文本中檢索資訊（Needle in a Haystack）的能力通常較差。
自我LV~
