LOTUS：把 map、filter、reduce 語意運算子疊在資料集上，用 agent 與 LLM 批次處理

LOTUS 要解的是「同一條指令套到很多筆資料」這個重複勞動

多數人第一次用 LLM 處理資料，寫出來的是一圈 for 迴圈：讀一列、組 prompt、呼叫模型、解析輸出、寫回欄位。資料量小的時候這沒問題，一旦變成幾千筆文件、幾萬筆紀錄，迴圈本身不是瓶頸，瓶頸在於每一次呼叫都是獨立且昂貴的，而且你很難在事後說明「為什麼這一批的準確率比上一批低」。LOTUS 的定位就是把這件事從手寫迴圈提升為宣告式操作：你用自然語言說明要對資料做什麼，用 sem_map、sem_filter、sem_agg、sem_join、sem_extract 這類語意運算子表達，剩下的執行細節交給它的 optimizer。README 的用詞是「express what you want over a dataset」，而 optimizer 負責「decides how to run it」，包含 batching、model cascades 與 proxies，以及對整條 pipeline 做 lazy planning。它的目標讀者是手上已經有 DataFrame 或一批文件、想把 LLM 判斷力當成一種資料庫操作來用的人，而不是想自己組 agent framework 的人。專案名稱本身就是縮寫：LLMs Over Text, Unstructured and Structured Data，結構化與非結構化都吃。

資料流：Corpus 進去，optimizer 決定怎麼打模型，結果出來

README 附的架構圖把流程畫成 Corpus 到 Declarative Programming 到 LOTUS Optimizer 再到 Results。拆開來看有兩層。第一層是語意運算子，每個運算子都是「對資料集做一次 LLM 驅動的轉換」，你只給自然語言指令，例如 map 是把每筆資料轉成新欄位、filter 是逐筆判斷留或不留、sem_agg 是把多筆聚合成一個答案、sem_join 是拿語意相似度而不是等值條件把兩份資料接起來。第二層才是 LOTUS 真正想賣的東西：optimizer。它接收你宣告的運算子鏈，決定要不要把多筆請求合併成一次呼叫、要不要先用便宜模型篩一遍再用貴模型處理剩下的（model cascades）、以及整條 pipeline 怎麼排程。這個分工的意義在於，你把「要做什麼」寫死，把「怎麼做才便宜」交給系統。要注意的是 README 只描述了 optimizer 會做這些事，並沒有列出可調參數或策略選擇介面，所以實際上你能控制的多半是運算子與指令本身，而不是最佳化策略。

兩類運算子：LLM 運算子走單步，agentic 運算子走多步加工具

LOTUS 把運算子分成兩類，這個切分比它表面的行銷語言更有資訊量。第一類是 LLM 運算子，也就是 sem_map、sem_filter、sem_agg、sem_join、sem_extract 這一組，本質上是一次模型呼叫對應一次轉換，適合任務邊界清楚、判斷可以在一輪內完成的情況。第二類是 agentic 運算子，透過 corpus.agent(ops=[...]) 呼叫，讓一個會用工具的 agent 跑在語料上，ops 可以組合 map、filter、reduce，並且能掛上工具。README 對兩者的適用場景講得很直白：agentic 運算子「shine on complex or ambiguous tasks that benefit from multiple steps and tool calls」，例如實際執行程式碼算出精確數值、解析檔案、掃過一整個 codebase，或做需要多層判斷的過濾。反過來說，如果你的任務只是「把這段文字分類成三類之一」，走 agent 路徑是浪費，每一步都多一次模型往返。這個二分法是選用 LOTUS 時第一個要做的決定。

安裝與最小可跑範例：從 pip install 到 agent 跑完 reduce

安裝本身沒有懸念，README 給的是 pip install lotus-ai，或用 uv add lotus-ai，要追最新功能則從原始碼裝：pip install git+https://github.com/lotus-data/lotus.git@main。套件名稱是 lotus-ai，import 名稱是 lotus，這點在寫 requirements 時容易搞混。設定模型的方式是 lotus.settings.configure(lm=LM(model="gpt-5", reasoning_effort="low"))，API key 走環境變數，README 舉的是 export OPENAI_API_KEY=sk-...。真正的入口是 Corpus：README 說明語料可以是 inline 文件、DataFrame、檔案，或一整段長文本，範例用的是 lotus.Corpus.from_documents(snippets)。接下來呼叫 corpus.agent，傳入 task 的自然語言描述、ops=["map", "reduce"] 以及 tools=[PythonREPLTool()]，回傳物件取 .output 就是 reduce 之後的結果。README 那個範例刻意選了幾個有微妙錯誤的函式（例如 average 除以 len(nums) - 1、percent 忘了乘 100），要 agent 在沙箱裡實際執行、找出 bug 並給出反例。這個範例之所以有說服力，是因為它示範了 agentic 路徑的核心價值：不是叫模型「看」程式碼猜哪裡錯，而是讓它在 Python REPL 裡跑出來。

PythonREPLTool 是能力也是風險邊界

