ハクソク

世界を動かす技術を、日本語で。

SymbolicAI: LLMに対する神経シンボリックな視点

332日前原文(github.com)

概要

  • SymbolicAI は、PythonとLLM（大規模言語モデル）を融合させた ニューロシンボリックフレームワーク
  • プリミティブ と コントラクト が中核概念で、柔軟な拡張性とカスタマイズ性を備える
  • 構成管理 やAPIキー設定など、実運用に必要な管理機能も充実
  • 多様なエンジン （OpenAI, Anthropic, ローカル, 画像/音声/検索など）を統合利用可能
  • コントラクト により、LLMの出力品質や正確性を保証する仕組みを実装

SymbolicAIとは何か

  • SymbolicAI は、 従来型Pythonプログラミング と LLMの意味的推論能力 を自然に組み合わせるフレームワーク
  • モジュール設計 により、独自エンジンの追加や外部ツール連携（Web検索・画像生成等）が容易
  • プリミティブ（Primitive） と コントラクト（Contract） が主要概念
    • プリミティブ ：シンボル（Symbol）を用いた直感的な操作体系
    • コントラクト ：LLMの出力品質を保証する設計原則

プリミティブ（Primitive）の特徴

  • Symbol は 2種類 ：構文的（Syntactic）・意味的（Semantic）

    • 構文的 ：通常のPython値として振る舞う（デフォルト）
    • 意味的 ：LLMエンジンと連携し、意味や文脈を理解

  • 演算子オーバーロード により、==や&などPython演算子を意味的に拡張

  • .sem/.syn プロパティで 構文⇔意味 の切替が可能

  • ドット記法操作 （例：.map()）実行時に自動で意味的モードへ

  • 複雑なチェーン処理 も単一Symbolで柔軟に実現

    • 例：
      • S = Symbol("Cats are adorable", semantic=True)
      • print("feline" in S) → True（意味的判定）
      • S = Symbol(['apple', 'banana', 'cherry', 'cat', 'dog'])
      • print(S.map('convert all fruits to vegetables')) → ['carrot', 'broccoli', 'spinach', 'cat', 'dog']

  • 主なプリミティブ・演算子一覧

    • ==：等価性判定（構文的＝文字列一致、意味的＝概念的同一）
    • +：加算・合成
    • &：論理積・文脈マージ
    • .choice()：パターンマッチ
    • .cluster()：意味的クラスタリング（sklearn DBSCAN利用）
    • .similarity()：埋め込み類似度計算
    • その他、多数の意味的ヘルパーメソッド

コントラクト（Contract）の仕組み

  • Design by Contract 原則をLLM活用に導入
  • デコレータ を使い、データモデルや検証制約を組み込む
  • Pydantic互換 のデータモデルで構造化・バリデーション
  • リメディ機能 （pre/post-remedy）で入力・出力の自動修正も可能
  • エラー履歴蓄積・リトライ制御 など堅牢な運用設計
  • コントラクト適用クラス （Agent等）は
    • prompt（命令文）、pre/post（検証）、forward（出力）等の高レベル振る舞いを実装
  • LLM出力が制約に違反した場合、自動的に修正またはフォールバック

インストールとセットアップ

  • pipでインストール

    • 基本: pip install symbolicai
    • オプション機能:
      • "symbolicai[wolframalpha]"
      • "symbolicai[whisper]"
      • "symbolicai[selenium]"
      • "symbolicai[serpapi]"
      • "symbolicai[pinecone]"
      • "symbolicai[all]"（全依存一括）

  • APIキー設定

    • OpenAI, Anthropic, ローカルエンジン（llama.cpp/huggingface等）に対応
    • OS・環境ごとに環境変数で設定（Linux/MacOS, Windows, Jupyter）

  • 追加要件

    • 音声認識：ffmpegインストール必須
    • Webクローリング：Chrome + chromedriver-autoinstaller利用

構成管理（Configuration Management）

  • 優先順位付き設定管理システム

    • 3段階（カレントディレクトリ＞Python環境＞ホームディレクトリ）
    • 各レベルに symai.config.json 等の設定ファイルを設置
    • symconfigコマンドで設定状況の確認・初期化

  • 推奨運用

    • デフォルト設定はグローバル（~/.symai/）
    • プロジェクト固有は環境別ディレクトリ
    • 開発・デバッグはカレントディレクトリ

  • 設定例

    • symai.config.jsonで各種エンジンAPIキー・モデル指定
    • SUPPORT_COMMUNITYでデータ収集協力のON/OFF切替
    • SYMAI_WARNINGS=0で警告非表示

テスト実行

  • pytestによるローカルテスト
    • 全テスト：pytest tests
    • 必須テストのみ：pytest -m mandatory

まとめ

  • SymbolicAI は、PythonコードとLLMの意味的推論を融合するための 強力なフレームワーク
  • プリミティブ と コントラクト により、 直感的な記述 と 品質保証 を両立
  • 多様なエンジン ・ 柔軟な構成管理 ・ 自動修復機能 など、実運用に適した機能群
  • APIキー設定や拡張依存の管理 もシンプルで、導入・運用が容易
  • LLM活用の新たな設計パラダイム として、Pythonユーザーに強く推奨

Hackerたちの意見

これが僕をワクワクさせるブードゥーなんだ。面白い例をいくつか見つけたよ： セマンティックマップ

lambdas S = Symbol(['apple', 'banana', 'cherry', 'cat', 'dog'])
print(S.map('convert all fruits to vegetables'))
# => ['carrot', 'broccoli', 'spinach', 'cat', 'dog']

コンテキストによる比較

greeting = Symbol('Hello, good morning!')
similar_greeting = 'Hi there, good day!'
result = greeting.equals(similar_greeting, context='greeting context')
print(result)
# => True

異なるコンテキストでの比較

formal_greeting = Symbol('Good morning, sir.')
casual_greeting = 'Hey, what\'s up?'
politeness_comparison = formal_greeting.equals(casual_greeting, context='politeness level')
print(politeness_comparison)
# => False

ビット演算

horn_rule = Symbol('The horn only sounds on Sundays.', semantic=True)
observation = Symbol('I hear the horn.')
conclusion = horn_rule & observation

interpret()はすごく強力みたいだね。OP、これを作るきっかけは何だったの？どこで使ってるの？今までの一番のお気に入りの使い方は？

└

これはすごく長い答えになりそうだね。面白いのは、2022年末からあまり変わってないってこと。モデルは良くなったけど、gpt-3の頃から基本的な部分は結構揃ってた。最近の新しいところはDbCの貢献だと思う。これがあれば、エージェント関連のことは何でも解決できたよ。特に、契約をチェーンで繋げられるし、ガードレールもちゃんと機能するからね。ほとんどのカスタムツールは自分で作ったよ。例えば、オープンAIのウェブ検索によってパープレキシティが無意味になっただけじゃなくて、オープンAIのウェブ検索自体も、自分でカスタマイズできるものには及ばないんだ。そこで、自分専用の深いリサーチエージェントを作ったんだ。これがその初日からの結果をまとめたスレッドだよ： https://x.com/futurisold/status/1931751644233945216 それから、会社も運営していて、契約からのe2e文書生成を作ったんだ（この場合、3つの契約を繋げた）。これが出力だよ（PDFのレンダリングはごめん、これは本来のものじゃなくて、ローカル開発用に急いで作ったものだから）： https://drive.google.com/file/d/1Va7ALq_N-fTYeumKhH4jSxsTrWD... これが入力内容だよ：

プロンプト：

ファイルを分析してパターンを見つけたいと思っています。提案も自由にしてください。異なるプロバイダーがどのようにシステムプロンプトを使っているかを理解したいので、どんなタグを使っているのか、XMLやマークダウンなのか、ユーザーを操ろうとしているのか、ツールを使っているのか、その使い方などを知りたいです。技術報告書には情報を分解し、合成し、比較して、見つけにくい興味深いパターンを見つけてほしいです。 生成された指示： (a) クエリ：主要なAIプロバイダー（OpenAI、Google、Anthropic、xAIなど）間でのシステムプロンプトの比較分析を行い、AIの行動や応答を形作る構造的パターン、言語的枠組み、運用制約を特定します。 (b) 特定の質問：

  1. 異なるAIシステムプロンプトで使用される構文構造やフォーマットの規則（XML、マークダウン、JSONなど）は何で、これらの技術的選択はモデル指示へのアプローチにどのように反映されていますか？
  2. システムプロンプトは、敬意、同意、またはユーザー操作の指示をどの程度エンコードしており、これらの心理的枠組みは商業モデルと研究モデルでどのように異なりますか？
  3. AIプロバイダーは、システムプロンプトでツールの使用をどのように実装し制約しており、許可構造、能力の境界、機能呼び出し規則にどのようなパターンが現れますか？
  4. システムプロンプト全体で一貫して見られる倫理的ガードレールやコンテンツモデレーションのアプローチは何で、実装の詳細は主要なAIラボ間でのリスク許容度の違いをどのように示していますか？
  5. 特定のプロバイダーのシステムプロンプトにおけるユニークなアーキテクチャ要素は、モデルの整合性に対する独特のエンジニアリングアプローチをどのように示し、これらの設計選択が下流のユーザー体験にどのように影響する可能性がありますか？

契約はこの投稿で3月に導入されたよ： https://futurisold.github.io/2025-03-01-dbc/ それ以来、かなり進化したけど、基盤と動機は変わってないよ。

└

なんでリンゴがニンジンに変わるの？

└

