Query

Definition

Query is the operation of asking the LLM Wiki a question. Unlike RAG where retrieval happens at query time, the LLM reads the compiled wiki pages and synthesizes an answer from the pre-organized knowledge. This is where the compounding effect pays off: each previous ingest gives the query a maintained knowledge artifact to consult.

Key Points

• Query flow: read index.md as the catalog -> identify relevant wiki pages -> read those pages -> synthesize an answer with citations
• Unlike RAG, there is no vector search or chunk ranking — the wiki’s structure guides retrieval
• Query benefits from the wiki’s cross-links: the LLM can follow connections between concepts
• Wiki pages already contain synthesized knowledge, so the LLM has more context for answering
• Cite the specific wiki pages used for the answer, then let their frontmatter and ## Sources sections provide the route to raw evidence. Level Up Coding explicitly describes query as synthesis with citations.
• The OKF draft defines query separately from ingest: query searches concepts, retrieves matching files, and synthesizes an answer. index.md aids discovery but is not the write operation.
• A contradiction exists between Karpathy’s original index.md-based approach and LLM Wiki v2’s hybrid search: the original assumes index.md works indefinitely; v2 argues it breaks at 100-200 pages.

Hybrid Search at Scale

Beyond 100-200 pages, LLM Wiki v2 recommends hybrid search for query instead of relying solely on index.md. ^[raw/articles/llm-wiki-v2-rohitg00-2026.md] Three streams fused with reciprocal rank fusion (RRF):

1. BM25 — keyword matching with stemming and synonym expansion (catches exact terms)
2. Vector search — semantic similarity via embeddings (catches conceptual matches)
3. Graph traversal — entity-aware relationship walking (catches structural connections)

Each stream catches things the others miss. Together they outperform any single approach, with reported 95.2% on LongMemEval-S.

Implications

Hybrid search is not needed for this vault (45 pages, well within the index.md limit) but becomes essential beyond ~200 pages. The key insight is that graph traversal adds a dimension neither BM25 nor vector search can provide — it finds structurally related content that shares no keyword overlap and no semantic similarity.

Open Questions

• At what exact page count does index.md break? LLM Wiki v2 says 100-200; no empirical data supports a specific threshold.
• Does hybrid search recover the simplicity benefit of a pure index.md approach? If query requires BM25 + vector + graph infrastructure, it loses the “just read markdown files” simplicity.
• RRF fusion weights: what ratio of BM25:vector:graph works best for LLM Wiki? The source reports 95.2% on LongMemEval-S but doesn’t disclose fusion weights.
• Can the three search streams be combined on a budget? Running BM25 + vector + graph searches per query is expensive — no source addresses cost/benefit trade-off.

Related Concepts

• llm-wiki — Query is one of the three core LLM Wiki operations
• ingest — Ingest feeds the wiki that query reads from
• lint — Regular linting ensures query has quality sources to work with
• open-knowledge-format — format-level definition of query and its separation from ingest

Sources

^[raw/articles/karpathy-llm-wiki-gist.md]