LLM 應用架構: 雲端閉源、本地開源

目前企業內部要應用LLM(大語言模型)，可以採取雲端或本地端方案。 雲端方案為相關服務呼叫提供LLM服務的供應商，通常依照使用量計費，企業內則不架設機房。 常見的雲端LLM服務供應商：

• OpenAI: GPT 系列 (GPT-4o, GPT-4)。
• Google: Gemini 系列 (Gemini 1.5 Pro)。
• Anthropic: Claude 系列 (Claude 3 Opus, Claude 3 Sonnet)。

如果對於將資料傳輸到雲端有疑慮，或者企業內有足夠人力維護設備，則可以採取本地端方案，運行開源的LLM model即可運作。 許多廠商都提供開源LLM模型，例如：

• Meta: Llama 3 8B
• Google: Gemma 7B
• Microsoft: Phi-3 Mini
• Mistral AI: Mistral 7B Instruct
• 01.AI: Yi-6B
• Cohere: Command R 35B

本地LLM 硬體需求

影響LLM回應品質的主要有三項：模型載入速度、推理速度、推理精度。 以下我們以Ollama、Llama 3 8B為架構案例，一一整理、分析相關的硬體需求。

1. 儲存空間 (Storage): 硬碟採用SSD讀取速度會較快。
2. 載入模型 (Model Loading): CPU會將模型從硬碟讀出，載入到VRAM，如果VRAM不夠，則載入到RAM中。
3. 推理生成 (Inference/Generation): 以GPU在VRAM中執行，如果VRAM不足，Ollama會使用主機的 RAM 和 CPU 來執行，這會大大降低推理速度。

Llama 3 8B

• Llama 3 8B指的是 參數數量 (parameters)大約 80 億參數
• Llama 3 8B各種量化版本所需要的影體儲存空間，其中FP16精度最高，Q4經過壓縮以減少RAM/VRAM使用，推理之精度較低。
• 模型的精度表示其理解、推理能力，精度高較能確實按照指令與方向執行、生成。
• 推理時所佔用的RAM/VRAM比載入時會再增加50%以上，例如Llama 3 8B Q4原本約4.5GB至5GB，推理時RAM/VRAM大約會使用到6GB至7GB之間。

模擬載入與推理速度

以「16 核心 CPU、40 核心 GPU、128GB 統一記憶體」此規格模擬

本地LLM 商務應用

1. Ollama 並沒有載入模型後就不是放的設定，但大約閒置30分鐘左右會釋放記憶體，因此若固定時間間隔呼叫Ollama，讓其不要釋放模型，可節省載入時間，但需要考慮到主機硬體可使用壽命以及額外的電力損耗。
2. 中小企業應比較適合使用Llama 3 8B Q4這個量化版本，否則推理速度太慢，影響使用體驗。

在這個案例車行的預約流程是：客人填寫LINE訊息要預約 → 車行客服檢查訂單資料是否完整 → 估算車資 → 填寫至線上行事曆。
本系統的核心目標是提供一個自動化且智能化的叫車服務與行程規劃解決方案，主要透過與通訊平台（如 LINE）整合，並利用大型語言模型（LLM）處理自然語言輸入，進而實現上述的行程規劃。

互動介面 (LINE Bot)

• 客人仍保持原本使用習慣，透過 LINE與本系統通訊。當用戶發送訊息時，系統會接收 Webhook 事件。
• 系統透過運用LLM(大語言模型)分析用戶想表達的意圖，並給予適當回覆，包括：訂車資訊表格、常見問題答案或訂單確認訊息。
• 例如，當系統識別到用戶有訂車意圖時，會發送訊息：「您好，請填寫訂車資訊\n1. 搭乘日期時間(年月日 時分)： \n2. 上車地點： \n3. 下車地點： \n4. 搭乘人數：」

LLM 意圖辨識，智慧應答，溝通零距離

• 精準意圖判斷：

  • faq (常見問題)：當客戶詢問服務價錢、時間或規則時。
  • order (填寫訂單資訊)：當客戶表達「想要訂車」或「提供搭乘日期、地點、人數等訂單細節」時。

• 自動分流與回應：將請求導向不同的處理流程。 ◦ 若為 faq，系統會在語料庫中向量搜尋出最高度相關的議題，並由LLM編寫文案答覆客人。 ◦ 若為 order，系統會引導使用者正確填寫必要資訊。

