
任意の文書コレクションをナレッジグラフに変換します。LLMを介してエンティティと関係を抽出し、あなたの承認を得て重複排除します。ドメインをマッピングし、隠れたつながりを見つけ、文書間のパターンを発見します — あなたとあなたのAIエージェントのために、持続し蓄積される知識です。すべてCLIから。
あらゆるドキュメントコレクションを知識グラフに変換します。
コード不要、データベース不要、インフラ不要 — CLIとドキュメントだけでOK。PDF、論文、記事、レコードを投げ込めば、すべてがどのように繋がっているかを示すブラウザブルな知識グラフを数分で取得できます。sift-kgはLLMを介してエンティティと関係性を抽出し、あなたの承認を得て重複を排除し、ブラウザで探索できるインタラクティブビューアを生成します。あらゆるものの概念マップを、いつでも手軽に。
可視化を支えるのと同じグラフは、AIセカンドブレインとしても機能します。NotionやObsidianで知識ベースを構築するのに何ヶ月も費やしている人ばかりです。そんな時間、誰にあるでしょうか? sift-kgは、2年ではなく2分で構築できる構造化された記憶です。ドキュメントを指定するだけで、あなたのAIはすべてがどのように繋がっているかを構造的に理解します。
ライブデモ → sift-kgによって完全に生成されたグラフ```bash pip install sift-kg
sift init # create sift.yaml + .env.example sift extract ./documents/ # extract entities & relations sift build # build knowledge graph sift resolve # find duplicate entities sift review # approve/reject merges interactively sift apply-merges # apply your decisions sift narrate # generate narrative summary sift view # interactive graph in your browser sift export graphml # export to Gephi, yEd, Cytoscape, SQLite, etc.
## 動作の仕組み```
Documents (PDF, DOCX, text, HTML, and 75+ formats)
↓
Text Extraction (Kreuzberg, local) — with optional OCR (Tesseract, EasyOCR, PaddleOCR, or Google Cloud Vision)
↓
Schema Discovery (LLM designs entity/relation types from your data — or use a predefined domain)
↓
Entity & Relation Extraction (LLM, using discovered or predefined schema)
↓
Knowledge Graph (NetworkX, JSON)
↓
Entity Resolution (LLM proposes → you review)
↓
Narrative Generation (LLM)
↓
Interactive Viewer (browser) / Export (GraphML, GEXF, CSV, SQLite)
すべてのエンティティとリレーションは、元のドキュメントと箇所にリンクされています。統合するものを制御できます。グラフはあなたのものです。
sift.yamlを置けば設定が永続化されますdiscovered_domain.yamlとして保存され、再利用や編集が可能。または構造化ドメイン(general、osint、academic)を使用して固定スキーマを適用するか、YAMLで独自のスキーマを定義することもできますsift search "SBF" でエンティティを名前またはエイリアスで検索し、オプションでリレーションや説明を出力--neighborhood、--top、--community、--source-doc、--min-confidencesift-kgは、AIエージェントが直接操作できる構造化ナレッジを生成します。
siftをドキュメント、ノート、プロジェクトファイルに向けてください。出力されるJSONナレッジグラフは、あらゆるAIエージェントに、世界のあらゆるものがどのようにつながっているかについての永続的で構造化された理解を提供します。手動による整理、タグ付け、Wikiリンクは不要です。構造はコンテンツから自然に生まれます。```bash sift extract ./my-stuff/ sift build sift topology # structural overview (JSON, for agents) sift query "topic" # entity neighborhood subgraph (JSON, for agents) sift search "X" --json # entity lookup (JSON, for agents) sift info --json # project stats (JSON, for agents)
グラフはセッションを跨いで永続し、段階的に成長します — 新しいドキュメントを同じ出力ディレクトリに抽出して再構築します。エンティティの重複排除により、グラフが成長しても一貫性を保ちます。
**これがエージェントに与えるもの:**
- **構造** — テキストチャンクだけでなく、エンティティ、関係、コミュニティ、それらの接続方法
- **トポロジー** — どの知識クラスターが存在するか、それらを橋渡しするもの、孤立しているもの
- **耐久性** — グラフはコンテキストウィンドウのリセット後も存続します。エージェントは毎セッションゼロから始める必要がなくなります
**バンドルされたエージェントスキル:** sift-kg には `.agents/skills/sift-kg/SKILL.md` にスキルが同梱されており、エージェントにナレッジグラフを永続メモリとして使用する方法(セッションのオリエンテーション、エンティティ探索、知識島のリンク推論、根拠のある提案生成)を教えます。
## バンドルされたドメイン
sift-kg にはすぐに使用できる特殊なドメインが同梱されています:```bash
sift domains # list available domains
sift extract ./docs/ --domain-name osint # use a bundled domain
sift.yaml にドメインを設定すると、毎回フラグを指定する必要がなくなります:```yaml
domain: academic
バンドル名(`schema-free`、`general`、`osint`、`academic`)またはカスタムYAMLファイルへのパスで動作します。
| ドメイン | 焦点 | 主要なエンティティタイプ | 主要な関係タイプ |
|--------|-------|------------------|--------------------|
| `schema-free` | データから自動発見(デフォルト) | *(LLMがコーパスごとに設計)* | *(LLMがコーパスごとに設計)* |
| `general` | 一般的な文書分析 | PERSON, ORGANIZATION, LOCATION, EVENT, DOCUMENT | ASSOCIATED_WITH, MEMBER_OF, LOCATED_IN |
| `osint` | 調査・FOIA | SHELL_COMPANY, FINANCIAL_ACCOUNT | BENEFICIAL_OWNER_OF, TRANSACTED_WITH, SIGNATORY_OF |
| `academic` | 文献レビュー・トピックマッピング | CONCEPT, THEORY, METHOD, SYSTEM, FINDING, PHENOMENON, RESEARCHER, PUBLICATION, FIELD, DATASET | SUPPORTS, CONTRADICTS, EXTENDS, IMPLEMENTS, EXPLAINS, PROPOSED_BY, USES_METHOD, APPLIED_TO, INVESTIGATES |
**academic** ドメインは、研究分野の知的ランドスケープをマッピングします。論文を入力すると、理論、手法、システム、発見、概念がどのように結びついているかを示すグラフが得られます。抽象的なアイデア(THEORY, METHOD)と具体的な成果物(SYSTEM — 例:GPT-2、BERT、GLUE)を区別します。文献レビュー、トピックマッピング、そしてアイデアがどこで一致し、矛盾し、あるいは互いに基づいて構築されているかを理解するために設計されています。
**schema-free** ドメイン(デフォルト)は、抽出前に**スキーマ発見**ステップを実行します。1回のLLM呼び出しで文書をサンプリングし、コーパスに合わせたエンティティタイプと関係タイプを設計します。発見されたスキーマは `output/discovered_domain.yaml` に保存され、後続の実行で再利用されるため、すべてのチャンクと文書間でタイプの一貫性が保たれます。ファイルを検査、手動編集、またはカスタムドメインの開始点としてコピーできます。再発見するには `--force` を使用します。関係を ASSOCIATED_WITH のような定義済みカテゴリに強制的に当てはめるのではなく、FUNDED、TESTIFIED_AGAINST、ENROLLED_AT のような具体的なタイプを生成します。あらかじめ定義した固定スキーマが必要な場合は、`general` や `osint` のような構造化ドメインを使用してください。
**general** ドメインは、PERSON、ORGANIZATION、LOCATION、EVENT、DOCUMENT のエンティティタイプと一般的な関係タイプを持つ固定スキーマを提供します。文書間で予測可能で一貫したタイプが必要な場合に便利です。
**osint** ドメインは、シェル会社、金融口座、オフショア管轄区域のエンティティタイプと、受益者所有権や資金フローを追跡するための関係タイプを追加します。
あなたの承認なしには何もマージされません。LLMが提案し、あなたが検証します。すべての抽出結果は、元の文書とパッセージにリンクされています。
概念グラフとしてマッピングされた12の基礎的なAI論文(425エンティティ、約$0.72)については [`examples/transformers/`](https://github.com/juanceresa/sift-kg/blob/HEAD/examples/transformers/) を、FTX崩壊(9記事から431エンティティ)については [`examples/ftx/`](https://github.com/juanceresa/sift-kg/blob/HEAD/examples/ftx/) を参照してください。[**ライブデモを探索する**](https://juanceresa.github.io/sift-kg/) — インストール不要、APIキー不要。
## Civic Table
法医学的リーガル分析とアナリストによる検証を備えたホスティングプラットフォームをお探しですか?
[**Civic Table**](https://github.com/juanceresa/forensic_analysis_platform) は、sift-kg パイプライン上に構築された法医学インテリジェンスプラットフォームです。AIが抽出した事実が証拠として扱われる前に、アナリストとJDが検証する4段階の検証システム、法務提出用のLaTeX書類生成、結果をクライアントや家族と共有するためのWebインターフェースを追加します。財産回復、調査ジャーナリズム、そして文書の出所が重要となるあらゆるコンテキストのために構築されています。
sift-kg はオープンソースのCLIです。Civic Table は完全なプラットフォームであり、アナリストとJDによって出力が検証されてから証拠としての重みを持つようになります。
## インストール
Python 3.11+ が必要です。```bash
pip install sift-kg
OCRサポート(スキャンされたPDF、画像)の場合:```bash
brew install tesseract # macOS sudo apt install tesseract-ocr # Ubuntu/Debian
代替バックエンドとしてGoogle Cloud Vision OCRを使用する場合(オプション):```bash
pip install sift-kg[ocr]
# Then use: sift extract ./docs/ --ocr --ocr-backend gcv
エンティティ解決時のセマンティッククラスタリング用に(オプション、PyTorchの場合は約2GB):```bash pip install sift-kg[embeddings]
開発用:```bash
git clone https://github.com/juanceresa/sift-kg.git
cd sift-kg
pip install -e ".[dev]"
sift init # creates sift.yaml + .env.example cp .env.example .env # copy and add your API key
`sift init` は `sift.yaml` プロジェクト設定を生成するため、毎回のコマンドにフラグを指定する必要がありません:```yaml
# sift.yaml
domain: domain.yaml # or a bundled name like "osint"
model: openai/gpt-4o-mini
ocr: true # enable OCR for scanned PDFs
# extraction:
# backend: kreuzberg # kreuzberg (default, 75+ formats) | pdfplumber
# ocr_backend: tesseract # tesseract | easyocr | paddleocr | gcv
# ocr_language: eng
APIキーを .env に設定してください:```
SIFT_OPENAI_API_KEY=sk-...
またはAnthropic、Mistral、Ollama、または任意のLiteLLMプロバイダを使用してください:```
SIFT_ANTHROPIC_API_KEY=sk-ant-...
SIFT_MISTRAL_API_KEY=...
設定の優先順位: CLIフラグ > 環境変数 > .env > sift.yaml > デフォルト値。sift.yaml の設定は、任意のコマンドでフラグを使用して上書きできます。
sift extract ./my-documents/ sift extract ./my-documents/ --ocr # local OCR via Tesseract sift extract ./my-documents/ --ocr --ocr-backend gcv # Google Cloud Vision OCR sift extract ./my-documents/ --extractor pdfplumber # legacy pdfplumber backend
75以上のドキュメント形式(PDF、DOCX、XLSX、PPTX、HTML、EPUB、画像など)を読み取ります。設定したLLMを使用してエンティティとリレーションを抽出します。結果は `output/extractions/` にJSONとして保存されます。
`--ocr` フラグにより、スキャンされたPDFに対してTesseract経由のローカルOCRが有効になります。APIキーやクラウドサービスは不要です。`--ocr-backend` でOCRエンジンを切り替えることができます:```bash
sift extract ./docs/ --ocr # Tesseract (default, local)
sift extract ./docs/ --ocr --ocr-backend easyocr # EasyOCR (local)
sift extract ./docs/ --ocr --ocr-backend paddleocr # PaddleOCR (local)
sift extract ./docs/ --ocr --ocr-backend gcv # Google Cloud Vision (requires credentials)
どのPDFにOCRが必要かを自動検出します。テキストが豊富なPDFは標準的な抽出を使用し、ほぼ空のページのみがOCRにフォールバックします。混合フォルダでも安全です。--ocr を指定しない場合、siftはPDFがスキャンされたものである場合に警告します。
また、--extractor pdfplumber を使用して抽出バックエンド全体をレガシーなpdfplumberバックエンド(PDF/DOCX/TXT/HTMLのみ)に切り替えることもできます。
sift build
すべての抽出結果からNetworkXグラフを構築します。グラフノードになる前に、ほぼ同一のエンティティ名(複数形、Unicodeのバリアント、大文字小文字の違い)を自動的に重複排除します。LLMがソース/ターゲットタイプをドメインスキーマと入れ替えた場合に、逆方向のエッジ方向を修正します。信頼性の低い関係をレビュー用にフラグ付けします。`output/graph_data.json` に保存します。
### 4. 重複エンティティの解決
正確性が重要な系図、法律、調査のユースケースでは特に重要な、完全なガイドについては、以下の[エンティティ解決ワークフロー](#entity-resolution-workflow)を参照してください。
### 5. 探索とエクスポート
**インタラクティブビューア** — ブラウザで概念マップを探索します:```bash
sift view # full graph
sift view --neighborhood "Palantir Technologies" # 1-hop ego graph around an entity
sift view --neighborhood "Palantir" --depth 3 # 3-hop neighborhood
sift view --top 10 # top 10 hubs + their neighbors
sift view --community "Community 1" # focus on a specific community
sift view --source-doc palantir_nsa_surveillance # entities from one document
sift view --min-confidence 0.8 # hide low-confidence nodes/edges
ブラウザにフォース指向グラフを表示します。概要にはコミュニティ領域(関連するエンティティをグループ化した色付きの凸包)が表示され、ラベルの乱雑さなくグラフ構造を一目で確認できます。任意のノードにマウスオーバーすると、その名前と接続をプレビューできます。検索、タイプ/コミュニティ/関係のトグル、ソースドキュメントフィルター、次数フィルター、詳細サイドバーが含まれています。
プリフィルターフラグ(--top、--neighborhood、--source-doc、--min-confidence)は、レンダリング前にグラフを削減します。--communityはサイドバーでコミュニティを事前選択します。--neighborhoodはエンティティID(person:alice)または表示名(大文字小文字を区別しない)を受け入れます。
フォーカスモード: 任意のエンティティをダブルクリックして、その近傍を分離します。矢印キーを使用して接続を1つずつステップスルーします。各ペアはラベル付きエッジとともに分離して表示されます。Enter/右矢印で近傍にフォーカスを移動、Backspace/左矢印でパスを戻る、Escapeで終了します。探索はサイドバーのトレイルパンくずリストとして追跡されます。これは、訪問したすべてのノードとそれらの間の関係を示す永続的なパスです。トレイルエッジはキャンバス上でハイライトされたままになるため、グラフ内のパスを確認できます。これが密なグラフを探索するための意図された方法です。重要なものにズームインし、接続を辿り、証拠を読んでください。
CLI検索 — ターミナルから直接エンティティをクエリ:```bash sift search "Sam Bankman" # search by name sift search "SBF" # search by alias sift search "Caroline" -r # show relations sift search "FTX" -d -t ORGANIZATION # descriptions + type filter
**静的エクスポート** — カスタムレイアウト、フィルタリング、またはスタイルを希望する分析ツール向け:```bash
sift export graphml # → output/graph.graphml (Gephi, yEd, Cytoscape)
sift export gexf # → output/graph.gexf (Gephi native)
sift export sqlite # → output/graph.sqlite (SQL queries, DuckDB, Datasette)
sift export csv # → output/csv/entities.csv + relations.csv
sift export json # → output/graph.json
GraphML/GEXFは、ノードのサイズ、エッジの重み、カスタムカラースキームを制御したり、専用ツールでグラフアルゴリズム(中心性、コミュニティ検出)を適用したい場合に使用します。SQLiteは、アドホックなSQLクエリ、Datasette での公開、またはDuckDBへのロードに便利です。
sift narrate sift narrate --communities-only # regenerate community labels only (~$0.01)
`output/narrative.md` を生成します。これは、概要、主要エンティティ間の主要な関係チェーン、タイムライン(データ内に日付が存在する場合)、およびテーマ別コミュニティ(Louvain community detection により発見)によってグループ化されたエンティティプロファイルを含む散文レポートです。エンティティの説明は、役割の要約ではなく、具体的な行動を伴う能動態で記述されます。
## ドメイン構成
sift-kg には4つのバンドルドメインが付属しています(詳細は上記の [バンドルドメイン](#bundled-domains) を参照してください)。デフォルトは `schema-free` です。
バンドルドメインを使用:```bash
sift extract ./docs/ --domain-name osint
または独自の domain.yaml を作成してください:```yaml
name: My Domain
fallback_relation: RELATED_TO # optional — catch-all for relations that don't fit defined types
entity_types:
PERSON:
description: People and individuals
extraction_hints:
- Look for full names with titles
COMPANY:
description: Business entities
DEPARTMENT:
description: Named departments within a company
canonical_names: # closed vocabulary — only these values allowed
- Engineering
- Sales
- Legal
- Marketing
canonical_fallback_type: ORGANIZATION # non-canonical names get retyped
relation_types:
EMPLOYED_BY:
description: Employment relationship
source_types: [PERSON]
target_types: [COMPANY]
OWNS:
description: Ownership relationship
symmetric: false
review_required: true
RELATED_TO: # define the fallback type if you use one
description: General relationship
**Schema enforcement:** Entity types and relation types defined in your domain are treated as a closed set — the LLM is instructed to use only these types and will not invent new ones. If `fallback_relation` is set, relationships that don't fit any defined type are mapped to the fallback. If omitted, the LLM uses the closest matching defined type with lower confidence. If you see many relations landing on your fallback type, your schema is likely missing a relation type that the data needs — add it and re-extract.
Entity types with `canonical_names` enforce a closed vocabulary. The allowed names are injected into the LLM extraction prompt so it outputs exact matches. As a safety net, any extracted name not in the list gets retyped to `canonical_fallback_type` during graph building (or kept as-is if no fallback is set). Useful for controlled taxonomies — departments, jurisdictions, predefined classifications.```bash
sift extract ./docs/ --domain path/to/domain.yaml
Pythonからsift-kgを使用 — Jupyterノートブック、スクリプト、Webアプリ:```python from sift_kg import load_domain, run_extract, run_build, run_narrate, run_resolve, run_export, run_view from sift_kg import KnowledgeGraph from pathlib import Path
domain = load_domain() # or load_domain(bundled_name="osint")
results = run_extract( Path("./docs"), "openai/gpt-4o-mini", domain, Path("./output"), ocr=True, ocr_backend="tesseract", # enable OCR for scanned PDFs extractor="kreuzberg", # or "pdfplumber" concurrency=4, chunk_size=10000, )
kg = run_build(Path("./output"), domain) print(f"{kg.entity_count} entities, {kg.relation_count} relations")
merges = run_resolve(Path("./output"), "openai/gpt-4o-mini", domain=domain, use_embeddings=True)
run_export(Path("./output"), "sqlite")
run_narrate(Path("./output"), "openai/gpt-4o-mini", communities_only=True)
run_view(Path("./output")) # full graph run_view(Path("./output"), neighborhood="person:alice", depth=2) # ego graph run_view(Path("./output"), top_n=10) # top hubs
from sift_kg import run_pipeline run_pipeline(Path("./docs"), "openai/gpt-4o-mini", domain, Path("./output"))
## プロジェクト構成
パイプラインを実行すると、出力ディレクトリには次のものが含まれます:```
output/
├── extractions/ # Per-document extraction JSON
│ ├── document1.json
│ └── document2.json
├── discovered_domain.yaml # Auto-discovered schema (schema-free mode)
├── graph_data.json # Knowledge graph (native format)
├── merge_proposals.yaml # Entity merge proposals (DRAFT/CONFIRMED/REJECTED)
├── relation_review.yaml # Flagged relations for review
├── narrative.md # Generated narrative summary
├── entity_descriptions.json # Entity descriptions (loaded by viewer)
├── communities.json # Community assignments (shared by narrate + viewer)
├── graph.html # Interactive graph visualization
├── graph.graphml # GraphML export (if exported)
├── graph.gexf # GEXF export (if exported)
├── graph.sqlite # SQLite export (if exported)
└── csv/ # CSV export (if exported)
├── entities.csv
└── relations.csv
家族記録、法務文書、または正確性が重要なあらゆる文書から知識グラフを構築する際、どのエンティティをマージするかを完全に制御したいはずです。sift-kg はあなたの承認なしに何もマージしません。
このワークフローには3つのレイヤーがあり、それぞれ異なる種類の重複を捕捉します。
sift build 時)エンティティがグラフノードになる前に、sift は明らかに同一である名前を決定論的に統合します。LLM は関与せず、コストもレビューも不要です。
これは sift build を実行するたびに自動的に行われます。これらは些細なケースであり、情報を追加せずにグラフを乱雑にするだけのスペルバリアントです。
sift resolve 時)LLMはエンティティのバッチ(DOCUMENT以外のすべてのタイプ)を確認し、同じ実世界のものを参照している可能性が高いものを特定します。また、クロスタイプの重複(同名で異なるエンティティタイプ)を検出し、親子パターンを見つけた場合はバリアント関係(EXTENDS)を提案します。結果は merge_proposals.yaml(エンティティマージ)と relation_review.yaml(バリアント関係)に出力され、すべて DRAFT として開始されます。```bash
sift resolve # uses domain from sift.yaml
sift resolve --domain osint # or specify explicitly
ドメインが設定されている場合、LLMはそのコンテキストを使用して、あなたの分野に固有のエンティティ名についてより適切な判断を行います。これにより、次のような提案が生成されます:```yaml
proposals:
- canonical_id: person:samuel_benjamin_bankman_fried
canonical_name: Samuel Benjamin Bankman-Fried
entity_type: PERSON
status: DRAFT # ← you decide
members:
- id: person:bankman_fried
name: Bankman-Fried
confidence: 0.99
reason: Same person referenced with full name vs. surname only.
- canonical_id: person:stephen_curry
canonical_name: Stephen Curry
entity_type: PERSON
status: DRAFT # ← you decide
members:
- id: person:steph_curry
name: Steph Curry
confidence: 0.99
reason: Same basketball player referenced with nickname 'Steph' and full name 'Stephen'.
まだ何もマージされていません。 LLMは提案しているだけで、決定はしていません。
提案を確認するための2つのオプションがあります:
オプション A: インタラクティブなターミナルレビュー```bash sift review
各`DRAFT`提案を一つずつ進めます。それぞれについて、正規エンティティ、提案されたマージメンバー、LLMの信頼度と推論が表示されます。承認、却下、スキップが可能です。
高信頼度の提案(デフォルトでは >0.85)は自動承認され、低信頼度の関係(デフォルトでは <=0.5)は自動却下されます:```bash
sift review # uses defaults: --auto-approve 0.85, --auto-reject 0.5
sift review --auto-approve 0.90 # raise the auto-approve threshold
sift review --auto-reject 0.3 # lower the auto-reject threshold
sift review --auto-approve 1.0 # disable auto-approve, review everything manually
オプションB: YAMLを直接編集する
任意のテキストエディタで output/merge_proposals.yaml を開きます。status: DRAFT を CONFIRMED または REJECTED に変更します:```yaml
canonical_id: person:stephen_curry canonical_name: Stephen Curry entity_type: PERSON status: CONFIRMED # ← approve this merge members:
canonical_id: person:winklevoss_twins canonical_name: Winklevoss twins entity_type: PERSON status: REJECTED # ← these are distinct people, don't merge members:
**高精度なユースケース向け**(系図、法的レビュー)では、各提案を慎重に確認できるよう、YAMLを直接編集することをお勧めします。このファイルは人間が読みやすいように設計されています。
### レイヤー3b: 関係性のレビュー
`sift build`中、信頼度しきい値(デフォルト0.7)以下の関係、またはドメイン設定で`review_required`とマークされたタイプの関係は、`output/relation_review.yaml`でフラグが立てられます:```yaml
review_threshold: 0.7
relations:
- source_name: Alice Smith
target_name: Acme Corp
relation_type: WORKS_FOR
confidence: 0.45
evidence: "Alice mentioned she used to work near the Acme building."
status: DRAFT # ← you decide: CONFIRMED or REJECTED
flag_reason: Low confidence (0.45 < 0.7)
同じワークフロー: sift review でレビューするか、YAMLを編集してから適用します。
すべてをレビューしたら:```bash sift apply-merges
これにより、次の3つの処理が行われます:
1. **確定したエンティティの統合** — メンバーエンティティは正規エンティティに吸収されます。すべての関係が再配線されます。ソースドキュメントが結合されます。メンバーノードは削除されます。
2. **拒否された関係** — グラフから完全に削除されます。
3. **ドラフト提案** — そのまま残されます。後で戻ってくることができます。
グラフは `output/graph_data.json` に保存されます。クリーンアップされたグラフを再エクスポート、ナレーション、可視化することができます。
### 反復処理
エンティティ解決は常に1回で完了するとは限りません。統合後、新たな重複が明らかになることがあります。再実行することができます:```bash
sift resolve # find new duplicates in the cleaned graph
sift review # review the new proposals
sift apply-merges # apply again
各実行は累積的です — merge_proposals.yaml 内の以前の CONFIRMED/REJECTED の判断は保持されます。
事前重複排除とLLMバッチ処理の手法は、@stochastic-sisyphus による KGGen (NeurIPS 2025) に触発されています。KGGenは、決定論的なエンティティ重複排除にSemHashを使用し、LLM比較の前にエンティティをグループ化するために埋め込みベースのクラスタリングを使用します。sift-kgはこれらを人間参加型のレビューワークフローに適応させています。
デフォルトでは、sift resolve はエンティティをアルファベット順に並べ、LLM比較のために重複するバッチに分割します。これは重複が類似した綴りを持つ場合にうまく機能しますが、"Robert Smith" (R) と "Bob Smith" (B) は異なるバッチに配置され、比較されることがありません。```bash
pip install sift-kg[embeddings] # sentence-transformers + scikit-learn (~2GB, pulls PyTorch)
sift resolve --embeddings
これは、アルファベット順のバッチ処理を、文埋め込み(all-MiniLM-L6-v2)に対するKMeansクラスタリングに置き換えます。意味的に類似した名前は、スペルの違いに関係なくクラスタリングされます。
| | デフォルト(アルファベット順) | `--embeddings` |
|---|---|---|
| インストールサイズ | 含まれている | ~2GB(PyTorch) |
| 初回実行時のオーバーヘッド | なし | ~90MBのモデルダウンロード |
| 実行ごとのオーバーヘッド | ソートのみ | エンコーディング(数百エンティティで1秒未満) |
| 異なるアルファベットの重複 | 異なるバッチにある場合は見逃される | 検出される |
| 小規模グラフ(タイプあたり100未満) | 同じ結果 | 同じ結果 |
依存関係がインストールされていない場合やクラスタリングが失敗した場合は、アルファベット順のバッチ処理にフォールバックします。
## ライセンス
MIT
--ocr フラグ)、オプションのGoogle Cloud Visionフォールバック(--ocr-backend gcv)--max-cost でLLMの支出を制限| ユースケース | 推奨アプローチ |
|---|
| 素早い探索 | sift review --auto-approve 0.85 — 高信頼度を承認し、残りをレビュー |
| 系図 / 家系記録 | 手動でYAMLを編集、--auto-approve 1.0 — 各マージをすべてレビュー |
| 法務 / 調査 | sift resolve --embeddings、手動でYAMLを編集、ラウンド間の検査に sift view を使用 |
| 大規模コーパス (1000以上のエンティティ) | より良いバッチ処理のために sift resolve --embeddings を使用し、その後インタラクティブレビュー |