Which backend should I use?
Set it with
knowledge_search.type in your config, or override per index with kapso index_kg --search-type.
kg_graph_search
The primary backend for wiki-based knowledge. It embeds the query, retrieves from Weaviate, optionally reranks with an LLM, then pulls connected pages from Neo4j.
Shipped defaults are
embedding_model: text-embedding-3-large, weaviate_collection: KapsoKG, include_connected_pages: true, use_llm_reranker: false and reranker_overview_max_chars: 300. A preset overrides them; anything a preset omits falls back to these.
This is a different setting from
defaults.models.embedding in the main config, which is text-embedding-3-small and is used for memory rather than for this backend.kg_llm_navigation
For JSON graphs, where an LLM navigates the structure instead of embedding it. No embeddings are involved, so it works with any graph shape.
All four use
search_node_type: specialization.
What comes back from a search
Both backends return aKGOutput.
KGResultItem with id, score, page_type, overview, content and metadata, plus domains, sources and last_updated as properties.
Narrow a search with KGSearchFilters:
How do I index content?
Indexing writes a.index file that campaigns load with --kg-index. See index_kg().
.index file is a small JSON reference, not the data itself:
What happens when knowledge search is off?
KnowledgeSearchFactory.create_null() returns a no-op backend whose search() gives an empty KGOutput. MINIMAL mode ships with knowledge_search.enabled: false and uses it, so a campaign runs without any knowledge-graph infrastructure.
Can I add my own backend?
Register a class implementingKnowledgeSearch:
knowledge_search.yaml beside the two shipped backends.
Related
Knowledge graph
What the graph holds and where it comes from
Learning pipeline
How sources become wiki pages
pip install leeroo-kapso · Every page as plain text: llms.txt.