車行就有一個24待命的AI助手，這套系統能自動化初階的客戶互動與問題解答，大幅降低人力成本，並確保客戶無論何時都能獲得即時回應。

LLM 訂單資訊檢查，資料規格化

本案案例中，車行會要求客人必須提供：搭乘日期時間、上車地點、下車地點、搭乘人數，等四項資料。系統會解析乘客輸入的內容，自動識別並提示缺失的資訊，並自動將客人輸入的訊息，自動轉換。

• 乘車時間標準格式：每個人表達時間的方式不盡相同，除了確切時間外還有相對時間的表達方式，LLM都能自動轉換成標準格式。
• 地理編碼，定位精準無誤：
  • 系統會將乘客提供的上車和下車地點文字，分別呼叫 Google Maps Geocoding API 將其精確轉換為地理座標。這確保了路線計算的準確性。
  • 隨後利用這些地理座標，呼叫 Google Routes API，精準計算出預估的行駛距離和預估的行駛時間，找到最有效率的路線。
  • 根據計算出的行車里程距離，自動估算車資。計費規則清晰透明：起程距離 1.25 公里 (1250 公尺) 費用為 85 元，之後每 200 公尺加收 5 元。客戶能立即得知車資，提高信任感。
• 自動排程，告別人工建檔：
  • 在訂單確認後，系統會將完整的訂單資訊（包括搭乘時間、地點、預估距離、時間和車資）自動新增至Google日曆中。
  • 同時將這些詳盡的資訊自動回覆LINE訊息給客戶。

AI Workflow 自動化優勢

車行客服不再需要手動查詢地圖、複雜計算路線和車資、或手寫記錄排程。這套系統將整個叫車與排程流程自動化，從接單到出發，一氣呵成，大幅提升營運效率，並減少人為錯誤。

1. 大幅降低人力成本與錯誤率：AI 辨識意圖和自動化處理流程，減少了大量重複性的人工操作，讓您的人力資源能更聚焦於核心業務。
2. 顯著提升客戶滿意度：客戶能獲得即時回應、精準的行程規劃與透明的車資估算，顯著提升叫車體驗與信任度。
3. 營運效率全面升級：從客戶發出需求到訂單完成與排程，整個流程高速自動化，讓服務更具競爭力。

系統流程概覽

1. 使用者輸入 (Webhook)：LINE 用戶發送訊息。
2. 前置處理 (Code)：清理用戶輸入文本（移除引號、反斜線、換行符號），並獲取當前日期。
3. 意圖識別 ：使用 llama3 判斷用戶意圖（faq, order）。
4. 流程分流
5. 訂單資訊填寫與檢查，如果訂單資訊完整，則進入後續行程規劃，否則引導客戶補充資訊。
6. 訂單確認與行程規劃：
   • 資料解析：進一步解析 LLM 提取的訂單數據。
   • 地理編碼：使用 Google Maps Geocoding API 將上車和下車地點轉換為經緯度。
   • 路線計算：使用 Google Routes API 計算行駛距離和時間。
   • 費用計算與訊息生成：根據路線數據計算預估車資，並生成 LINE 回覆訊息（包含距離、時間、車資）。
   • 回覆用戶：將訂單摘要和預估資訊LINE訊息回覆給用戶。
   • 新增行事曆事件：將訂單資訊新增到Google日曆服務。

本案例的情境，是車行每個月需處理一千筆以上行程，如果遇到要統計資料或批次處理的情況，以人工一一處理肯定是來不及的，因此我們應用AI Agent，用來提供工作效率。

AI Agent結構介紹

1. Prompt：

   • 明確的提示工程：AI Agent 的內部指令經過精心設計，賦予AI Agent「工作職責」、「工作規則」，以及嚴格的輸出 JSON 格式要求。這確保了 AI 的行為符合預期，提供更穩定可靠的服務。

2. Chat Model：

   • 助理的大腦：能夠理解以口語、自然語言提出的請求。無論您說「今天有什麼行程？」還是「幫我刪掉下週的會議」，它能理解您的意圖，並判斷應該採取的行動、使用的工具。

