Engineering Overview
從一句話需求，到可執行的用餐安排
ByteBites 由三個服務組成：Java 後端擁有交易狀態、Python AI 服務負責理解與推薦、 Next.js 與 LINE 提供雙入口。這一頁整理系統的運作方式與工程實證。
ByteBites
AI Dining Concierge
BYTEBITES DRAFT
確認訂位內容
599
台北店家
真實爬取資料：照片、評論、ABSA 情感分析與向量索引全對齊
3,600
店家照片
每店 6 張高解析總覽照，缺漏與重複皆為 0
341
自動化測試
Java 115 · Python 191 · Web 35，CI 全綠
15/15
檢索評估
Hit@5 回歸防護網，排序改動前後必跑
How it works
一次訂位在系統裡的六個階段
每個階段都能在這個網站與 LINE 上實際操作；下方每張卡描述的是系統行為，不是概念圖。
自然語言需求
使用者在 Web 或 LINE 說出地點、料理、人數與時間。條件不足時，AI 會先追問收斂，而不是硬給結果。
結構化推薦
推薦卡帶出區域、菜色、適合情境與推薦理由；排序品質由版本化的檢索評估（Hit@5）持續把關。
訂位草稿
AI 從對話整理出店家、日期、時間與人數，先產生草稿讓使用者確認，不會直接替使用者下訂。
確認後執行
Web 與 LINE 都以確認卡送出；訂位建立、訂金與付款全部由 Java 後端的交易狀態機處理。
狀態同步
付款、額滿候補、改期與取消，在 Web 與 LINE 讀寫的是同一套後端狀態，不存在兩份真相。
出發前提醒
開車的訂位者會在出發前收到附近停車資訊與提醒，把服務範圍從「訂到位」延伸到「順利抵達」。
Design decisions
四條刻意畫出的邊界
這些不是功能列表，是系統設計時做出的取捨。
完整旅程，不只搜尋
多數平台停在找店。ByteBites 把搜尋、訂位、付款、候補通知與停車提醒接成同一條可執行的流程。
高風險動作先確認
訂位與付款不靠模型猜測。AI 只產生草稿，送出永遠發生在使用者明確確認之後。
雙入口、單一狀態
LINE 與 Web 介面各自最佳化，但推薦、訂位、付款與通知共享同一套後端 contract。
商家端閉環
商家後台管理時段容量、臨場事件與退款，讓 AI 訂位落到真實營運資料，而不是聊天演示。
Engineering evidence
可驗證的工程實證
以下每一項都對應 repo 裡可執行的測試、評估報告或模組； 完整的架構決策（ADR）與工程案例（case studies）收錄在原始碼的 docs 目錄。
閱讀工程案例Java（Spring Boot 3 + JPA）擁有訂位、付款、候補、事件與退款的交易狀態機 — 115 個測試
Python（FastAPI + Gemini function calling + Qdrant）負責語意檢索、對話 Agent 與 LINE 流程 — 191 個測試
檢索品質有回歸防護網：版本化 gold dataset，Hit@5 15/15，改排序前後必跑
Guardrail 雙向防護：輸入端擋 prompt injection，輸出端句級過濾而非整段封殺
Prometheus 記錄每次 LLM 呼叫的 token 用量與延遲，Grafana dashboard 可視化
AI 服務依依賴方向分層：config → ranking → retrieval → agent → line_routes