SymbolicAI: LLMに対するニューロシンボリックな視点
(github.com/ExtensityAI)- SymbolicAIはニューロシンボリック・プログラミングフレームワークであり、PythonプログラミングとLLMを自然に結び付ける
- 基本単位であるSymbolオブジェクトを通じて、構文的(syntactic)および意味的(semantic)な操作の両方をサポートする
- Contracts機能は、LLMの予測にデータ妥当性検査と自動修正ロジックを適用し、信頼性と堅牢性を保証する
- さまざまな外部エンジン(OpenAI、Anthropic、huggingfaceなど)、Web検索、画像生成、音声処理との連携運用が可能
- 優先順位に基づく構成管理システムと強力なカスタマイズ機能が特徴
SymbolicAI: プロジェクト概要と重要性
- SymbolicAIは、古典的なPythonプログラミングと差別化された、プログラマブルなLLM(大規模言語モデル)の結合を自然に支援するニューロシンボリック(Neuro-Symbolic)ライブラリである
- モジュラー設計により、容易に拡張、エンジンの切り替え、ツール連携が可能
- Localエンジン、Web検索、画像生成など多様なツールと連携でき、実験的用途にも実用的用途にも適している
主要コンセプト紹介
Primitives
-
Primitivesは基本構成単位であり、中心となるのは
Symbolオブジェクトである -
Symbolオブジェクトは**構文的(syntactic)モードと意味的(semantic)**モードの両方をサポートする- 構文的(syntactic): 通常のPython値のように動作し、比較や演算など安全で高速な動作を実装
- 意味的(semantic): ニューロシンボリックエンジンに接続され、意味と文脈を理解し、柔軟な意味比較や操作が可能
-
構文モードがデフォルトであり、エンジン動作が必要な場合にのみ意味的処理へ切り替えられる
意味的/構文的モードの切り替え方法
- 生成時にsemantic=Trueオプションを指定
.sem(semantic)、.syn(syntactic)属性で自由に切り替え- 意味的関数呼び出し(mapなど)時に自動で意味モードへ変換
演算例
==: 構文的ではリテラル比較、意味的では意味論的同等性(例: 'Hi' == 'Hello' が True)+,&,.startswith(),.choice(),.foreach(),.cluster(),.similarity()など- 複合的な意味ベースの操作と論理的チェイニングが可能
Contracts
- LLMの不確実性を補うDesign by Contract原則を導入
- データモデルと妥当性検査ルールをデコレータで指定
- 不正な入力/出力に対して自動エラー修正、再試行、履歴蓄積など多様な安定性機能をサポート
- Pydanticのデータモデル互換、フィールド検証、自動プロンプト生成、エラー処理などを内蔵
契約(Contract)機能の主な特徴
- pre_remedy/post_remedy: 入力/出力エラーの自動修正
- accumulate_errors: エラー履歴を入力
- remedy_retry_params: 再試行制御パラメータ(試行回数、遅延、バックオフなど)を指定
詳細な例や追加説明は公式ドキュメントおよびDeepWikiページを参照可能
外部エンジンと機能拡張性
- 現在、OpenAI、Anthropicなど多様なニューロシンボリックエンジンをサポート(API/ローカル)
- {huggingface, llama.cpp} など独自エンジンのローカル実行が可能
- 音声、画像、Web検索など追加エンジンとの連携が可能(別途依存パッケージのインストールが必要)
- 検索、クラスタリング、OCR、インデクシングなど実践的なML/AI機能を統合的に提供
構成(Configuration)管理システム
優先順位ベースの構成ファイル管理
-
デバッグモード(プロジェクトフォルダ): 開発・テスト用
-
Python環境別設定({python_env}/.symai/)
-
グローバル設定(~/.symai/): 基本/バックアップ用
-
3つの場所で、優先順位の高い項目を自動適用
主な構成ファイル
- symai.config.json: SymbolicAIの主要オプションを管理
- symsh.config.json、symserver.config.json: シェル、サーバー用設定
構成ファイル例
- API Key、モデル名、エンジン種類などを明示的に指定
- SUPPORT_COMMUNITYオプションでデータ収集への同意(研究および品質向上目的)
- ユーザー警告は
SYMAI_WARNINGS環境変数でオン/オフを制御可能
環境設定とテスト
- ffmpeg(音声)、chromedriver(Webクローラー)など外部パッケージが必要
- テスト実行は
pytest、カバレッジ確認もサポート
参考資料と活用ガイド
- DeepWikiと公式GitBookで豊富な参考資料と動画チュートリアルを提供
- Arxiv公開論文で理論とフレームワークの詳細を説明
- BSD-3-Clauseライセンスを適用
結論
- SymbolicAIは、記号システムの明確性とニューラルネットワークの柔軟性を組み合わせ、LLMベースの信頼性重視サービスおよび実験的研究に非常に適したフレームワークである
- 構成、拡張性、信頼性確保に焦点を当てた設計により、スタートアップやIT実務者に多様な応用可能性を提供する
開発者とコミュニティ支援
- コントリビューション用リソース、連絡先、サポートチャネル(メール、Webサイト、Discord)を積極的に公開
1件のコメント
Hacker Newsのコメント
こういうブードゥー魔術みたいなものは本当に興味深い。
面白いと思った例としては、意味論的な
map lambdaの利用がある。たとえば Symbol のリスト
Sがあるとして、S.map('すべての果物を野菜に変換')を呼ぶと、果物だけが野菜に変わり、それ以外はそのまま維持される。また、文脈に応じて parameter を受け取って比較することもできる。たとえば挨拶の文脈で
Hello, good morning!とHi there, good day!が同じ意味かどうかを判定したり、あるいは丁寧さのレベルとしてGood morning, sir.とHey, what’s up?を比較したりできる。さらに、ビット演算子のように意味論的な論理結合も可能。箇条書きのように規則と観察を
&で結合して結論を導ける。interpret()関数は強力そうに見える。OPに、このプロジェクトに着想を与えたもの、実際に適用した分野、そしていちばん好きなユースケースが何か聞いてみたい
Lotus という python dataframeライブラリ をおすすめしたい。
すべての主要な関係演算を、簡単に意味論的に拡張して使える。
各呼び出しが「モデル」ポイントになるので、後から機械学習方面へ拡張するのも容易。
snowflake のようなクラウド SQL も、だんだんこういう方向へ進んでいる感じがする。
louie.ai では似たシステムを実装している。AI notebook、dashboard、API を通じて、(splunk、databricks、グラフDB などの) データを対話的に扱い、文脈ベースで symbolic + semantic operator を自動判別する。
実務で本当に役立つ。
私の主な use case は次の通り:
semantic map で splunk インデックスから警告を取得して怪しいものにフラグを付け、説明欄も追加し、
それを semantic reduce で要約して自然言語のレポートまで作ること
なぜニンジンがリンゴの野菜変換結果になるのか、という質問
答えようとするととても長くなる話。
プロジェクトは 2022 年末から始まっていたが、最近はモデルが良くなっただけで、基礎的な部分はすでに GPT-3 時代からあった。
最近登場した DbC(Design by Contract) は本当にユニーク。
エージェント関連で自分が経験してきたすべての問題を解決してくれる。特に複数の contract をチェーン接続すると、guardrail が自然に伝播して効果的。
ほぼすべてのカスタムツールを自作している。
たとえば OpenAI の web search は良いがカスタマイズ性が足りないので、自分専用の deep research agent を開発して活用中。
初日の成果物のスレッド
会社を経営していて、contract 3 つをつないで e2e の文書生成自動化も構築した。
デモPDF 参照。
入力プロンプトは、
「ファイル内のパターン分析、さまざまなプロンプト形式(XML、markdown など)、追従傾向、ツール使用方式、倫理的ガードレール、アーキテクチャ上の特異点などを全体比較してレポートを生成せよ」という要求。
contract は 2025 年 3 月の この投稿 で紹介し、その後かなり進化したが、基本的な趣旨と動機は同じ
意味論的な
==や+のような演算子を使えるというのは、新鮮なアイデアに肥料を与えるような感じがする。単語埋め込みが出始めた初期に
King - Man + Woman = Queenのような概念代数に初めて触れたときと同じ興奮がある。ただし、ここでのニューラルネットと記号(logic)の統合は、たいていのシステムと同じく、まだ浅いか分離されたまま。
参考
本当の革新は、今後もっと根本的な統合が実現したときに可能になるはず。
うちの会社(Onton)でも、それを目指して研究している。
目標は 1) 完全に統合された表現(シンボリックでもディープラーニングでもない)、2) ノイズの多い少量データでも継続学習(忘却なし)、3) 数学・記号演算の信頼性 100%、4) 幻覚(hallucination)ゼロ。
今はホットグルー式に複数システムをつなぎ合わせるのも有用だが、統合型アーキテクチャが状況を一変させると思う
説明と例がよくまとまっている 公式コードノートブック と 公式論文PDF のリンクを共有
コード内のエラー報告(
correctness contractsでvalid_sizesが定義されていない)この話題について意見をくれて、応援してくれた皆さんに感謝。
こんな反応は予想していなかったし、いつでもメールやツイートで連絡してもらって大丈夫。
皆さんと話せて本当に楽しかった
残念な点がある。
Symbolic AIという用語そのものは、すでにきちんと 定義されている近いうちに名前を変えるかもしれない。
論文にも命名理由を脚注で入れていて、基礎研究を牽引した Newell と Simon への敬意を込めてプロジェクト名を付けた
気になる点がある。
コスト体系はどうなっているのか。
自然言語演算を含む 1 行を実行するたびに(外部 API を使うならなおさら)、LLM 推論コストを継続的に払う構造なのか。
たとえば
symbolic関数がループの中で繰り返し呼ばれる場合もそうなのかその通り。
たとえば openai API を使う場合、意味論的演算ごとに openai 呼び出しが発生してコストがかかる。
llama.cpp などでローカル LLM を自前ホスティングすれば、ホスティング費用だけで追加の推論コストはない
たしかにキャッシュのようなものは必須になりそう
こんなに人気が出るとは思っていなかったので少し驚いている。
本来なら寝ているはずだったのに、今は睡眠不足の経験値を活かして会話に参加し続けている
関数型プログラミング(FP)のように、すべての Symbol は純粋な値として振る舞う。
演算はクリーンで追跡可能なフローとして合成される。
曖昧な段階ではモデルが介入する。
FP の IO 演算のように、生成モデル呼び出しはスコープ内の副作用として扱われる。
普段は reasoning グラフが決定的で、必要なときだけモデルに委ねる。
デモは本当にすごい
最初から関数型として設計した。
ローレベルでもすべて関数型原則に基づいていて、内部的にも
functional.pyやcore.pyと呼んでいる。デコレータも至るところで使っているので、リファクタリング、拡張、バグ管理などに大いに役立っている
最近は LLM がコードを丸ごと作ることもあるが、
Symbol のように文脈を保持しつつ python operator で簡単に操作できる構造には、
人がいちいち確認しながらコードを書くのに比べてどんな強みがあるのか気になる。
たとえば意味論的変換をああいう文法で直接書くこともできるが、単に LLM に果物のリストを野菜に変換するプログラムを作ってくれとプロンプトしてもいいのではないか。
本質的な違いが何なのか理解したい
LLM にフォーマルシステムを生成させれば、汎用システムよりはるかに検証しやすい