3. Tools

   • 原生工具：需要有一點Javascript基礎，提供一些小工具給AI Agent使用，例如「Get Today」用於取得今天的日期。
   • 外部服務：透過「HTTP Request」工具與外部行事曆 API 服務進行互動。AI Agent會自行判斷、使用查詢活動列表和刪除指定活動等後端操作。
   • 結構化輸出：AI Agent 的最終回應會嚴格遵循特定的 JSON 格式。這種標準化的輸出，對於下游的應用程式或系統來說，處理和解析起來都非常方便和高效。

4. Memory

   • 記憶上下文：AI Agent能夠儲存對話歷史，記住您之前的互動內容。這使得對話更加連貫，您可以持續地與助理進行多輪交流，而無需重複提供相同資訊。

AI Agent特性介紹

1. 不用需要給詳細的操作步驟，只需要提供方向，AI Agent就會自行推理、判斷。
2. 適合統計資料或批次處理資料，例如：「計算八月份每日平均營業額」、「刪除客戶取消的行程」。

驗證結果

儘管智能行程規劃助理功能強大，但在使用初期，還是要驗證它的回覆是否正確，持續改善提示詞、給予適當的工具。

企業流程系統化面臨難題

企業將工作規範、標準流程都訂定並整理後，若公司本身並沒有足夠的軟體開發人力，大致只能發包給專業的軟體開發公司，或者研究市場上是否已有系統可以符合公司的企業需求。
後續外在環境或法令規範一旦有變化，企業內部的流程需求也需要跟著調整，因此須要持續負擔系統維護的人力成本，否則軟體系統與現況漸行漸遠，終致不敷使用而出現流程需要回到人工判斷的情況。

困境反轉的契機-LLM 大型語言模型

流程自動化最大的困難是無法將企業運作規則轉換成程式開發人員可以理解的規格，因此系統開發公司通常有專職人員，負責收集需求、分析出需求規格後，交予系統開發架構師設計出一整套系統的框架。
過去二、三十年，業界人士不斷地提出新的工具，試圖更有效率、準確地表達需求，例如UML Use Case、User Story等等，這些方法本質上還是需要高度專業人員執行。
近年來隨著LLM的能力持續增強與普及化，人們發現它可以越來越準確地理解各行各業的行規、行話，並且能用使用各領域的常識生成產出。
除了當生活中的小助手外，LLM也能理解口語文字訊息想表達的意圖，因此逐漸可應用在商用領域。

AI Workflow Automation / No-Code

• 企業內部不需要自己有會寫程式的IT人員，只要各部門能清楚描述作業流程與規定。
• 使用如 n8n這類的no-code/low-code工具，把各流程分析清楚再串連起來。
• No-Code：AI工具(例如n8n)會提供「積木」一樣的元件（通常叫 node / block），使用者只要拖拉、設定，就能把一個完整的流程拼湊出來。
• LLM 處理非結構化資料（意圖判斷、資料檢查），例如將客人的口語訊息，自動轉化為一張制式的訂單資料。
  AI Workflow Automation，適合應用在「製造業」、「運輸業」等有作業標準並且對於產品、服務需要做到高良率、高精度等要求的行業。
  應用AI工具、LLM的過程，比較大的困難是：要把流程拆得夠細夠清楚，還要會設計提示詞讓 LLM 正確理解。

AI Agents / Vibe Coding

分四部分：Prompt、Chat Model、Memory、Tools。我們只要把各種工具準備好，再給一個指示、目標，讓LLM自行運作。

• 設定高階需求的指示prompt，例如：「今天出門要帶傘嗎？」。
• 讓 AI Agent 的 Chat Model LLM 就像大腦，讓它推理「該用哪些工具、順序怎麼走」，例如：：查詢地圖資料、查詢天氣資料。
• Vibe Coding：人員是用自然語言描述需求，不用自己寫程式，就能讓AI自行編排程式流程，打造一套系統。
• AI Agent生成的結果是可能出錯的，需要人工監督、測試與驗證，像培訓新員工一樣。記錄它的表現，持續協助它調整、改善。

總結

• 傳統自動化 = 要寫程式 → 得依賴外部的IT廠商。
• AI Workflow Automation = 不用寫程式 → 需研究怎麼用prompt、串接流程。
• AI Agent = AI自己研究、應用工具 → 需驗證、提供資料讓AI進步。

駕駛員安全管理

