AI APPLICATION · GRADUATION PROJECT
2025
結合 RAG、生成式 AI、向量資料庫與地理空間演算法， 降低 AI 推薦不存在景點、錯誤地點與不合理路線的問題。
一般生成式 AI 雖然能快速產生旅遊建議， 卻可能推薦不存在、已歇業或位於其他縣市的地點。 TravelAI 嘗試在生成速度與資訊可靠性之間取得平衡。
規劃自由行需要同時處理地點、時間、交通與天氣， 而通用大型語言模型缺少即時且可驗證的在地資料。
先從經過整理的景點資料中檢索真實候選項目， 再交由 Gemini 規劃行程，並透過演算法與即時 API 補足地理、交通、天氣與營業資訊。
系統不是讓模型直接憑空回答，而是建立多層資料流程， 讓產生的旅遊行程更容易被驗證與實際執行。
使用 Supabase 與 pgvector 進行語意搜尋， Gemini 僅能從檢索結果中挑選景點，降低虛構內容。
使用 K-Means 將景點依地理位置分群， 再以最近鄰演算法安排每日順序與午餐時段。
串接中央氣象署與 Google Places， 補充天氣、評分、照片、營業狀態及交通資訊。
前端使用 React 與 Vite，後端部署於 Vercel Serverless， 並將 Supabase、Gemini、Google Maps 與中央氣象署資料串成完整流程。
從自然語言中取得縣市、天數與旅遊偏好。
同步取得天氣資料，並從向量資料庫檢索景點。
將真實景點與天氣資訊整理成結構化 Prompt。
由 Gemini 產生可解析的行程 JSON。
依座標分群、排序，並補充交通與地點資訊。
完整行程需要經過多個 AI 與資料查詢階段。 系統使用 SSE 回傳即時進度，避免使用者面對沒有回應的空白畫面。
本專題為兩人團隊共同完成，我擔任主要開發者， 負責大部分系統設計與程式實作。 專題方向、測試與成果整理則由團隊共同討論完成。
將照片、評分等非必要查詢移至前端， 並以 Promise.all 平行執行天氣與 RAG 檢索， 降低後端等待時間。
使用 RAG 候選資料作為白名單， 再以 Google Places 確認地點狀態， 減少虛構店家及地理錯置。
改用 Server-Sent Events 分階段回傳處理狀態， 讓使用者知道系統正在解析需求、檢索與生成。