Skip to main content
Glama
deenesjakoruzh
hailampy123

solid-knowledge-ai

by hailampy123
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

Solid Knowledge AI

マルチソースのドキュメント知識アシスタントで、自己反省型のLangGraphエージェントによって駆動されます。PDF + Markdown + Webページを1つのベクターストアに取り込み、自身の検索結果を評価し、回答が根拠に基づいているかを検証するエージェントを通じて質問に回答します。いずれかのチェックが失敗した場合は、書き換えたクエリで再試行し、回答を根拠付けできない場合は捏造を拒否します。Langfuseでトレースされ、DeepEvalで品質テストされ、MCP経由で公開されます。

エージェンティック開発を紹介するために構築されました: LangGraph · LiteLLM · ChromaDB · MCP · Langfuse · DeepEval。

なぜこれが「単なるRAG」ではないのか

このエージェントは修正型 / 自己反省型RAGループであり、線形のretrieve → generateチェーンではありません:

question
   │
   ▼
 route ──chitchat/out_of_scope──▶ generate ──▶ END
   │ kb
   ▼
retrieve ──▶ grade_docs ──irrelevant (rewrite query, retry)──▶ retrieve
                 │ relevant
                 ▼
             generate ──▶ self_check ──ungrounded (retry)──▶ retrieve
                              │ grounded / budget spent
                              ▼
                     answer + citations  (or an honest "I don't know")

  • route — 雑談や範囲外の質問では検索をスキップします。

  • grade_docs — LLMによる関連性ゲート。失敗した場合はクエリを書き換えて再試行します。

  • self_check — 下書きした回答が取得したコンテキストによって含意されているかを検証します。 そうでない場合は、幻覚を起こす代わりに再試行するか、曖昧な回答にします。

  • 共有の再試行予算（max_retries、デフォルト2）が両方のループを制限します。

  • Memory — SQLiteチェックポインターがthread_idごとにマルチターン会話状態を保持します。

Related MCP server: pdf-analyzer

クイックスタート

# 1. Install (Python 3.11+, uv)
uv sync

# 2. Configure — only ANTHROPIC_API_KEY is required
cp .env.example .env      # then edit .env

# 3. Ingest the sample corpus (2 Markdown + 1 PDF + 1 Wikipedia article)
uv run skai ingest        # -> builds ./.chroma  (local MiniLM embeddings, no API)

# 4. Ask (defaults to Haiku 4.5; switch per-call with --model)
uv run skai ask "What do orcas eat?"
uv run skai ask "How do orcas communicate?" --source md
uv run skai ask "Summarize orca threats" --model sonnet   # haiku | sonnet (Opus blocked)

# 5. Multi-turn chat (remembers the conversation)
uv run skai chat

# 6. Web UI (chat + feedback + live data ingestion)
uv run skai ui        # http://localhost:7860

# 7. Serve over MCP (stdio) for Claude Desktop / an IDE
uv run skai mcp

Web UI

skai uiは、ライブデモに必要な機能を備えたGradioアプリを起動します:

  • Chat — セッションごとのメモリ付き。各回答にはソース、ルート、モデルが表示されます。

  • すべての応答後のフィードバック — 👍/👎 + 任意のコメント。SQLite （.skai/feedback.sqlite）に保存され、トレースが有効な場合はそのターンのトレースに対するLangfuseスコアとしても プッシュされます。これがクローズドループです: 実際の使用が評価シグナルになります。

  • 最初の対話をガイドするサンプルプロンプト。

  • ナレッジベースをライブで拡張 — .md/.txt/.pdfをアップロードするか、URLを貼り付けると、その場で Chromaに取り込まれます。デモはシードコーパスに限定されません。

  • モデル（haiku/sonnet）とソースフィルター（all/pdf/md/web）のセレクター。

フィードバックはskai.feedback.export_jsonlを介してJSONL評価シードにエクスポートできます。

コマンド

Command

説明

skai ingest [--path data/docs --urls data/urls.txt --reset]

読み込み → チャンク分割 → 埋め込み → Chromaに永続化

skai ask "..." [--source pdf|md|web] [--thread-id X]

引用付きのワンショット質問

skai chat

メモリ付きの対話型マルチターンチャット

skai ui [--port 7860 --share]

Gradio Web UI: チャット、フィードバック、ライブ取り込み

skai mcp

search_kbとaskを公開するMCPサーバーを実行

skai eval

DeepEval品質スイートを実行（--group eval + キーが必要）

MCPクライアント設定

サーバーは2つのツールを公開します — search_kb(query, source_type?)（生の検索）とask(question)（フルエージェント）。MCPクライアントをそれに向けます:

{
  "mcpServers": {
    "solid-knowledge-ai": {
      "command": "uv",
      "args": ["run", "skai", "mcp"],
      "cwd": "/absolute/path/to/solid-knowledge-ai"
    }
  }
}

モデル選択

デフォルトはHaiku 4.5（高速、低コスト — Q&Aルーター+グレーダー+ジェネレーターループに適しています）。--modelで呼び出しごとに切り替えるか、.envのSKAI_MODELでグローバルに切り替えます:

Value

解決先

haiku (default)

anthropic/claude-haiku-4-5

sonnet

anthropic/claude-sonnet-4-5

任意のLiteLLM ID

そのまま渡されます（例: openai/gpt-4o-mini）

Opusは意図的にブロックされています（resolve_modelが例外を発生させる）。そのため、アシスタントが誤って最も高価なティアを指すことはありません。

可観測性

