Tag: Rag

エキスパートシステムから生成AIエコシステムへ

エキスパートシステムから生成AIエコシステムへ

古典的なエキスパートシステムは、主に知識ベースと推論エンジンによって、専門家の判断をルール化して扱う仕組みだった。

現在の生成AIでは「エキスパートシステム」という名前はあまり使われない(技術的な連続性も乏しいと思います)。 しかし、その構成要素は RAG、tool calling、agent runtime、guardrails、policy engine、workflow engine、observability などに分解されて生き残っている。

現代的には、次のように捉えると分かりやすかった。

LLM が曖昧な自然言語理解、分類、計画、候補生成を担い、 RAG が外部知識を与え、 tool calling が外部手続きを実行し、 guardrails / policy engine / schema validation / approval gate が決定性と安全性を補う構成。

古典的構成との対応

古典的エキスパートシステムの要素現代の生成AI周辺で近いもの役割
Knowledge BaseRAG、Vector DB、全文検索、Knowledge Graph、ドキュメント indexLLM 本体にない外部知識を検索し、質問に応じて関連 context として渡す
Rule BaseGuardrails、Policy-as-Code、OPA/Rego、JSON Schema、Business Rule Engine「この条件なら許可/拒否」「この形式以外は不可」「このトピックは禁止」などの明示ルールを担う
Inference EngineAgent runtime、agent harness、planner-executorLLM が tool 選択や次の行動を判断し、外側の実行基盤がループを管理する
Forward ChainingEvent-driven automation、監視 alert pipeline、SOAR、workflow engine事実やイベントを起点に次の処理を発火する。例: ログ異常、分類、runbook 検索、ticket 作成
Backward ChainingQuery planning、RAG query decomposition、multi-step retrieval目標から逆算して、必要な情報、検索、tool call を決める
Working MemoryConversation state、agent state、scratchpad、checkpointer現在の事実、途中結果、tool 結果、会話履歴を保持する
Explanation FacilityTrace、citation、observability、eval、provenance判断過程、参照元、tool 実行履歴を後から検証できるようにする
Knowledge AcquisitionDocument ingestion、connector、crawler、MCP resource、schema extraction専門家の知識、ドキュメント、API、GitHub、Slack、チケットなどを取り込む
External Procedure CallTool calling、function calling、MCP toolsLLM の判断を外部 API、CLI、DB、Kubernetes、GitHub などの操作へ接続する
Input / Output ValidatorStructured Outputs、JSON Schema、Pydantic/Zod validationLLM 出力を自由文ではなく、機械処理しやすい schema 準拠データにする
Safety / Compliance LayerGuardrails、moderation、PII filter、topic control、approval gate危険操作、情報漏洩、不適切出力、権限逸脱を防ぐ
User Questioning / InterviewElicitation、フォーム補完、human-in-the-loop approval不足情報を人間に確認し、重要操作では承認を挟む

古典的な仕組みとの違い

古典的エキスパートシステムでは、推論の中心は if X then Y のような明示ルールだった。

Read more...