掌握 Gemini Batch API 與 Webhook 實現 LINE Bot 餐廳分析助手

作者
  • avatar
    姓名
    Nino
    职业
    Senior Tech Editor

在開發基於大語言模型（LLM）的應用程序時，開發者經常需要處理大量數據分析任務。例如，一次性分析數十家餐廳的評論、對大量文章進行分類，或批量生成翻譯。如果使用傳統的同步 API（實時調用），不僅會面臨嚴苛的頻率限制（Rate Limit），還可能因為網絡連接超時和極高的計算成本而導致項目失敗。

為了克服這些限制，Google 推出了 Gemini Batch API 和 Webhook API。這兩項技術的結合為非緊急性的大數據處理提供了完美的解決方案。通過 n1n.ai 提供的穩定 API 聚合服務，開發者可以更輕鬆地集成這些高級功能，確保企業級應用的穩定運行。 n1n.ai 作為領先的 LLM API 聚合器，支持多種主流模型，是開發者的首選工具。

為什麼選擇 Batch API 與 Webhook？

  1. Gemini Batch API：允許開發者將大量請求打包成一個 JSONL 文件並一次性上傳。Gemini 會在後台進行異步調度計算，不佔用每日的實時 API 配額，且計算成本通常僅為實時 API 的一半。這對於預算有限但數據量巨大的項目來說至關重要。
  2. Webhook API：傳統的 Batch 任務需要本地不斷編寫輪詢（Polling）邏輯來檢查狀態。有了 Webhook，當 Gemini 完成 Batch 計算後，會主動向你指定的 URL 發送 HTTP POST 回調，瞬間通知任務完成，使系統架構更加優雅且節省資源。

實戰案例：LINE Bot 餐廳分析助手

我們將這些強大的 API 集成到了 LINE Bot 餐廳分析助手中，實現了在移動端一鍵進行深度評論與招牌菜色的大數據分析。用戶只需發送位置，Bot 就能自動提取附近熱門餐廳並提供深度分析報告。

系統架構圖

graph TD
    A[用戶發送位置] -->|位置訊息| B[Google Maps Grounding 搜尋]
    B -->|純文本餐廳列表| C[Gemini-1.5-Flash 提取前三名餐廳]
    C -->|動態生成快速回覆| D[LINE Bot 回覆 3 個自定義分析按鈕]
    D -->|用戶點擊特定分析| E[FastAPI 後台任務]
    E -->|立即回覆 ACK| F[LINE 聊天訊息]
    E -->|打包 JSONL 並上傳| G[Gemini Batch API 提交]
    G -->|計算完成 Webhook 回調| H[主動推送深度報告給用戶]

技術實現深度解析

1. 使用 Gemini 進行結構化數據提取

在搜尋到餐廳列表後，我們需要精確提取餐廳名稱以生成按鈕。利用 Gemini 的結構化輸出能力，我們可以確保返回的是標準的 JSON 格式：

# 提取前三個餐廳名稱用於 Quick Reply
names = []
if place_type == "restaurant":
    try:
        extract_prompt = f"請從以下文本中提取所有餐廳名稱，並以 JSON 數組格式返回（例如 [\"餐廳 A\", \"餐廳 B\"]）。請直接輸出 JSON 數組，不要包含任何 markdown 標籤或解釋性文字。\n\n{result}"
        extract_res = client.models.generate_content(
            model="gemini-1.5-flash",
            contents=extract_prompt
        )
        extract_text = extract_res.text.strip() if extract_res.text else ""
        # 解析邏輯...
        names = json.loads(extract_text)
    except Exception as e:
        logger.error(f"提取失敗: {e}")

2. 處理 LINE API 的字符限制

在實作動態 Quick Reply 時，我們遇到了一個關鍵限制：LINE API 的按鈕標籤（Label）長度不能超過 20 個字符。如果餐廳名字太長，會導致 400 錯誤。我們設計了動態截斷機制：

  • 原始餐廳名稱超過 10 個字時，強制截取前 9 個字並加上「...」。
  • 加上「🍴 分析」前綴後，總長度控制在 15 字以內，確保安全。

3. FastAPI 異步任務調度與超時處理

LINE Webhook 要求服務器在 3 秒內返回 HTTP 200。然而，收集評論、上傳 JSONL 並提交 Batch 任務通常需要 3-8 秒。為此，我們採用了異步處理架構：

  • 快速響應：當 Bot 接收到分析請求時，立即調用 reply_message 回覆用戶「正在處理中...」，並瞬間返回 HTTP 200。
  • 後台執行：使用 Python 的 asyncio.create_task 將繁重的網絡搜尋與 Batch 提交任務交給 FastAPI 的背景 Worker 執行。
  • 主動推送：當 Webhook 收到任務完成通知後，再使用 LINE 的 push_message 將報告發送給用戶。

Batch API 的優化建議

在開發過程中，我們發現 Batch 任務有時會卡在 JOB_STATE_PENDING 狀態。這是因為 Batch 任務需要排隊等待 Google 的服務器資源。我們的優化策略包括：

  1. 最小化工作負載：將批量分析的餐廳數量減少到 1，縮減 JSONL 的請求行數，以加快調度速度。
  2. 防重複點擊機制：在用戶點擊分析時，首先檢查該用戶是否有正在運行的 Batch Job。如果有，則回覆「您的分析任務正在運行中，請耐心等待」，避免重複提交造成的資源浪費。
  3. 多模型備選：通過 n1n.ai 的管理界面，你可以輕鬆切換不同的模型（如從 Gemini 切換到 DeepSeek 或 Claude），以應對特定型號的 API 波動。

總結

通過優化 Quick Reply 和 Gemini Batch API 的集成，我們的餐廳分析助手在移動端實現了極佳的用戶體驗。這套架構不僅解決了 Webhook 超時和 API 頻率限制的問題，還大幅降低了運營成本。對於希望構建低延遲、高穩定性大數據分析工具的開發者來說，這是一個非常值得借鑑的方案。

欲了解更多關於高性能 LLM API 的應用，請訪問 n1n.ai。

Get a free API key at n1n.ai

参考来源：https://dev.to/evanlin/gemini-api-hands-on-6im