Industry RAG

餐飲菜單 AI 客服,是把菜單成分、過敏原與素食辣度資料建成知識庫,讓顧客即問即答的檢索式應用。
傳統做法是店員背成分、翻活頁夾,或請顧客等現場問廚房。RAG(檢索增強生成)的差別在於:先把每道菜的食材、過敏原、素食分類與辣度標準化成文件,再用向量索引檢索,最後讓 AI 只根據查到的內容作答,並附上出處。顧客在官網、LINE 或現場平板打字問「這道有沒有花生」,系統就從你的菜單資料回答,而不是憑空生成。
高雄新興、苓雅一帶餐飲與連鎖店密集,午晚餐尖峰時,店員一邊出餐一邊要回答成分問題,很容易講錯或講不清楚。過敏原若答錯,不只客訴,還可能是食安風險。
我在苓雅開連鎖麵食,午餐 11 點半到 1 點大約要出 180 碗。以前顧客問『麻醬有沒有堅果』,新來的工讀生答不出來,只能跑去問廚房,一來一回耽誤 3 分鐘,後面排隊 8 個人開始不耐煩。有一次答錯,一位對堅果過敏的客人吃了才發現,當場退餐加道歉,那天光處理這件事就花了快半小時。
問題不在店員不用心,而在資料散在紙本、群組訊息和老員工腦袋裡。新店開幕、人員流動時,這些知識沒被系統化,尖峰時就靠人硬撐,答案品質全看當班是誰。
這正是賴家榮,甫東科技創辦人、SAIP 台灣首席 AI 長、SGS AI 認證;16 年帶團隊為超過 500 家企業做過系統與 AI 導入;服務高雄、台南、屏東、嘉義的中小企業主管與第一線團隊;開發時用 Claude AI、Codex、Antigravity 三工具分工,最常協助餐飲業者處理的第一線問題:把分散的菜單知識收攏成一套能即問即答的客服系統。
RAG 的核心是把菜單知識拆成可檢索的小單元,讓 AI 回答時有據可查。以下用一張對照表,說明常見顧客問題、需要準備的資料,以及 RAG 的處理方式。
| 顧客問題類型 | 需準備的知識文件 | RAG 處理與輸出方式 |
|---|---|---|
| 成分/有沒有某原料 | 每道菜完整食材清單、供應商配方表 | 檢索該菜品條目,列出含與不含,標菜單版本出處 |
| 八大過敏原 | 過敏原對照表(甲殼、堅果、蛋、奶、麩質等) | 比對菜品標籤,明確回覆含哪幾項,不確定就轉真人 |
| 素食分類 | 全素/蛋奶素/五辛素標註表 | 回覆分類等級並列出可食清單,避免只答『可以』 |
| 辣度分級 | 辣度標準(微辣、小辣、中辣、大辣對應描述) | 用分級描述回答,附可否調整、可否去辣資訊 |
| 套餐與客製 | 套餐組合、可加購與替換規則 | 組合規則檢索後回覆,超出規則範圍轉店長確認 |
以下內容基於 2026 年 7 月各工具版本。導入餐飲菜單 AI 客服不需要一次到位,建議先從一間店、一份主菜單試做,跑順再複製到其他分店。整個流程分七步,各步驟指定主要工具與角色分工。
輸入現有菜單、活頁夾、過敏原紙本、群組問答紀錄
動作彙整成一份原始清單並標出缺漏欄位
產出菜單知識盤點表
負責角色店長+顧問
常見地雷只收數位檔,漏掉老員工口頭知識與臨時客製規則
輸入盤點表原始資料
動作統一過敏原命名、素食分類與辣度分級用語
產出標準化菜單文件
負責角色顧問
常見地雷辣度用『很辣』等形容詞,未轉成可比對的分級
輸入標準化菜單文件
動作以單道菜為單位切分,補上分店、版本、日期標籤
產出結構化資料片段
負責角色工程
常見地雷一次塞整份菜單成一段,檢索時抓不到正確菜品
輸入結構化資料片段
動作建立向量索引與檢索管線,設定相似度門檻
產出可檢索知識庫
負責角色工程
常見地雷門檻設太寬,把不相關菜品也一起帶進答案
輸入檢索結果
動作限制 AI 只依檢索內容作答,未命中就回『請洽店員』
產出受控問答引擎
負責角色工程+顧問
常見地雷沒設防杜撰規則,AI 自行編出不存在的成分
輸入受控問答引擎
動作串接官網、LINE 與現場平板,統一入口
產出多通路菜單客服
負責角色工程
常見地雷各通路各接一套,答案版本不同步
輸入多通路菜單客服、真實顧客提問樣本
動作抽驗過敏原答案、由店長人工覆核高風險回覆
產出上線版本與維運清單
負責角色店長+顧問
常見地雷上線就放手,過敏原答案未保留真人把關機制
七步走完,重點不是換掉店員,而是讓店員手上有一個永遠答得出、答得準的助手,尖峰時也能穩定服務。
若看不到上方流程圖,以下表格提供等價資訊:導入依序經過需求釐清、文件清理、切分策略、向量索引與檢索、生成與出處控制、介面與整合、試運行與維運七個階段,每階段都有明確產出。
| 階段 | 主要動作 | 產出 |
|---|---|---|
| 需求釐清 | 確認要回答哪些菜單問題與風險項目 | 需求與風險清單 |
| 文件清理 | 統一過敏原、素食、辣度用語 | 標準化菜單文件 |
| 切分策略 | 以單道菜為檢索單元切分並加標籤 | 結構化片段 |
| 向量索引與檢索 | 建索引、調相似度門檻 | 可檢索知識庫 |
| 生成與出處控制 | 限定依據作答、標出處、防杜撰 | 受控問答引擎 |
| 介面與整合 | 串官網、LINE、現場平板 | 多通路入口 |
| 試運行與維運 | 抽驗答案、人工覆核、定期更新菜單 | 上線與維運機制 |
我在新興開火鍋連鎖,第一次導入時貪快,把三家分店的菜單合成一份就上線。結果顧客問『招牌鍋底有沒有加酒』,AI 回答某分店的配方,但那位客人在的分店根本沒這款,害他白跑一趟。後來查才知道,是我沒把分店標籤切乾淨,檢索時三家資料混在一起。
修正方式是把分店、菜單版本與生效日期都做成檢索標籤,並在切分時就綁定,不要合併不同分店的菜單。同時設定『查無此分店資料時明確告知並轉真人』,避免 AI 拿別家答案硬回。上線前務必用真實提問抽驗跨分店情境,確認每家答的是自己的菜單。
導入前用以下八項自我檢核,逐項確認再上線,能大幅降低過敏原誤答與跨分店混淆的風險。
只要知識庫的過敏原資料正確,並設定 AI 只依檢索內容作答、查無資料就轉真人,就能大幅降低答錯風險。過敏原屬於高風險項目,建議上線後仍保留店長人工覆核機制,並定期比對廚房實際配方,確保菜單一有異動就同步更新知識庫。
以一間店、一份主菜單試做,通常數週內可先跑出可用版本,再逐步複製到其他分店。費用會依菜品數量、通路整合與維運範圍而不同,一般中小型餐飲導入約落在數萬元至數十萬元區間,建議先做需求釐清再報價,避免一次投入過大而難以驗證成效。
不需要整套重做。標準化文件與檢索標籤建好後,改菜單時只要更新對應菜品條目與生效日期,重新索引即可。建議把更新流程納入維運清單,指定專人在換季或改配方時同步,避免顧客查到舊版菜單而產生落差或誤解。
會一樣。導入時三個通路共用同一份知識庫與同一套問答引擎,因此不論顧客從哪個入口提問,檢索到的都是相同菜單資料。這樣可避免現場說一套、線上說另一套的情形,也讓店員與顧客對答案有一致的預期,減少爭議。
可以。知識庫的菜單內容一旦標準化,AI 就能用不同語言表達同一份成分與過敏原資訊,協助店員面對外籍或長輩顧客時溝通。不過涉及過敏原等關鍵資訊時,仍建議保留真人確認,確保翻譯與理解無誤,語言只是輔助而非取代把關。
不會取代,而是當店員的即問即答助手。尖峰時店員忙不過來,AI 能先擋掉大量重複的成分與辣度問題,讓店員專注在出餐與需要判斷的客製需求上。過敏原等高風險情境仍由店員與店長把關,系統的價值在於讓人力用在更需要判斷的地方。
若你在高雄經營餐飲或連鎖店,想讓菜單、過敏原與辣度問答不再靠人硬記,可以從一份主菜單開始試做,跑順再擴大。以下提供三種切入方式。
下載菜單 AI 客服上線前檢核表,逐項確認再導入
下載檢核表預約 30 分鐘諮詢,一起盤點你的菜單知識現況
預約諮詢需要企業內訓,讓團隊學會維運菜單知識庫,可索取報價
企業內訓報價

restaurant-menu-tablet.jpg|高雄餐飲連鎖店員在現場平板即時查詢菜單成分|https://www.pexels.com/photo/5908767/customer-phone-menu.jpg|顧客用手機查詢餐點過敏原與素食資訊|https://www.pexels.com/photo/5934556/diner-checking-food.jpg|顧客用手機查詢餐點過敏原與素食資訊|https://www.pexels.com/photo/4864249/本文為賴家榮 AI 教學中心原創教學內容;想讓團隊學會用 AI,歡迎看AI 課程或預約授課 →
代表圖片來源:圖片來源:Pexels