How search works Added in v0.116.0 (2026-11-04)

Graphium finds things in your notes in several places — the ⌘K Composer, the note list, and the AI chat. Behind them are three ways of looking: by words, by meaning, and by the structure you recorded. This page explains each one briefly, where it runs, and where the idea comes from.

Everything here runs on your device or through the AI model you set up. The indexes are caches built from your notes; deleting them loses nothing, and they never change your notes.

The big picture

Where	What it matches	How it looks
⌘K Composer	Titles, headings, labels and authors first; then the words in note bodies and in materials (text read from images, PDFs, web pages)	Words
Note list search box	Titles, text read from images, and note bodies	Words
AI chat — the first search (Internal / External)	Knowledge pages, plus short passages from notes and materials	Words + meaning, merged
AI chat — the AI searches again	The same as the first search, with words the AI picks	Words + meaning
AI chat — the AI follows the structure	Labeled materials, tools, conditions and outputs; steps; links between notes	Structure

By words: the full-text index (BM25)

When you save a note, Graphium cuts it into passages of about 600 characters and adds them to a full-text index on your device. Text read from images (OCR), PDF text, and web-page excerpts go into the same index. A search scores each passage with BM25: a word counts for more when it appears often in that passage, and for less when it appears everywhere. This is the method most search engines have used for decades.

Japanese has no spaces between words, so Graphium splits it with the word breaker built into the browser and operating system. Longer words are also stored as two-character pieces (熱電変換 → 熱電 · 電変 · 変換), so a search still matches when a word is split differently.

• Good at: exact names — a sample ID, a model number, a chemical formula, a person.
• Weak at: different wording for the same thing ("dry box" vs "desiccator").
• Needs: nothing — no AI model, no internet.

You can see what is in the index in Settings → Storage → Search index.

By meaning: embeddings

An embedding turns a piece of text into a list of numbers, placed so that texts with similar meaning end up close together. Graphium embeds each section of your knowledge pages and, when you ask the AI something, embeds the question too, then picks the closest sections.

On the desktop app the default embedding model, bge-m3, runs on your device (it is downloaded once). It handles Japanese and English and can match across them. How it compares with other models is in Which embedding model finds the right passage?, and how much memory it uses while it works is in Why the desktop app ate 11 GB while tidying up.

• Good at: different wording, and questions in one language about notes in another.
• Weak at: exact names and numbers; results can look plausible without containing the word you meant.
• Needs: an embedding model. Without one, this part is simply skipped and the word search still works.

Merging the two: reciprocal rank fusion

The chat's first search runs both, then merges the two ranked lists with reciprocal rank fusion (RRF). RRF ignores the raw scores — which are on different scales — and adds up 1 / (60 + rank) from each list. A passage near the top of both lists comes first; one that only one list found still gets a place.

Handing the AI the passages it needs, so it answers from your notes instead of from memory, is called retrieval-augmented generation (RAG). In Graphium, the passages carry numbers, and the AI cites them: that is how the links in an answer point back to your notes.

By structure: what you recorded

When you label a material, tool, condition or output, mark steps, or link one note to another (Labels & provenance), you record a small graph: what was used, in which step, and what came from what. Graphium writes this down following W3C PROV, the web standard for describing provenance.

A word or meaning search sees this only as text. Following the graph answers different questions:

• "Which runs used this furnace?" — by the label, not the word "furnace" somewhere in the text.
• "What were the steps and conditions of that run?" — the steps in order, with what was labeled in each.
• "Where did this result come from?" — the notes, samples and source files upstream of a note.

These lookups only see what you labeled and linked. An unlabeled mention is left to the word search.

Walking the graph instead of pasting it

A common way to give an AI a graph is to find the nodes near your question and paste them, with their links, into the prompt — and let the AI make sense of the tangle. Graphium does something different: it treats your recorded graph as a place the AI works in, one step at a time.

	Pasting the graph	Walking the graph (Graphium)
What the AI receives	A block of nearby nodes and links, all at once	The result of one lookup, then the next
How the steps are shaped	Generic "neighbors of this node"	Lookups that follow what the record means: which notes used a material, which steps came before, what a note was built from
Two-step questions ("which runs used X, and at what temperature?")	The AI has to spot the path in the pasted block	One lookup finds the runs, the next reads their steps
Where each fact in the answer comes from	Somewhere in the pasted block	A specific lookup result, cited with its number

The direction matters. A material that a step used and a sample that a step produced are different things, even when they sit next to each other in the graph; a lookup that keeps them apart avoids answers that mix up inputs and outputs. And because every fact the AI uses arrives as a numbered result, you can check each claim in the answer against the note it came from — and see the whole trail under How the AI looked it up.

Letting the AI look things up itself (agentic search)

With Research before answering on (Settings → AI → Chat), the AI gets read-only tools — searching again, reading a page, and the structural lookups above — and decides which to call. It looks at each result before choosing the next step, then answers. This pattern of alternating reasoning and actions is known from ReAct; using it to search is often called agentic search.

This can answer two-step questions ("which runs used X, and at what temperature?") that a single search can't. It is also slower, costs more AI usage, and depends on how well the model uses tools — see Letting the AI research before answering for the trade-offs.

Sources

• BM25 — S. E. Robertson, S. Walker, S. Jones, M. M. Hancock-Beaulieu, M. Gatford, "Okapi at TREC-3", Proceedings of TREC-3, NIST, 1995 (proceedings). An accessible later account: S. Robertson, H. Zaragoza, "The Probabilistic Relevance Framework: BM25 and Beyond", Foundations and Trends in Information Retrieval, 2009 (doi:10.1561/1500000019).
• Word breaking — Unicode Standard Annex #29, "Unicode Text Segmentation" (unicode.org), which the browser's word breaker implements.
• Embeddings (bge-m3) — J. Chen, S. Xiao, P. Zhang et al., "M3-Embedding: Multi-Linguality, Multi-Functionality, Multi-Granularity Text Embeddings Through Self-Knowledge Distillation", 2024 (arXiv:2402.03216).
• Reciprocal rank fusion — G. V. Cormack, C. L. A. Clarke, S. Buettcher, "Reciprocal rank fusion outperforms Condorcet and individual rank learning methods", SIGIR 2009 (doi:10.1145/1571941.1572114).
• Retrieval-augmented generation — P. Lewis, E. Perez, A. Piktus et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020 (arXiv:2005.11401).
• Provenance — W3C, "PROV-DM: The PROV Data Model", W3C Recommendation, 2013 (w3.org/TR/prov-dm).
• Reasoning with tool calls — S. Yao, J. Zhao, D. Yu et al., "ReAct: Synergizing Reasoning and Acting in Language Models", ICLR 2023 (arXiv:2210.03629).