LOTUS: データセットをLLMとエージェントで一括処理するためのsemantic operator入門

LOTUSが埋めるのは「DataFrameとLLMのあいだの実行計画」

LLMを使ったデータ処理は、多くの場合forループで1行ずつプロンプトを投げる形になる。動くが、並列化・バッチ化・失敗時の再試行・コスト管理はすべて自前で書くことになる。LOTUSはこの部分をライブラリ側に引き取る。利用者は「何をしたいか」を自然言語の指示で書き、実行方法はオプティマイザに任せる、という分担である。READMEはこの処理をsemantic operatorと呼び、LLMベースのmap、filter、reduce、joinといったプリミティブとして説明している。対象読者は、データセットや文書コーパスに対してLLM処理を繰り返し適用する必要があり、かつその実行を自分でスケジューリングしたくないエンジニアである。単発のチャットアプリを作る人や、プロンプトを1回投げて終わる用途には不要な抽象化になる。

2種類のsemantic operator: LLM operatorとagentic operator

LOTUSが提供する演算子は2系統に分かれている。1つはLLM operatorで、sem_map、sem_filter、sem_agg、sem_join、sem_extractといった名前がREADMEに挙がっている。行ごとの変換、条件による絞り込み、集約、結合、フィールド抽出を、自然言語の指示で指定する。もう1つはagentic operatorで、corpus.agent(ops=[...])という形でmap、filter、reduceを組み合わせ、ツールを使うエージェントをコーパス上で走らせる。READMEはagentic側の得意分野を「複数ステップとツール呼び出しが効く複雑または曖昧なタスク」と説明し、コードを実行して正確な値を計算する、ファイルを解析する、コードベースを一掃する、といった例を挙げている。判断基準は単純で、答えがLLMの知識だけで出るならLLM operator、外部計算やファイル操作が必要ならagentic operatorである。両者を混ぜるのではなく、タスクの性質で選ぶ設計になっている。

Corpusから結果までのデータフロー

READMEの図が示す流れは、Corpus、宣言的プログラミング、LOTUSオプティマイザ、結果という4段階である。入力はコーパスで、READMEによればインラインの文書、DataFrame、ファイル、あるいは1つの大きなテキストを取る。クイックスタートではlotus.Corpus.from_documents(snippets)で文字列のリストからコーパスを作っている。次に利用者が自然言語のタスクを与え、オプティマイザが実行計画を立てる。READMEが挙げる最適化の内容は、呼び出しのバッチ化、モデルカスケードとプロキシの適用、パイプライン全体の遅延計画である。agentic operatorの場合、コーパスをシャードに分割し、シャードごとにエージェントを並列で起動する。各エージェントはサンドボックス化されたPython REPLを持ち、そこでコードを実行して正確な値を計算できる。最後にシャード単位の所見をreduceして1つの答えにまとめる。この「分割、並列実行、集約」という構造はREADMEの記述から読み取れる範囲であり、オプティマイザが具体的にどのコストモデルで計画を選ぶかは、この資料からは確認できない。

インストールと最小の実行例

パッケージ名はlotus-aiで、pip install lotus-ai、またはuv add lotus-aiで導入する。最新機能が必要な場合はpip install git+https://github.com/lotus-data/lotus.git@mainというソース指定もREADMEに記載されている。実行前にAPIキーを環境変数として設定する必要があり、例ではexport OPENAI_API_KEY=sk-...が示されている。LMの設定はlotus.settings.configure(lm=LM(model="gpt-5", reasoning_effort="low"))という1行で行う。ここでモデル名とreasoning_effortを指定する点は、推論コストをタスクごとに調整する前提だと言える。クイックスタートの例では、意図的にバグを含む4つの短い関数をコーパスにし、agentに「各関数を例入力でテストし、バグのあるものを反例付きで報告せよ」と指示する。ops=["map", "reduce"]、tools=[PythonREPLTool()]を渡し、結果はresult.outputとして取り出す。設定キーは現状lmが中心で、モデルカスケードやプロキシの具体的な設定キーは提示された資料からは確認できない。

エージェントにPython REPLを渡すという設計判断

PythonREPLToolをtoolsに渡すと、エージェントは関数を実際に実行してバグを再現できる。LLMにコードを読ませて推測させるのではなく、実行結果を根拠にさせるという設計である。これは精度の面では合理的だが、副作用のあるコードをサンドボックス外で走らせないという前提が利用者側に残る。READMEはサンドボックス化されたREPLと書いているが、隔離の強度やリソース制限の詳細はこの資料にはない。また、エージェントがツールを呼ぶ回数だけレイテンシとトークン消費が増える。単純な分類タスクにagentic operatorを使うと、LLM operatorより遅く高くつく可能性が高い。逆に、コードの実行結果が正解を決めるタスクでは、LLM operatorでは原理的に届かない精度が出る。ツール呼び出しを許すかどうかは、精度とコストのトレードオフを利用者が明示的に選ぶポイントである。

向かないケースと、既存ツールとの違い

LOTUSが向かないのは、逐次的な対話や、1件ずつ人間が確認しながら進めるワークフローである。バッチ処理を前提とした抽象化なので、リクエストごとに文脈が変わる用途ではオプティマイザの利点が活きない。また、決定論的な変換だけで済む処理にLLMを挟む理由もない。比較対象として挙げられるのはLangChainやLlamaIndexのようなオーケストレーションフレームワークである。これらはチェーンやエージェントの構成要素を組み立てる部品を提供するが、データセット全体の実行計画を最適化する層は薄い。LOTUSは逆で、演算子の種類は絞られている代わりに、バッチ化やカスケードといったデータ処理側の最適化を前面に出す。もう1つの比較軸はpandasである。LOTUSはDataFrame的な操作感を保ちつつ、その中の変換を自然言語で書けるようにしたものだと読める。既存のパイプラインにLLMステップを差し込むのか、LLM前提でデータ処理を書き直すのかで、選択は変わる。

ライセンスとメンテナンスの見え方

ライセンスはApache-2.0で、商用利用や改変、再配布が許容される寛容な条件である。ただし、依存するLMプロバイダの利用規約やデータ送信の扱いは別問題であり、LOTUSのライセンスがそれを覆うわけではない。ここは法務判断ではなく、利用者側で確認すべき項目として挙げておく。メンテナンス面では、提示された情報によればv1.2.2が2026年6月13日、v1.2.3が7月2日、v1.2.4が7月3日と、直近は短い間隔でリリースが続いている。活発に見えるが、これはリリース頻度の事実であって成熟度の証明ではない。APIが動いている前提でコードを書くなら、バージョンを固定してアップグレード時に差分を確認する運用が現実的である。ソースからのインストールを選ぶと常にmainを追うことになる点も、安定性を優先するチームには向かない。

編集部の結論

大量の非構造データやDataFrameに対して、LLMによる分類・抽出・集約を繰り返し実行するチームには向いている。逆に、単発のプロンプト呼び出しや対話型アプリが目的なら、LOTUSを挟む意味は薄い。導入前に確認すべきは、自分の用途がagentic operatorの対象かLLM operatorの対象か、そしてLMプロバイダのレート制限とコストがバッチ処理の規模に耐えるかである。READMEの例は小規模なスニペットで閉じているため、実データでの挙動は手元のコーパスで確かめる必要がある。

公式情報源

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