國家為保障運輸業勞工以及用路人的安全，會規範駕駛員必須做好自我管理，包括在發車前要確實做酒測並且紀錄。 目前市面上常見幾種酒測器。

一、一般酒測

這是最普遍的方案，就測器僅將酒測結果顯示於螢幕，不提供輸出介面。司機須將酒測結果抄寫在《安全管理自主檢查表》上，完成紀錄後方可發車。

二、商用酒測

這是進階的方案，適用管理大型的車隊。酒測結果除了酒測器的顯示器外，另外可以透過藍芽、USB等介面讀出，也有透過4G傳輸到雲端管理後台的架構。價格為一般酒測器的十倍以上。

一般酒測的自動化方案

因商用酒測器使用成本高昂，許多業者選擇使用一般酒測器，由駕駛自主登記酒測紀錄。 不過，現在我們所處在的AI時代，可以用什麼方法也能做到自動化紀錄嗎？

文字識別(OCR)軟體

許多業者曾想到請司機把酒測結果拍照下來，再另外使用軟體做文字辨識，但是因拍照的環境干擾因素多，也沒有辦法規範拍照方式，實務上成效不佳。

• 此方案有一定成本費用，實際應用準確度較低。

影像預處理模型

如果企業內已有使用大數據資料模型的應用，則可以將拍照影像預先處理：

1. 影像灰階、去除雜訊、提升圖像的對比度等，降低干擾因素、提升辨識度。
2. 因為酒測器出現在照片中的位置不固定，應用即時物件偵測演算法，訓練出酒測器螢幕偵測模型。
3. 裁切酒測器螢幕(ROI)可能所在的區塊影像，減少噪音、提高準確度。

• 此方案準確度高，但不易維護，需有專職工程師訓練調整模型。但如果企業本身沒有資料或工程團隊，也不用擔心，可使用AI Workflow 平台，就能快速實現酒測紀錄自動化，無需自建模型。

應用AI Workflow讓酒測紀錄自動化

適用於未配置軟體或資料工程師的企業。只需導入如 n8n 等無程式碼自動化平台，便可串接第三方 AI OCR API，自動辨識照片中的酒測數值並完成紀錄與存檔作業。

成本效益

• 某車隊原本使用市售商用酒測器含軟體系統，平均每次檢測的費用約為1至1.2元。
• 導入本公司的方案後，平均每次檢測費用約為0.2至0.21元。節省近八成費用。

歡迎聯絡我們了解更多AI 自動化實作方案

這些場景是否仍持續發生

每天一到通勤尖峰時間，各家長照計程車、復康巴士的客服電話，就開始此起彼落響個不停。通話中傳來的不外是個案家屬焦急地詢問：「司機怎麼還沒到？」、「哪一台車會來接我們？」

客服人員將聽筒緊貼著耳際，但兩眼盯著螢幕卻只能看到客戶訂單，找不到可以回答客戶問題的答案：調度資訊。因為車輛、駕駛的狀況，得詢問調度中心才能得知。

調度人員接到客服打來的詢問電話後，在桌面點開車隊管理系統，在數十上百輛車輛GPS定位點中，找到派車車輛資料，並概略估算了一下路程後，回報給客服。

比較有經驗的客服，如果接到臨時要用車的訂單電話，只能委婉回答：「不好意思，今日派趟已滿 ……」

跨部門協調

首先應該做的，就是各職位的代表，包括客服、調度中心、運輸經理等，大家坐下來，花半小時，把各單位需要的資訊以及管道理清楚。

例如客服手上有訂單資料、客戶資料，但沒有車輛即時的定位資料，必須要打電話給調度查詢。而調度必須進到車隊管理系統查詢。

這個將流程確認清楚的過程，就是正規化。

如果車隊管理系統，並沒有電子化保存，只有紙本單據，則應更進一步先完成資料電子化、持久化。

當企業內部滿足了上述正規化、電子化話條件後，便能著手導入一套軟體：能自動撈取車隊管理系統中保存的電子資料，並透過電話以外的方式(例如：網路)，讓客服可以看到。這一步驟為自動化。

數位轉型

瑞可森的職責，即是從IT角度，協助您一步步順利走過數位轉型的過程。

如何透過智能派車系統提升復康巴士與無障礙計程車調度效率？——自動通知功能大幅減少人工作業！

