情境
正式應用中的文件分析
法務團隊比較主服務合約、安全附約與價格表。 解析器保留頁碼、標題、表格與註腳。 模型接收選定章節，產出逐條差異報告。
每個差異都須引用確切文件與頁碼。 呼叫模型前先確認 OCR 品質；掃描不佳就重新處理，不要求模型猜測。
正式環境場景
文件分析用 LLM API
法務團隊比較主服務合約、安全附約與價格表。 解析器保留頁碼、標題、表格與註腳。 模型接收選定章節，產出逐條差異報告。
正式環境實作
API、主要模型與備援設定
| 正式環境選擇 | 建議 | 原因 |
|---|---|---|
| API | POST /v1/chat/completions | OpenAI 相容伺服器端請求 |
| 主要模型 | gemini-2.5-pro | 大型混合文件集與跨文件比較，優先使用 Gemini 2.5 Pro。 |
| 備援模型 | gpt-5.6-terra | 已縮減至相關章節的純文字文件，使用 Terra。 只將未解決的高風險條款交給 Sol 或法律顧問。 |
| 升級模型 | gpt-5.6-sol | 只在主要路徑未達品質或複雜度門檻時使用 |
| 輸出規則 | 通過驗證的 JSON | 回傳逐條差異表，每列都附文件與頁碼引用。 |
架構
文件分析流程如何運作
- 解析文件並保留頁碼與結構參照。
- 選取與審查問題相關的條款。
- 要求格式一致的差異表。
- 逐一核對引用與原文段落。
- 資料缺失、衝突或 OCR 品質低時，轉交審查。
API 請求
透過 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": "Compare the supplied contract sections. Return a deviation table with issue, baseline clause, changed clause, risk, document ID, and page. Never infer missing text."},
{"role": "user", "content": "Compare liability, security, renewal, and pricing terms across these documents."}
],
"response_format": {"type": "json_object"}
}'模型選擇
為什麼以 gemini-2.5-pro 為主要模型
大型混合文件集與跨文件比較，優先使用 Gemini 2.5 Pro。
已縮減至相關章節的純文字文件，使用 Terra。 只將未解決的高風險條款交給 Sol 或法律顧問。
驗收
文件分析驗收檢查
| 指標 | 通過條件 |
|---|---|
| 證據準確度 | 每個重要回答都指向正確頁碼、章節、表格或註腳 |
| 跨章節召回率 | 跨章節問題包含所有必要支持段落 |
| 表格與註腳處理 | 解析後正確保留表格與註腳的數值和限制條件 |
| 每份文件成本 | 解析、檢索、生成與驗證總成本符合每份文件預算 |
失敗處理
部署前要處理的失敗
- 以為長上下文就不必檢索
- 遺失頁碼參照
- 為流暢卻無據的摘要給高分
- 忽略格式損壞的頁面
輸出
回傳輸出與執行紀錄
回傳逐條差異表，每列都附文件與頁碼引用。
每次正式執行記錄模型 ID、請求 ID、token 用量、重試、驗證結果與最終處理。
常見問題
整份文件應放進一個提示詞嗎？
只有已測試的路徑、任務、延遲與成本都允許時才適合；檢索通常仍有幫助。
如何稽核回答？
保留頁碼識別，要求重要回答指向支持段落。
掃描 PDF 應如何處理？
評估語言模型前，先單獨評估 OCR 品質。
用自己的輸入測試設定
以相同請求、工具與驗證規則比較主要和備援模型。