Great Synto tutorial in French: Building a full local RAG → Wiki vault pipeline

[kytmanov]

Hey everyone,

Just came across this excellent video tutorial showing how to use Synto in a complete local knowledge base workflow:

• Turning raw Markdown notes into an interconnected Obsidian wiki (with synto run, watch mode, confidence scores, etc.)
• Full RAG-to-local-vault pipeline using Ollama, n8n, Gemini, and GitHub

Super useful if you're into local LLMs and personal knowledge bases.

Video: https://www.youtube.com/watch?v=7nnF8teISkE

Would love to hear your thoughts or any other interesting use cases with Synto!

[bstovej]

Since I can't understand French, I got LLM to translate the transcript to learn how it was done. This implementation is has a number of redundancies. It uses synto (which creates an index db), and on top of it, Copilot and Smart Connection, which add another two layers of embedding/indexing. I think synto is already good enough since it supports query on the vault, and can function with a Terminal that is inside or outside the vault. I haven't uninstall my Copilot plugin as I use it with cloud LLM with websearch capability for long conversations. BTW, when using synto query, does it use the heavy or light LLM provider? How about having a Query provider defined specifically for query purposes, and with option for web-search? Perhaps that would help remove Copilot plugin and lighten the vault overheads.

[kytmanov]

Sorry for the slow reply on this - I missed it earlier.

Good catch on the stack in that video. You're right that Synto + Copilot + Smart Connections is a lot of overlapping index/embedding work for one vault. Synto is intentionally different here: synto query does not use embeddings. It routes through wiki/index.md (with concept-alias hints from the state DB), so if your main need is “answer from my notes,” Synto alone is usually enough, and you can run it from a terminal inside or outside the vault.

On the model question: synto query uses both roles:

1. fast — picks which wiki pages are relevant
2. heavy — writes the answer from those pages

Same split as the rest of the pipeline (fast for cheap routing/analysis, heavy for generation).

A dedicated query provider (and especially optional web search) is a fair feature request. Today the roles are only fast / heavy / embed, so query is locked to that pair. A separate query endpoint would let you point Q&A at a stronger/cloud model without changing compile, and web search is basically the gap people keep Copilot for. I want to keep the default path local and grounded in the vault, but an opt-in web-search path (or a clean way to plug one in) would make sense so you can drop the extra plugins when you don't need them.

Thanks for writing this up — useful signal on where the product should go next.