排解最佳化函式問題

在 AlloyDB for PostgreSQL 執行最佳化 AI 函式時，如要解決模型訓練、查詢準備和效能倒退問題，請套用建議的修正措施，解決查詢傳回的警告或錯誤。

預期效能會降低。無法使用最佳化 AI 函式

說明

這項警告表示查詢已改用 LLM。如果最佳化函式仍在訓練、未準備就緒、未通過執行階段準確度驗證檢查，或 ai.if() 函式參照的內容和嵌入欄不屬於同一個資料表，就會發生這種情況。如果是較小的資料表，代理模型可能無法妥善一般化，且準確率通常低於 95%，因此 AlloyDB 預設會使用 LLM。

導致錯誤的查詢範例

EXECUTE positive_reviews_query;
  • 等待最佳化函式訓練完成。
  • 請確認查詢已使用 PREPARE 陳述式正確準備。
  • 確認 ai.if() 函式參照的內容和嵌入資料欄屬於同一個資料表。
  • 最佳化函式 (預先發布版) 較適合大型資料表。你也可以使用陣列式 AI 函式提升效能。

  • 如要略過執行階段準確度檢查 (例如在開發環境中)，請將整個資料庫環境的 google_ml_integration.runtime_accuracy_check 設為 off。

    ALTER DATABASE DATABASE_NAME SET google_ml_integration.runtime_accuracy_check = off;

    將 DATABASE_NAME 替換為資料庫名稱。

查詢未處理任何資料列，或模型準備失敗

說明

如果查詢未處理任何資料列，主要原因可能是未生成嵌入，或整個嵌入資料欄含有 NULL 值。這會導致查詢準備失敗，因為系統不會對任何含有 NULL 嵌入的資料列進行取樣。

  • 使用最佳化函式前，請先為資料生成嵌入項目。
  • 請確認嵌入資料欄不含 NULL 值。
  • 如果查詢僅在 WHERE 子句中的常數值有所不同，可能仍會使用現有的訓練模型。

即使使用最佳化 AI 函式，效能仍不佳

說明

請確認您未超出 Gemini Enterprise Agent Platform 配額。即使 AI 函式經過最佳化，初始執行階段準確度檢查仍需呼叫遠端 LLM，才能取得資料列樣本。如果配額不足，這項初始檢查可能會變慢或失敗。

請檢查 Agent Platform 配額，並視需要要求提高配額，確保初始執行階段準確度檢查能順利進行，不會延遲。

ERROR: function ai.if(prompt => text, embedding => vector) does not exist

說明

呼叫 ai.if() 函式時，如果一併傳遞 model_id 參數和嵌入資料欄，AlloyDB 不會使用訓練過的 Proxy 模型，並會產生類似下列的錯誤：

testdb=# select ai.if('Is the rating positive?' || review, review_embedding, 'gemini-2.5-pro') from restaurant_reviews;
ERROR:  function ai.if(text, vector, unknown) does not exist
LINE 1: select ai.if('Is the rating positive?' || review, review_embe...
               ^
HINT:  No function matches the given name and argument types. You might need to add explicit type casts.

呼叫 ai.if() 函式時，請確認您未傳遞 model_id 值。這可確保 AlloyDB 使用訓練過的 Proxy 模型處理查詢。