無障礙計程車與復康巴士業者每天都在處理大量的預約單，從排班、調度到通知乘客，往往需要花費數小時處理。如果有一套系統可以自動排班並直接通知乘客，是否能大幅提升工作效率？

本文介紹如何透過 「自動通知訊息」 功能，協助無障礙交通接送業者減少人工作業時間，並提升整體服務品質！

傳統復康巴士與無障礙計程車調度的痛點

許多無障礙車行和復康巴士業者每天面臨以下問題：

1️⃣ 手動排班耗時：一般業者需要 2 小時來完成排班，且容易因人工錯誤導致調度不佳。
2️⃣ 人工通知效率低：司機、客服人員需要逐一打電話或傳 LINE 訊息通知乘客，平均每天花費 1 小時以上。
3️⃣ 乘客難以查詢行程：乘客如果臨時需要查詢派車狀況，必須再打電話詢問，增加客服負擔。

我們的 SaaS 解決方案——自動排班、自動通知，一次搞定！

我們開發了一款 專為復康巴士與無障礙車行設計的智能派車系統，提供以下功能：

✅ OTP驗證保障資料安全：司機、乘客加入專屬LINE@頻道後，使用OTP認證綁定帳號。 ✅ 自動發送乘車通知：無需人工逐一聯絡，系統會自動將派車資訊傳送給乘客的 LINE 帳號，司機亦可在LINE@頻道自行查詢派趟。
✅ 乘客可在 LINE@ 查詢行程：透過 LINE LIFF 整合，乘客可以直接在 LINE 上查詢最新的派車資訊，無須打電話。

自動通知系統的運作流程

我們的 SaaS 平台如何讓無障礙接送排班變得更簡單？這裡簡單說明：

🔹 步驟 1：乘客加入 LINE@

業者只需提供 專屬的 LINE@ 頻道，讓乘客掃描 QR Code 加入。

🔹 步驟 2：輸入手機號碼驗證身份

乘客加入 LINE@ 後，系統會要求輸入手機號碼，以確認對應的預約單與排班資訊。

🔹 步驟 3：接收 OTP 驗證碼

系統會透過 SMS 簡訊發送 OTP 驗證碼 到乘客手機，確保安全性。

🔹 步驟 4：完成身份驗證，綁定 LINE 帳號

輸入 OTP 後，系統將 乘客的 LINE User ID 與預約資料綁定，未來即可自動發送乘車通知。

🔹 步驟 5：自動發送乘車資訊

當排班完成後，系統會自動將車輛、司機資訊與乘車時間發送至乘客的 LINE@，不再需要人工聯繫！

為什麼無障礙計程車與復康巴士業者需要這套 SaaS 系統？

🔹 使用門檻低：無需自行開發或購買系統，也不需要額外下載安裝APP。 🔹 降低人工成本：客服與調度人員不再需要大量打電話或手動發訊息。
🔹 提升乘客體驗：乘客可隨時透過 LINE 查詢派車資訊，無須來電詢問。
🔹 提升排班準確度：系統透過演算法計算最適合的排班方案，避免人工錯誤。

我們的自動化服務，是最適合的無障礙交通預約調度方案

如果你的派車流程都還人工作業，現在就要升級使用我們的自動化服務！

長照交通接送業者需要在乘客上下車時，司機操作APP回報乘客的上下車時間，這個資料用於每個月的核銷補助申請。但是：

• 多數現場車輛停等規定嚴格，司機當下沒有多餘時間操作APP，等離開現場忙著接送下一趟任務，自然而然就容易忘記回報。
• 到了月底結算要補填寫，也因為時間久遠而只能依記憶填寫，導致調度員無法掌握準確的乘車資訊。

📌 申請補助時，容易遇到時間衝突問題
每月申請補助核銷時，便容易因與其他業者之接送紀錄或照護項目時間存在衝突，而被視為異常案件，影響補助款核銷。

善用GPS 自動判斷客上、客下時間

我們可以善用每台接送車輛都有安裝的GPS車機，利用每30秒發報一次的規律，判斷實際客上、客下時間：

1️⃣ GPS 定位與訂單資料自動比對

• 訂單內的上下車地址，透過Google 地理編碼（Geocoding API）轉換成 GPS 經緯度，與車輛實際定位做比對。
• 系統將 GPS 記錄存入資料庫，確保每趟行程都有完整數據。

