RAG 聊天機器人用 LLM API

正式應用中的 RAG 聊天機器人

內部政策助理依人事手冊與各地補充規定回答問題。 先檢索資料，再呼叫模型。 每段資料保留文件 ID、章節、生效日期與存取權限標記。

Gemini 2.5 Pro 只接收選定段落，且必須引用所用段落 ID。 各地政策不一致時，回答應指出衝突，不可默默選擇其中一個。

RAG 聊天機器人流程如何運作

• 檢索前先確認使用者權限。
• 檢索並重新排序段落，保留文件中繼資料。
• 傳送足以回答的最小證據集。
• 要求每句附段落 ID。
• 核對引用是否支持說法，證據不足時不回答。

透過 LLMFly AI 呼叫 gemini-2.5-pro

從伺服器送出請求，將範例內容與預留工具格式換成應用的資料與工具。

curl https://app.llmfly.ai/v1/chat/completions \
  -H "Authorization: Bearer $LLMFLY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemini-2.5-pro",
    "messages": [
      {"role": "system", "content": "Answer only from the supplied passages. Cite passage IDs after each material sentence. If passages are missing or conflicting, state that explicitly."},
      {"role": "user", "content": "Can a Shanghai employee carry unused leave into next year? Use the supplied policy passages."}
    ]
  }'

為什麼以 gemini-2.5-pro 為主要模型

長篇證據與跨文件整理，優先使用 Gemini 2.5 Pro。

資料檢索完整的簡短回答，使用 Gemini 2.5 Flash。 先確認檢索品質，再將不明確的政策整合交給 Terra。

RAG 聊天機器人驗收檢查

部署前要處理的失敗

• 把檢索漏失怪到模型頭上
• 把所有文件塞進上下文
• 顯示不相關引用
• 沒有證據仍強迫回答

回傳輸出與執行紀錄

每個重要說法後附資料段落 ID，或明確說明證據不足。

每次正式執行記錄模型 ID、請求 ID、token 用量、重試、驗證結果與最終處理。