Utoljára frissítve:
PKM & Személyes AI · Spoke
Obsidian RAG pipeline 2026 — hogyan csatlakoztasd a tudásbázisod az AI-hoz?
Az Obsidian vault önmagában gazdag archívum — de a beépített keresés 200 note felett megbízhatatlanná válik. A RAG pipeline az, ami a vaultot valóban kérdezhetővé teszi: markdown export, embedding generálás, Qdrant indexelés, lokális LLM és MCP integráció — a teljes workflow itt, napi operatív tapasztalatból.
256–512 token a legjobb chunk-méret Obsidian note-okhoz. Egy 800 note-os vault kb. 30 perc alatt indexelható Qdrant-ba. A Copilot plugin gyors megoldás, de szemantikus keresésnél 30–50%-kal gyengébb, mint a teljes RAG pipeline. Az MCP integráció teszi Claude-ot igazi vault-asszisztenssé.
Miért nem elég az Obsidian beépített keresése
Az Obsidian keresője szóegyezésen alapul. Ha „PKM rendszer” típusú kifejezésre keresel, megtalálja azokat a note-okat, amelyekben ezek a szavak szerepelnek. De nem találja azt a note-ot, amelyikben csak „személyes tudáskezelés” vagy „knowledge management” olvasható — pedig fogalmilag ugyanarról szól.
Ez a szöveges és szemantikus keresés közötti alapvető különbség. 50 note alatt tökéletesen elegendő a beépített keresés. 200 felett rendszeresen előfordul, hogy tudod, hogy van valami a vaultban, de nem találod — mert más szóval írtad le, mint amit most gépelnek keresőbe. 800 note felett ez napi szintű frusztrációvá válik.
Ami valójában kell: természetes nyelvű kérdések — „melyik note-ban elemeztem a vállalati AI bevezetés kockázatait?” — és releváns találatok, amelyek a kérdés jelentése alapján kerülnek elő, nem a szavak egyezése alapján. Erre való a RAG pipeline.
A 900 note-os vaultomban a beépített keresés még most sem haszontalan — de a valódi munka az MCP-alapú corpus-keresésen fut. Egy kérdésre átlagosan 3–5 releváns note kerül elő, köztük olyanok is, amelyek létezéséről már nem emlékeztem. A „saját elfelejtett tudás visszahozása” az egyik leghasznosabb funkció.
A pipeline felépítése — 5 lépés
Az Obsidian RAG pipeline öt egymásra épülő lépésből áll. Minden komponens cserélhető — az architektúra rugalmas, nem kötött egyetlen eszközhöz. Az alábbi workflow a saját rendszerem alapján épül fel, amely 1,48 millió vektort indexel.
A vault Markdown fájljait beolvasod és frontmatter YAML-t elválasztod a törzs szövegtől. A frontmatter mezőket (tags, created, type, up) külön metaadatként tárolod — nem kerülnek bele az embedding szövegébe. A wikilink referenciákat ([[Note Name]]) vagy eltávolítod, vagy megtartod és link-gráfként leképezed a Qdrant payload-ban.
Az Obsidian atomikus note-ok természetes határokon vághatók: H2/H3 fejlécnél, bekezdéshatárokon. Ajánlott: 256–512 token leaf chunk pontossághoz, 1024 token parent chunk kontextus-gazdagításhoz (hierarchikus parent-child chunking). Rövid note-ok (50 szó alatt) összegyűjthetők tematikus parent chunk-ba, hogy ne vigyenek zajt a vektorbázisba.
Minden chunk-ot az embedding szerver numerikus vektorrá alakít. Lokális ajánlás: llama-server Qwen3-Emb-8B modellel (Matryoshka, multilinguális, erős magyar szövegeknél). Alternatíva kisebb gépen: nomic-embed-text (768 dim, gyors). Felhőalapú: OpenAI text-embedding-3-small (0.02 USD/1M token, egy 800 note-os vault indexelése elhanyagolható cost).
A vektorokat és a hozzájuk tartozó szöveget, metaadatokat Qdrant-ba töltöd — Docker-ben fut, 6333-as porton érhető el. Két kollekcióban érdemes tárolni: corpus_leaves (pontos visszakeresés) és corpus_parents (kontextus). A payload tartalmazza: note elérési útvonalat, frontmatter mezőket, chunk indexet. Hash-alapú változásdetekció: csak az új vagy módosult note-ok kerülnek újra-feldolgozásra.
A FastAPI search szerver (8091-es port) fogadja a természetes nyelvű kérdéseket, elvégzi a vektoros keresést, majd a reranker (Qwen3-Reranker-0.6B) újrarangsorolja a találatokat relevancia alapján. Az LLM — Ollama lokálisan vagy Claude MCP-n keresztül — a top találatok szövegéből szintetizálja a választ. Az MCP integráció az, ami az egész rendszert valódi vault-asszisztenssé teszi.
Az adatfolyam vizuálisan
Markdown
256/1024 tok
Qwen3-Emb
vektorbázis
relevancia
szintézis
Melyik szint kell neked? — döntési táblázat
Három szint létezik az Obsidian AI-integrációban. Ezek nem egymást kizárók — egyre mélyebb technikai elköteleződést és egyre nagyobb hasznot képviselnek. A „minél több, annál jobb” logika csapda: a 3. szint nem mindenkinek szükséges.
| Szint | Eszköz | Vault-méret | Keresés típusa | Technikai igény |
|---|---|---|---|---|
| 1. Copilot plugin | Obsidian Copilot | 50–200 note | Szöveges alapú | Plug-and-play, API kulcs |
| 2. Smart Connections | nomic-embed-text lokálisan | 200–500 note | Szemantikus, lokális | Plugin telepítés |
| 3. Teljes RAG pipeline | Qdrant + reranker + MCP | 500+ note | Szemantikus + rerank | Fejlesztői képességek, 3–6 hónap |
A 3. szint valódi értéke ott mutatkozik meg, ahol a vault specifikus, máshol nem elérhető tudást tartalmaz: saját kutatási meglátások, döntésnapló, projekttörténet, személyes elemzések. Ezeket az általános AI nem ismeri — csak a saját corpus. Ha a vaultod főleg máshonnan mentett cikkekből áll, a 2. szint elegendő.
A 3. szint felépítési ideje valóban 3–6 hónap — ez nem weekend projekt. Az első hónap: chunking pipeline és indexelő script. A második: search API és reranker. A harmadik: MCP és minőségjavítás. De ha a vault egyedi, a befektetés megtérül — mert ezt a tudást más forrásból nem lehet pótolni.
Inkrementális re-indexelés — a vault él
Az indexelés nem egyszeri feladat. A vault él: note-ok születnek, változnak, törlődnek. Az inkrementális hash-alapú indexelés megoldja ezt: minden note-hoz tárold az MD5 vagy SHA256 hash-t. Futtatáskor csak azokat a fájlokat dolgozza fel újra az indexelő, amelyeknek megváltozott a hash-e.
Egy 900 note-os vaultban, ahol naponta 5–10 note változik, az inkrementális futás másodpercekig tart, a teljes re-index percekig. Ez teszi lehetővé az automatikus napi ütemezést. A wikilink-gráf konzisztenciájához havi teljes re-index ajánlott — a törölt vagy átnevezett note-ok referenciáit ez takarítja el.
Az AI csak annyira jó, amilyen jók a mögötte lévő note-ok. Ezer jól szervezett, linkelt, saját perspektívával ellátott note értékesebb corpust képez, mint tízezer összefüggéstelen szövegrészlet. A minőséget nem a mennyiség, hanem a struktúra és a koherencia határozza meg.
PARA struktúra a RAG pipeline-ban
Az Obsidian PARA struktúrája (Projects, Areas, Resources, Archive) természetes hierarchiát teremt, amelyet a RAG pipeline ki tud használni. A Projects és Areas note-ok parent chunk-ként kezelhetők — ezek adják a tematikus kontextust. A hozzájuk kapcsolódó atomikus note-ok leaf chunk-ként pontosabb, részletesebb visszakeresést tesznek lehetővé.
A tag-szűrés a Qdrant payload-mezőkön keresztül valósítható meg: „csak a #VZ projekthez tartozó note-okban keress” típusú hibrid lekérdezések egyszerre alkalmaznak vektoros hasonlóság-keresést és metaadat-szűrést. Ez a megközelítés drasztikusan csökkenti az irreleváns találatokat nagy vault-okban, ahol sok projekt fut párhuzamosan.
A PARA struktúra és a RAG pipeline összekapcsolásának legnagyobb előnye: a keresés nem csak szöveg-szintű, hanem projekt-kontextus-tudatos. Egy kérdésre visszakapod a releváns atomikus note-ot és a projekt-kontextust, amelybe tartozik — nem izolált szövegrészletet.
Kérdések és válaszok
Hogyan kezeli a RAG pipeline az Obsidian frontmatter YAML mezőit?
A frontmatter mezőket (type, created, tags, up) érdemes külön metaadatként tárolni a vektorbázisban — ne kerüljenek bele a chunk szövegébe, mert zajt visznek az embeddingbe. A Qdrant payload mezőiben tárold őket: tag, dátum, parent-link, dokumentum-típus. Így szűréssel is lekérdezhetők: 'csak #VZ tagű note-ok között keress' típusú hibrid keresési feltételek válnak lehetővé.
Mi történik a wikilink referenciákkal indexeléskor?
A [[Note Name]] wikilink-ek két stratégiával kezelhetők: (1) eltávolítod indexelés előtt és csak a szöveget vektorizálod — egyszerűbb, de elveszíti a kapcsolati kontextust; (2) megőrzöd, és a Qdrant payload-ban tárolt link-gráf alapján retrieval-kor link-bővítést végzel — a találat mellé visszaadod a hivatkozott note-ok szövegét is. A második módszer jobb kontextust ad, de összetettebb pipeline-t igényel.
Milyen chunking stratégia illik legjobban az Obsidian PARA struktúrára?
A PARA-struktúra hierarchiájára a parent-child chunking illeszkedik legjobban: a Projects/Areas note-ok parent chunk-ként, a hozzájuk tartozó atomikus note-ok leaf chunk-ként kezelhetők. Ez lehetővé teszi, hogy egy kérdés a leaf szintű részletet hozza elő, de a parent kontextusa — a projekt kerete — is rendelkezésre álljon a generatív LLM számára. A header-alapú vágás (H2, H3 szinten) szintén jól működik Obsidian note-okhoz.
Mikor kell újra-indexelni a vaultot?
Háromféle trigger indokolja az újra-indexelést: (1) új note létrehozásakor — az inkrementális hash-alapú indexelő azonnal lefuttatható; (2) meglévő note lényeges átírásánál — a hash változás automatikusan kiváltja; (3) embedding modell cseréjekor — ekkor teljes re-index szükséges, mert a vektorok más dimenzióban keletkeznek. Ajánlott ütemezés: napi automatikus inkrementális futás, havi teljes konzisztencia-ellenőrzés.
Mi az optimális chunk-méret Obsidian note-okhoz?
Az Obsidian atomikus note-ok általában 200-600 szó közé esnek — ez 256-512 tokennek felel meg, ami ideális leaf chunk-méret. Hosszabb összefoglalók és szintézis-note-ok esetén 1024 token parent chunk javasolt. A rövid, fragmentált note-ok (50 szó alatt) általában nem érdemes önállóan indexelni — gyűjtsd össze őket tematikus parent chunk-ba, különben zajt visznek a vektorbázisba.
Hogyan integrálható az Ollama a vault-kereső pipeline-ba?
Az Ollama a generatív szintet adja: a retrieval (Qdrant + reranker) visszahozza a releváns note-részleteket, az Ollama modellje (pl. Llama 3, Mistral, Qwen2.5) ezekből szintetizálja a választ. Az integráció legegyszerűbb módja egy Python FastAPI wrapper, amely a search szerver találatait kontextusként fűzi az Ollama API kéréséhez. Előny: teljesen lokális, nulla API-cost, adatvédelmileg zárt rendszer.
Mi az MCP szerver szerepe az Obsidian RAG pipeline-ban?
Az MCP (Model Context Protocol) az Anthropic által definiált protokoll, amely lehetővé teszi, hogy Claude közvetlenül hívjon meg külső search eszközöket chat közben. Az Obsidian vault MCP-n keresztül csatlakoztatva azt jelenti, hogy Claude egy természetes párbeszédben képes lekérdezni a teljes vault-ot, és a találatok alapján kontextus-gazdag választ adni. Nem plugin, hanem architektúrális integráció — a Claude Desktop vagy Claude Code settings.json-ban konfigurálható.
Hogyan kezeli a pipeline a képeket és PDF-mellékleteket a vaultban?
A standard szöveges embedding pipeline kihagyja a bináris fájlokat — a képek és PDF-ek nem vektorizálódnak automatikusan. Megoldások: (1) a képek mellé írj Obsidian note-t leírással — ez indexelődik; (2) PDF-ekhez futass OCR + szöveg-extrakciót, majd add hozzá a chunking pipeline-hoz; (3) multimodális embedding modell (pl. CLIP) a képekhez — ez haladóbb infrastruktúrát igényel. A legtöbb PKM use case-re az első megoldás elegendő.
Mennyibe kerül a lokális Obsidian RAG pipeline futtatása?
A lokális pipeline fő előnye a nulla folyó API-cost. Egyszeri befektetés: a hardver (GPU ajánlott az embedding és reranker futtatásához, minimum 8 GB VRAM). Az elektromos fogyasztás valós cost, de tipikusan havi néhány ezer forint. Ha felhő-embeddingre (OpenAI text-embedding-3-small) váltasz az indexeléshez, egy 800 note-os vault első indexelése kb. 0.02-0.05 USD — elhanyagolható. A folyó query-k lokális embedding szerverrel ingyenesek.
Mi a különbség a Smart Connections plugin és a teljes RAG pipeline között keresési minőség szempontjából?
A Smart Connections plugin lokális embedding modellel (nomic-embed-text) végez szemantikus keresést közvetlenül az Obsidian-ban — telepítés után azonnal működik, nincs külön infrastruktúra. Hátránya: nincs reranker (a relevanciasorrend gyengébb), nincs cross-vault search API, és nem integrálható Claude MCP-vel. A teljes pipeline (Qdrant + reranker + FastAPI + MCP) komplexebb, de 30-50%-kal jobb retrieval recall-t ad, és tetszőleges LLM-ből elérhető — nem csak az Obsidian-on belülről.