agentic 路徑的關鍵零件是 tools=[PythonREPLTool()]。README 的描述是每個 shard 的 agent 都帶著一個 sandboxed Python REPL，用途是「exact computation」，也就是把需要精確計算的部分交給程式碼而不是交給模型的算術能力。這個設計直接決定了 agentic 運算子能處理什麼：凡是「跑一下就知道答案」的任務，例如測試函式、統計數值、解析結構化檔案，它都能拿到比純文字推理可靠的結果。但同一件事換個角度看就是風險。README 只寫了 sandboxed，沒有說明沙箱的隔離層級、網路是否可達、檔案系統可見範圍，這些在正式環境是要自己查清楚的。另外，一旦語料裡的文件本身含有惡意內容，而 agent 又會執行程式碼，你就多了一條 prompt injection 到程式碼執行的路徑。這不是 LOTUS 獨有的問題，但它是選用 agentic 運算子時必須自己承擔的部分，README 並沒有在這裡給出防護說明。

什麼情況下 LOTUS 是錯的工具

第一種情況是資料不能離開你的環境。LOTUS 的運算子本質是 LLM 呼叫，README 的範例走的是外部模型 API，若你有法規或合約上的資料落地要求，這條路徑直接不成立，除非你自己接自架模型，而 README 沒有示範這種設定。第二種情況是任務只需要單次問答。語意運算子的價值來自「同一條指令套用到很多筆」，一筆資料的任務用 LOTUS 只是多一層抽象。第三種情況是你需要逐筆可重現的輸出。optimizer 會做 batching、cascades 與 lazy planning，這意味著同一份程式碼在不同資料量或不同模型路由下，實際發出的請求可能不一樣；當你要對單一列的結果做稽核或回放時，這種不透明會變成負擔。第四種情況是任務高度依賴精確的字串比對或數值篩選。sem_filter 是語意判斷，不是 SQL 的 WHERE；能用確定性條件表達的過濾，用 pandas 或 DuckDB 更快也更準。LOTUS 的適用範圍是那些「你講得出規則但寫不成 if-else」的判斷。

替代方案：直接寫 API 迴圈，或走 RAG 框架，差別在控制權

最直接的替代方案不是另一個套件，而是自己寫迴圈加 pandas apply。差別在控制權：自己寫的話，每一次呼叫的 prompt、模型版本、重試策略、並行度、成本都攤在你看得到的地方，除錯是一行一行看。代價是你得自己處理批次合併、快取、失敗重試與成本控制，資料量一大這些工作會反過來吃掉你的時間。LOTUS 換走的正是這部分控制權，換來的是 optimizer 幫你做這些決策。另一類替代是 RAG 框架，但兩者解決的問題不同：RAG 框架關心的是「怎麼從語料檢索出相關段落再生成答案」，LOTUS 關心的是「怎麼對語料每一筆做轉換再聚合」。README 自己把 RAG 列為可建構的應用之一，而不是 LOTUS 的替代品，這個區分是對的。真正要判斷的是：你的瓶頸在檢索品質，還是批次轉換的成本與準確率。前者選 RAG 框架，後者才是 LOTUS 的守備範圍。

維護成本與授權：Apache-2.0，版本節奏偏快

授權是 Apache-2.0，屬於寬鬆授權，允許商業使用與修改，條款細節請自行閱讀 LICENSE 全文，這裡不構成法律意見。維護節奏從 release 紀錄看得出來相當密集：v1.2.2 在 2026-06-13，v1.2.3 在 2026-07-02，v1.2.4 在 2026-07-03，三週內三個版本，而且最新一次 push 與最新 release 只差約二十五分鐘。對採用者來說這是雙面訊號：專案活躍，但小版本之間可能有行為變動。README 也提供了從 main 分支直接安裝的路徑 pip install git+https://github.com/lotus-data/lotus.git@main，方便但等於放棄版本鎖定。實務上建議在 requirements 或 lock 檔裡釘住具體版本號，升級前先跑一遍你自己寫的語意運算子測試，特別是 agentic 路徑，因為它牽涉模型行為與工具執行，比純函式更容易在版本之間產生差異。

編輯結論

如果你的任務是「同一段自然語言指令要套用到成千上百筆資料」，而且你能接受把資料送進外部模型 API，LOTUS 值得先跑一次 pip install lotus-ai，用官方 Colab 或 examples/agentic_map_reduce/codebase_sweep.py 對自己的語料做小規模驗證。相反地，若你只需要單次問答、或資料不能離開自有環境、或工作流程需要嚴格可重現的逐筆輸出，LOTUS 的 optimizer 與 agent 多步執行會讓除錯變得困難，此時直接寫呼叫 API 的迴圈更透明。導入前務必確認三件事：你的模型供應商與 API key 環境變數是否與 lotus.settings.configure(lm=LM(model=...)) 相符；agent 路徑的 tools 是否真的需要 PythonREPLTool（它會執行程式碼）；以及 optimizer 對你的資料量實際上做了哪些批次與串接決策，因為 README 只描述「會做」，沒有給出可調參數清單。

官方來源

1. License: Apache-2.0
2. lotus-data/lotus on GitHub
3. Project website
4. README
5. Releases