2️⃣ 自動判斷乘客的上下車時間

✅ 乘客上車時間
當司機抵達上車地點後，系統會觀察 GPS 訊號：

• 當車輛開始遠離上車地點（超過 100 公尺），系統推測乘客已上車。
• 系統自動發送LINE 提醒給司機，詢問「乘客是否已上車？」
• 司機只需點擊「是」，系統即自動記錄時間。

✅ 乘客下車時間
當車輛接近目的地時，系統會自動偵測：

• 若車輛停在目的地 1 分鐘以上，系統判斷乘客可能已下車。
• 再次發送LINE 提醒，請司機確認「乘客是否已下車？」
• 司機點擊確認後，系統自動記錄時間。
• 如果司機忘了回應，系統會在車輛離開目的地後再次提醒，確保記錄完整。

核銷流程自動化效益

🌟 正規化 → 使用Google 地理編碼整合比對異質之訂單資料與GPS紀錄。 🌟 自動化 → 自動比對挑出會造成退件的異常資料，避免醒想補助款核銷進度。
🌟 更友善 → 使用LINE 訊息提醒，避免干擾，司機不用分心操作而影響行車安全。 🌟 更精準 → 結合Google 地圖、GPS 紀錄不斷訓練預測模型，讓排班調度越來越精準。

無障礙接送服務預約流程：從身份查核到排班安排

無障礙接送服務的預約流程與一般計程車不同，除了提供基本的上下車地點外，還需經過身份查核、乘車用途確認、補助額度計算等多重程序，確保乘客符合搭乘資格及補助條件。以下將為您詳細解析整個預約與派車流程，讓您更了解如何順利完成預約。

身份查核與補助確認

當乘客向車行預約無障礙接送服務時，車行首先會詢問乘客的個人資料，並透過政府平台進行身份查核，以確認是否符合搭乘資格，並計算可使用的交通補助與輔具補助額度。不同的預約身份可能會有額外的程序，請特別留意。

1. 長照補助身份預約

如果乘客使用長照補助身份預約，車行必須經過個案管理師（個管師）的照會程序，待個管師確認後，才能正式完成預約。此外，每位乘客可照會的車行數量依各縣市政府規定而有所不同，因此乘客應先了解當地政策，以免影響預約安排。
如果有申請爬梯輔具補助，則需要乘車時提交相關核可紙本文件，車行才可以代為申請補助。

2. 復康巴士預約

復康巴士的預約流程與一般無障礙計程車不同，車行需登入政府管理平台，確認乘客是否具備無障礙身份，且戶籍必須在當地，才符合搭乘條件。此外，各地方政府可能與車行業者簽訂特定協議，例如：

✅ 限定服務範圍：僅能提供起迄地點皆位於特定區域內的乘客使用。
✅ 特定行駛路線：部分地方政府可能會限制車行只能行駛特定區間，影響乘客的預約彈性。
✅ 不提供爬梯輔具服務：復康巴士僅提供交通接送服務，如有爬梯需求，需另洽爬梯輔具租賃業者。

費用與補助適用條件

無障礙接送的費用結構與一般計程車不同，主要取決於乘車用途與政府補助政策。

✅ 補助適用範圍：長照車行的補助與獎助通常僅適用於醫療目的的接送，例如就醫、復健、洗腎等。如果乘客的需求屬於購物、探親、娛樂等其他用途，則無法獲得補助，須以自費方式支付車資。

✅ 車資計算方式：
車資通常以跳錶計費，車行可根據行車路線提供大致費用估算，讓乘客了解大約的費用範圍。

✅ 額外費用：若乘客的行程涉及以下情況，可能會額外收費：

🚗 偏遠地區加收費用：如目的地位於偏遠地區，需額外加收車資。
🌙 深夜加班接送：特定時段（如深夜、凌晨）可能有額外費用，需與車行確認。

這些額外費用通常會在預約時由車行主動告知，乘客可依自身需求決定是否接受。

訂單成立與排班機制

當車行確認乘客身份、乘車需求、計費方式後，便會成立訂單。然而，這並不代表乘客已經成功排到車，因為無障礙車行並非「先預約先排隊」，而是採用統一排班機制。

🚕 排班時間：車行通常會在乘車日前 1 至 3 日，彙整所有成立的訂單，並進行統一排班。