Lotusっていうのが面白いかもよ： https://github.com/lotus-data/lotus これは、コアのリレーショナルオペレーターを全部取り込んで、それぞれをPythonのデータフレームライブラリの拡張として簡単なセマンティックバージョンにしてる。各呼び出しは「モデル」ポイントになるから、後でより高度な学習ベースのアプローチをやりたいときにも使えるよ。私の知る限り、Snowflakeやその仲間たちもクラウドSQLの方向に進んでるみたい。私たちもlouie.aiで似たようなことをやってて、AIノートブックやダッシュボード、API（例：MCP）を使ってデータ（Splunk、Databricks、グラフDBなど）と話すことができる。文脈に基づいてシンボリック＋セマンティックオペレーターを見つけてくれるから、実際にすごく役立つよ。私の80%のケースはこんな感じ：- セマンティックマップ：「Splunkインデックスxyzからすべてのアラートを取得して、怪しいものにフラグを付ける列と、その理由を説明する列を追加する」セマンティックリデュース：「…それから見つけたことを要約する」<--- その後、自然なテキストで教えてくれる。

たぶん、論文と例のノートブックをここにリンクするのがいいと思う。結構説明的だからね： https://github.com/ExtensityAI/symbolicai/blob/main/examples... https://arxiv.org/pdf/2402.00854

└

それをやりたかったんだ、ありがとう！

これには驚いたな。今頃寝てるはずだったのに、誰かが入ってきたらおしゃべりしようかな！ホワイトナイトの経験があってよかった。

これは関数型プログラミングみたいに動いて、すべてのシンボルが純粋な値で、操作がクリーンで追跡可能なフローに組み合わさるんだ。曖昧なステップにぶつかると、モデルが介入する。FPのIOみたいに、生成的な呼び出しはスコープ付きの副作用として扱われる。これによって、推論グラフがデフォルトで決定論的に保たれ、必要なときだけモデルに委ねられる。すごいデモだね、気に入ったよ！

└

そうだね、ほぼその通り。最初から関数型にしたかったんだ。低レベルでも、すべてが関数型（functional.py/core.pyって呼ばれてるし）。デコレーターをあちこちで使ってる。これがリファクタリングやフレームワークの拡張、バグの抑制にすごく役立ったよ。

参考までに、正しさ契約に関する部分に誤りがあるよ：valid_opts = ['A', 'B', 'C'] だけど、vがvalid_sizesに含まれていない場合、valid_sizesが未定義になってる。

└

あ、ありがとう；リファクタリングのアーティファクト。今は修正したよ。

一つ質問なんだけど、OP、これのコストはどうなってるの？自然言語計算を含む行を実行するたびに、LLMの推論コスト（外部APIを使う場合はそのままの意味で）を払うの？例えば、ループ内で「シンボリック」関数を呼び出したらどうなるの？

└

そうですね、その通りです。例えばOpenAIを使う場合、すべてのセマンティック操作はOpenAIへのAPIコールになります。もしローカルのLLMをllama.cppでホスティングしているなら、モデルをホスティングする以外の推論コストは明らかにかからないです。

└

何らかのキャッシュが必要ですね。

最近はコードがLLMによって生成されるから、文脈を持ち、Pythonのオペレーターで操作できるシンボルのような特定の構文が、LLMによって生成された通常のPythonコードと比べてどう役立つのか理解したいんだ。例えば、すべての果物を野菜に変換するためにこの構文を書くこともできるし、単にLLMに果物のリストを受け取って、バックグラウンドで野菜の同等物を返すプログラムを作るように促すこともできる。違いを理解しようとしてるんだけど。

└

幻覚の防止かな。LLMに形式的なシステムを作らせると、一般的なものよりもずっと簡単に検証できるよね。

すごくクールだね。==や+のようなセマンティック（構文的ではなく）オペレーターを使えるのは、新しいアイデアの肥料みたいな感じ。言葉の埋め込みが初めて出たときのように、そこに緩やかな概念代数が導入された感じ（「王 - 男 + 女 = 女王」）。とはいえ、ここでの神経＋シンボリックの統合は、ほとんどのシステムと同じようにかなり浅いし、ファイアウォールがある（分類的には、タイプ3 / 神経;シンボリック — https://harshakokel.com/posts/neurosymbolic-systems）。本当の魔法は、もっと根本的な統合に向かい始めたときに来ると思う。実際、私たちの会社でもこれに取り組んでる（https://onton.com）。ポストLLMシステムをどうやって作るか：1) 統合された表現を持つ（純粋にシンボリックでもなく、密な浮動小数点行列でもない）；2) 小さなノイズの多いデータから段階的に学習できる、壊滅的な忘却にさらされない；3) 数学的およびその他のシンボリック操作を確実に実行できる；4) 幻覚がない？既存のシステムをホットグルーでくっつけるのは確かに便利だけど、統一されたアーキテクチャがすべてを変えると思う。

ちょっと残念なのは、「シンボリックAI」はすでにしっかり定義されてるってことだね： https://en.m.wikipedia.org/wiki/Symbolic_artificial_intellig...

└

わかりました。名前を変更するかもしれません。論文には名前の選び方についての脚注があって、これはこのプロジェクトにインスパイアを与えたニューウェルとサイモンの基礎的な仕事を称えるためのものです。