Thank you for the suggestion, natural language queries are planned for future releases. In the meantime the search assistant might be helpful (although not that much in this case):
The QMD approach is a good reference point, and the interesting design question underneath it is what you actually index. For natural-language queries over a document store like this, the quality lever is almost never the LLM, it’s the retrieval layer feeding it: how you chunk, what you embed, and how you combine lexical and semantic search.
A few things that tend to matter more than the model choice, from doing this locally:
Hybrid beats pure vector. A local embedding model (nomic-embed or bge, say) is great at paraphrase and concept matching, but it quietly loses on exact terms, proper nouns, code identifiers and rare jargon. Running BM25/lexical alongside it and fusing the results (reciprocal rank fusion is the simple version) recovers the precise-match cases pure semantic search drops. For a technical or reference corpus that is a big deal.
Chunk on structure, not a fixed token window. Splitting on headings and paragraphs and keeping a little parent-section context around each chunk retrieves far better than blind 512-token windows, especially for “find me items related to X” queries where the relevant unit is a section, not a sentence.
Metadata filters do a lot of quiet work. A natural-language query usually carries an implicit filter (a date range, a group, a kind of document). Pre-filtering the candidate set before ranking beats a bigger index every time.
The nice part is all of this stays fully local and needs no cloud model or separate vector service: FTS for lexical, a small on-device embedder for semantic, fuse and rerank. @cgrunenberg, if the planned NL-query feature can lean on the existing See Also / classification internals, that hybrid framing may already be half built.
FWIW I’ve built myself a clunkIy version of this to start. I have access to https://www.miyo.md (as a n early Copilot for Obsidian, supporter). It indexes my DEVONthink database as a RAG.
I’m learning that for a broad reaching searches I use Claude:
Claude queries Miyo to find key examplar documents for the query
Documents are parsed for keywords
Claude uses the DEVONthink MCP for keyword searching
Far from perfect but I get results faster and with less effort than working inside DEVONthink on its own.
If it’s good with @cgrunenberg I will use this thread to point other approaches I find that might be technically interesting to the DT Team.
What you have hand-built is close to a classic IR pattern called pseudo-relevance feedback: use a first semantic pass to find exemplar documents, mine them for terms, then run a precise lexical search with those terms. It is a good pattern, and naming it helps when you want to refine it, because most of the quality is decided in the term-mining step. The trick is to ask for terms that discriminate within your corpus, words that occur in the exemplars but are rare in the rest of the database, rather than generic topic words. Generic terms send the keyword search back to the same broad soup the semantic pass already gave you.
The text-only indexing point is worth keeping visible, because that failure mode is silent. If the RAG layer never saw a document type, the whole pipeline is confidently blind to it: the exemplars cannot surface what was never indexed, so the keyword stage never receives the right terms either. A periodic coverage check, item counts per type in DEVONthink versus what Miyo reports as indexed, turns that from an invisible gap into a known one.