📢 排班結果通知：
若車輛數量無法滿足所有乘客的需求，車行將會通知部分乘客，告知該時段車輛已排滿，並建議另行安排交通方式。

這種方式可以提高車輛派遣效率，但也意味著乘客可能需要提前準備備案，以免影響行程。

智慧排班：如何讓「回程調度」更有效率？

在無障礙交通車調度的情境中，多數行程的出發時間是確定的，另外有乘客是到醫療院所門診，回程的時間依看診的醫院、科別，要做哪些檢查，都有所不同。 因此回程的時間是不固定的。交通業者多數採取兩種回程排班方式：

1. 由乘客自行預估回程時間
   在實務上殊不可行，也非常容易影響車行後續的調度安排，因此較少業者採行此種方式。
2. 乘客看診結束後通知車行
   此種方式較為靈活，但考驗行控調度人員的判斷能力。

問題：如何安排回程調度派遣？

當乘客通知已經看完診，需要安排車輛前往接送，行控人員需要決定：

1. 哪位司機最適合接這筆訂單？
2. 如何在不影響其他行程的情況下，讓這筆訂單順利插入現有行程？
3. 如果所有司機的行程都滿了，應該讓誰來接這筆單？

如果安排不當，可能會出現以下問題：

• 乘客等待時間過長，影響服務品質。
• 司機的行程安排混亂，導致空車時間過多，影響收益。
• 司機行駛距離過長，造成油耗增加與疲勞駕駛。

動態排班功能：有效應對「回程調度」需求

當乘客通知已經看完診，需要安排車輛前往接送時，系統會自動進行以下步驟：

1. 計算預計行駛時間

   • 從資料庫中調出乘客去程訂單，設定回程之出發地與目的地位置，估算行駛時間。
   • 參考Google地圖路線估算與歷史交通數據，預測當下的車程時長，避免派錯車。

2. 尋找合適的司機

   • 檢查目前正在執行訂單的司機，看看是否有適合的空檔。
   • 若新訂單的上車時間可以順利銜接某位司機的行程，就將訂單派給他。

3. 計算「回程單」是否可安排

   • 若某位司機剛完成一趟行程，且離新乘客不遠，則評估是否可以讓這位司機接這筆新訂單。
   • 計算這樣的安排是否會影響後續行程，若不影響，則優先指派。

4. 分配給最早有空的司機

   • 如果所有司機的行程都無法順利插入新訂單，則挑選下一位最早有空檔的司機來接單。
   • 確保不讓任何訂單被遺漏，並讓整體車輛利用率最佳化。

人工 vs. 程式排班，誰更有效率？

如果派遣調度完全依靠人工處理，當現有行程已經有 50 張訂單，現在要動態排入 1 張臨時訂單，調度員需要花費大量時間計算與評估。

🔴 人工排班的時間成本

• 分析現有行程：調度員需要查閱所有司機的行程，可能需要 3-5 分鐘。
• 評估插單可行性：考慮不同司機的行程安排，推算插單是否影響後續訂單，可能需要 5-10 分鐘。
• 與司機溝通：聯絡司機確認是否能接受新訂單，可能需要 2-3 分鐘。
• 總時間：約 10-18 分鐘 才能完成一次排班調整。

🟢 程式智慧排班的時間成本

• 系統會在數秒內分析現有行程，計算所有可能的插單方式，並自動挑選最優解。
• 最快 1-3 秒內 完成派單，無需人工干預。

📈 節省的時間與效益
假設每天有 20 張臨時訂單需要人工插單，每次人工處理平均需要 5 分鐘，則一天就要花費 100 分鐘（1.5 小時） 來處理排班。如將 「回程調度」 自動化，則100分鐘的工作可以在 1 分鐘內 完成，節省 99% 的時間！

這樣的排班方式有什麼好處？

✔ 減少乘客等待時間：系統能快速決定最適合的司機，不讓乘客久等。
✔ 提升司機收益：透過合理的派單，讓司機的時間安排更緊湊，減少空車時間。
✔ 降低燃油成本：減少不必要的空車行駛，降低油耗與環保負擔。
✔ 提升服務品質：讓乘客獲得更好的乘車體驗，提高滿意度與回頭率。
✔ 降低營運成本：減少人力調度的時間成本，提升公司整體運營效率。