.envにLANGFUSE_PUBLIC_KEY / LANGFUSE_SECRET_KEY（およびオプションでLANGFUSE_HOST）を設定します。すると、すべてのグラフ実行で、ノードごとおよびLLM呼び出しごとにスパンを持つ1つのトレースが生成されます。キーがない場合、トレースは完全なノーオペレーションです — 他には何も変わりません。

品質評価（DeepEval）

uv sync --group eval
export ANTHROPIC_API_KEY=...
uv run skai ingest
uv run --group eval pytest evals -v      # or: skai eval

判定者はLiteLLM経由のClaudeなので、OpenAIキーは不要です。メトリクス: 忠実性、回答関連性、文脈関連性 — さらに低コストのキーワードゲート。

テスト

uv run pytest        # 39 tests, fully offline: no network, no API keys

LLMは依存性注入されているため、テストではグラフ全体が決定的なスタブに対して実行され、Chromaは決定的なインプロセス埋め込み関数を使用します。

構成方法

src/skai/
  config.py            settings (.env)              agent/llm.py     ChatLiteLLM -> Claude
  models.py            Document/Chunk/AgentState    agent/nodes.py   route/retrieve/grade/generate/self_check
  ingest/loaders.py    pdf | md | web  -> Document  agent/prompts.py node prompts
  ingest/chunk.py      source-aware splitting       agent/graph.py   StateGraph + SQLite memory
  ingest/store.py      Chroma add/query             observability.py Langfuse handler (or no-op)
  cli.py               ingest|ask|chat|mcp|eval     mcp_server.py    search_kb / ask as MCP tools
evals/                 DeepEval suite               tests/           offline unit + graph tests

エージェントグラフとコンポーネント図（Mermaid）: docs/ARCHITECTURE.mdを参照してください。設計根拠と技術トレードオフ: docs/DECISIONS.mdを参照してください。

ステータス

検証済み: uv run skai ingestは3つのソースタイプすべて（md 2 + pdf 1 + web 1 → 170チャンク）を読み込み、実際のセマンティック検索が関連するパッセージを返します。39のオフラインテストが合格します。ask/chat/evalにはANTHROPIC_API_KEYが必要です。

Available Tools

2 tools
askB

Ask the self-reflective knowledge agent. Returns a grounded, cited answer.

NameRequiredDescriptionDefault
questionYes

Output Schema

NameRequiredDescription
resultYes

TDQS

B3.2/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry behavior disclosure; it does say outputs are grounded and cited, a meaningful trait. However, it does not mention limitations, confidence, citation format, or whether the agent can refuse/ask follow-ups, leaving the behavioral profile thin.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, with the core instruction and return behavior front-loaded. No filler or redundant restatement of the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter tool with an output schema, the description covers the key behavior and return characteristic. It is mostly complete, though the lack of sibling differentiation and parameter detail keeps it from being fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has a single required `question` string with no field description, and the description does not elaborate on expected question format, length, or scope. The parameter name is self-explanatory, but the description adds no semantic detail to compensate for 0% schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific action ('Ask') on a distinct resource ('self-reflective knowledge agent') and its output ('grounded, cited answer'). It does not explicitly compare itself to search_kb, but the resource and output type give enough differentiation for a general sense.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to ask versus using search_kb, nor any exclusions or conditions. The name and description imply Q&A usage, but the agent is not told when to choose this tool over the sibling.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_kbC

Semantic search over the ingested documents. Optional source_type: pdf|md|web.

NameRequiredDescriptionDefault
queryYes
source_typeNo

Output Schema

NameRequiredDescription
resultYes

TDQS

C2.9/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the full burden of disclosing behavior. It reveals that the tool searches over ingested documents and accepts an optional source_type, but it does not disclose result limits, relevance behavior, authentication needs, or any side effects. For a read/search tool this is a notable but not severe gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single tight sentence followed by a compact optional-parameter note. It is front-loaded with the core action and resource, and every word adds information. No filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter search tool, the description covers the essential invocation surface, and an output schema likely documents return values. However, it omits any comparison with 'ask' and does not explain result behavior or limitations, leaving the agent to infer when this tool is appropriate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate. It does add meaning to source_type by enumerating allowed values ('pdf|md|web'), but it leaves the main 'query' parameter semantically undefined beyond the schema's bare type declaration. The compensation is only partial.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Semantic search') on a clear resource ('ingested documents') and lists the optional source_type filter. It does not explicitly name the sibling tool 'ask' as the alternative, so some differentiation is left to inference, but the operation is unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to prefer search_kb over the sibling tool 'ask', nor any exclusions or prerequisites. Usage context is only implied by the phrase 'semantic search', which is not enough to route an agent reliably.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.0
    • First observedask
    • First observedsearch_kb
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.2/5.0

Scored across 2 tools

Disambiguation4/5

The two tools are distinct in purpose: search_kb returns semantic search results over sources, while ask provides a grounded, cited answer through an agent. There is some overlap in that both retrieve information from the same knowledge base, but the descriptions clearly differentiate a low-level search from a high-level Q&A interaction, making misselection unlikely.

Naming Consistency4/5

Both tool names use lowercase snake_case and are verb-based. 'search_kb' follows a verb_noun pattern while 'ask' is a bare verb, creating a minor inconsistency, but the pattern is still simple and predictable given the small set.

Tool Count3/5

With only two tools, the server feels thin but not unreasonable. Search and ask cover the core knowledge-access functions, though additional tools like listing sources or managing documents might be expected in a fuller knowledge-management server.

Completeness4/5

The tool surface covers the core domain of querying an ingested knowledge base: search_kb for retrieval and ask for synthesized answers. Minor gaps exist, such as no way to enumerate available sources or inspect document metadata, but these are not critical for the stated purpose.

Maintenance

ActivitySlowing
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers