Elasticsearch Inference API 讓我們直接在 ES 裡運用 OpenAI Completion API
Last updated
Last updated
這二年來出來各式各樣 AI 工具與流程自動化的工具,而我自己也常運用這些工具來拼湊出 AI 的應用流程,但是 Elasticsearch 頂多是當個 vector store,還沒有想過要嘗試在 Elasticsearch ETL 的過程中使用 LLM。(去年曾自己用 ChatGPT 寫了個 Logstash OpenAI filter plugin 來呼叫 OpenAI API,做到這件事,但這也是使用外部的 ETL 工具)
這幾天因應某個專案,ETL 的任務是由 ES 的 Ingest Pipeline 負責,而沒用到 Logstash,讓我發現了 Elasticsearch 8.14 在 Inference API 當中加入的 #Completion 的功能 (使用 #OpenAI Completion API)。
這個功能在 Elasticsearch Release Notes 並沒有被特別強調,所以我一直沒注意到這件事,現在找到之後覺得實在是太方便了,必須在這邊分享一下。
這樣能做到什麼事?
可以在 Elasticsearch API 直接下 prompt 取得 OpenAI 的回覆結果。
可以直接運用在 Ingest Pipeline 當中,也就是你的資料寫入到 Elasticsearch 時,可以先透過 LLM 幫你加工或處理資料,再寫入到 Elasticsearch 當中。
我直接在我的圖片分享我這次做的事:
將一篇新聞文章,寫入到 Elasticsearch 時,在 ETL 透過 GPT4o 進行"摘要"以及"擷取重要關鍵字",並寫入到"summary"與"keywords"的欄位之中。
以下是這次操作 Kibana 的完整步驟:
統整一下使用這個方式的優缺點:
優點:
全在 Elasticsearch 裡做完"運用 LLM 處理 ETL"這件事,Tech stack 的維護成本較低。
可直接運用 Ingest Pipeline 的 error handling 機制,發生錯誤時可寫入到別的 index,並方便重試的處理可再寫回原先的 index 中。
缺點:
Indexing 的整體執行時間被拉長,資料寫入 TPS 較高的服務,可能不適合這樣的運作架構
CoT (Chain of Thought) 或是過於複雜的 Prompt Chaining,若要加工 LLM 回覆的結果,可能導致處理流程太複雜,複雜的流程放在 No Code 工具來做,往往維護成本比寫 code 高非常多。(最近這半年多的深刻體驗。)
對於想在 ETL 當中簡單應用 LLM 的情境,這個功能真的很方便!