Obsidian + RAG: ваш приватний ChatGPT

Бази знань, особисті нотатки, технічна документація та робочі архіви постійно зростають. З часом знайти потрібну інформацію стає дедалі складніше, навіть якщо всі документи добре структуровані. Звичайний пошук працює лише за ключовими словами, тоді як сучасні задачі дедалі частіше потребують пошуку за змістом, аналізу взаємозв’язків між документами та узагальнення інформації з різних джерел.

Саме це забезпечує технологія Retrieval-Augmented Generation (RAG). Вона дозволяє великим мовним моделям (LLMs) працювати з вашою власною базою знань, знаходити релевантну інформацію, використовувати її як контекст і формувати відповіді, що ґрунтуються не на загальних знаннях моделі, а на ваших документах.

Однією з найкращих платформ для побудови локальної RAG-системи є Obsidian. Завдяки локальному зберіганню даних, відкритому формату Markdown та розвиненій екосистемі плагінів він дозволяє створити повністю приватну систему штучного інтелекту, яка працює без передачі інформації до хмарних сервісів.

Сучасні рішення для локального RAG вже не обмежуються лише Markdown-нотатками. Вони підтримують роботу з різноманітними форматами документів, забезпечуючи єдиний пошуковий простір для всієї бази знань. Завдяки цьому штучний інтелект може аналізувати як особисті записи, так і технічну документацію, книги, наукові статті чи корпоративні документи, зберігаючи повну конфіденційність даних.

Такий підхід буде корисним насамперед тим, хто регулярно працює з великими обсягами інформації. Науковці та дослідники зможуть швидко знаходити потрібні відомості серед тисяч статей, не перечитуючи їх щоразу заново. Юристи, аналітики та консультанти отримають інструмент для безпечної роботи з конфіденційною документацією без використання зовнішніх ШІ-сервісів. Розробники зможуть інтегрувати локальні LLMs у власний робочий процес для роботи з документацією, технічними нотатками та кодовою базою. А користувачі Obsidian – перетворити власне сховище знань із пасивного архіву на інтелектуального помічника, здатного знаходити приховані зв’язки між нотатками та відповідати на складні запитання.

У цій статті розглянемо, як побудувати локальну RAG-систему на базі Obsidian, які інструменти для цього існують, як організувати обробку різних форматів документів, обрати моделі ембеддингів і векторну базу даних, а також які архітектурні рішення забезпечують найкращу якість пошуку та генерації відповідей.

Теоретичний фундамент та архітектурна парадигма локального RAG

Впровадження RAG у локальне середовище Obsidian базується на принципі суверенітету даних. На відміну від хмарних рішень, локальна система виконує всі етапи конвеєра – від парсингу документів до векторного пошуку та генерації відповіді – безпосередньо на апаратному забезпеченні користувача. Це критично для фахівців, які працюють з конфіденційною інформацією, медичними даними або інтелектуальною власністю.

Архітектурно локальний RAG складається з кількох критичних вузлів, взаємодія яких визначає точність та швидкість системи. Першим етапом є вилучення тексту та структурування даних, де Markdown-файли, PDF та офісні документи перетворюються на фрагменти тексту, придатні для обробки моделями ембеддінгів. Наступним кроком є семантичне кодування, де текстові фрагменти трансформуються у високорозмірні вектори. Наприклад, модель BGE-M3 створює 1024-вимірні вектори, що дозволяють фіксувати не лише ключові слова, а й глибокі семантичні зв’язки та контекстуальні відтінки.

Пошук релевантної інформації базується на математичному розрахунку косинусної подібності між вектором запиту та векторами в базі даних. Математично це виражається через скалярний добуток векторів $\mathbf{A}$ та $\mathbf{B}$, поділений на добуток їхніх норм:

$$\text{similarity} = \cos(\theta) = \frac{\sum_{i=1}^{n} A_i B_i}{\sqrt{\sum_{i=1}^{n} A_i^2} \sqrt{\sum_{i=1}^{n} B_i^2}}$$

Ця метрика дозволяє системі знаходити відповіді навіть у тих випадках, коли запит сформульовано іншими словами, ніж оригінальний текст у нотатках.

Порівняння архітектурних рішень для локального RAG

Для вибору оптимальної стратегії необхідно оцінити доступні інструменти за критеріями продуктивності, підтримки форматів та складності налаштування.

Обробка Markdown-нотаток. Структурна перевага Obsidian

Markdown є рідним форматом Obsidian, що дає значну перевагу при побудові RAG-систем. Однак просте зчитування тексту є недостатнім для якісної генерації. Ефективна система повинна враховувати специфічну топологію Obsidian, яка включає вікі-посилання, ієрархію тегів та метадані у форматі YAML (frontmatter).

Стратегії інтелектуального чанкінгу

Чанкінг (chunking), або розбиття тексту на фрагменти, є етапом, де закладається якість майбутнього пошуку. Використання фіксованого розміру фрагментів (наприклад, по 512 токенів) часто розриває логічні зв’язки. Для Obsidian найбільш ефективною є стратегія, що враховує структуру заголовків (heading-aware chunking). Фрагмент повинен відповідати одній завершеній думці, зазвичай обмеженій заголовками другого або третього рівнів (H2, H3).

Система в ідеалі повинна реалізовувати наступні принципи:

1. Збереження контексту заголовків: кожен фрагмент тексту повинен нести в собі метадані про всі заголовки вищого рівня. Це дозволяє моделі розуміти, що абзац у розділі "Методологія" стосується саме "Проєкту Фенікс", навіть якщо назва проєкту не згадується безпосередньо в тексті фрагмента.
2. Обробка вікі-посилань: вікі-посилання є критичними для GraphRAG. Системні плагіни, такі як Neural Composer або ObsidianRAG, використовують ці посилання для побудови графа знань. Це дозволяє реалізувати пошук "через один-два кроки", коли відповідь на запит формується не лише на основі тексту знайденої нотатки, а й на основі контексту пов’язаних документів.
3. Валідація та фільтрація: перед індексацією рекомендується видаляти фрагменти, що складаються переважно з пробілів або містять менше 50 символів, щоб уникнути "шуму" в результатах пошуку.

Метадані та семантична вага

Використання YAML-метаданих дозволяє впроваджувати фільтрацію на етапі пошуку. Наприклад, поле status: archived може автоматично виключати нотатку з активного RAG-контексту, а поле type: MOC (Map of Content) може отримувати вищу вагу при ранжуванні результатів.

Складні формати документів: PDF та OCR-конвеєри

Інтеграція PDF-файлів у базу знань Obsidian є одним із найбільших викликів через специфіку формату, який орієнтований на візуальне відображення, а не на структурну логіку. Для вирішення цього завдання в екосистемі Obsidian існують три основні підходи.

Пряма екстракція та повнотекстовий пошук

Плагіни на кшталт Text Extractor використовують бібліотеки Tesseract.js для вилучення тексту. Цей метод забезпечує базовий рівень пошуку через плагін Omnisearch, але має суттєві обмеження: він часто не справляється з багатоколонковими верстками та складними таблицями.

Більш сучасним підходом є використання спеціалізованих OCR-сервісів. Наприклад, плагін OCR Extractor дозволяє інтегрувати Mistral AI OCR, який демонструє високу точність при вартості близько 2 доларів за 1000 сторінок. Результат екстракції зберігається безпосередньо в Obsidian у вигляді розгорнутого Callout-блоку під PDF-вкладенням, що робить текст доступним для вбудованого пошуку та локальних RAG-двигунів без необхідності повторного парсингу.

Глибоке анотування та PDF++

Для дослідницької роботи критично важливо не просто проіндексувати PDF, а мати можливість посилатися на конкретні фрагменти. Плагіни PDF++ та Annotator дозволяють створювати "глибокі посилання" (deep links) на конкретні сторінки та виділення в PDF. При використанні RAG це означає, що ШІ може згенерувати відповідь і надати пряме посилання, яке відкриє PDF-файл саме на тій цитаті, яка була використана.

Обробка документів Word та OpenDocument

Документи форматів Word (DOCX) та OpenDocument Text (ODT) вимагають відмінних від PDF підходів, оскільки вони базуються на XML-структурі, що теоретично дозволяє краще зберігати логіку документа, але на практиці стикається з труднощами локального парсингу.

Технічні аспекти парсингу DOCX

На відміну від PDF, DOCX є архівом ZIP, що містить word/document.xml. Сучасні парсери, такі як LlamaParse, використовують цю XML-структуру для точного вилучення таблиць та вкладених списків. Це дозволяє уникнути проблем зі складним форматуванням, де візуальні межі клітинок таблиці у PDF часто розмиваються для алгоритмів розпізнавання.

Для локального RAG в Obsidian підтримка DOCX зазвичай реалізується через зовнішні сервери (наприклад, LightRAG сервер у Neural Composer) або через конвертацію у Markdown перед індексацією. Використання бібліотеки pandoc залишається золотим стандартом для пакетного перетворення DOCX у "чистий" Markdown, який найкраще сприймається локальними LLM.

Труднощі та їх рішення для формату ODT

Формат ODT часто є "сліпою зоною" для більшості плагінів Obsidian. Нативної підтримки ODT у Smart Connections або Neural Composer станом на початок 2026 року немає. Користувачі, чия база знань містить велику кількість ODT-файлів, змушені використовувати сторонні інструменти для підготовки даних.

Одним із найбільш ефективних локальних рішень є утиліта Jimmy (marph91/jimmy), яка спеціалізується на конвертації ODT у Markdown. Хоча LibreOffice 26.2 додав функцію "Зберегти як Markdown", користувачі часто повідомляють про помилки у форматуванні заголовків та зайве виділення тексту жирним шрифтом, що може негативно вплинути на якість ембеддінгів. Використання спеціалізованих конвертерів або інструмента LiteParse, який автоматично конвертує офісні документи у PDF через LibreOffice перед парсингом, є більш стабільним шляхом для RAG-конвеєра.

Використання Binary File Manager

Для тих, хто не хоче конвертувати всі файли, плагін Binary File Manager пропонує стратегію метаданих. Він автоматично створює Markdown-файл для кожного виявленого бінарного файлу (PDF, DOCX, ODT). У цей файл можна додати опис, теги та посилання. Хоча це не забезпечує повнотекстового індексування вмісту ODT, це дозволяє локальному RAG принаймні "знати" про існування документа та знаходити його за метаданими.

Векторна інфраструктура та вибір локальних моделей

Продуктивність RAG-системи в Obsidian безпосередньо залежить від обраної моделі ембеддінгів та векторної бази даних. Для локальних систем обмеженням часто виступає обсяг відеопам’яті (VRAM) та швидкість дискових операцій.

Порівняння моделей ембеддінгів для локального використання

Вибір моделі визначає розмірність векторного простору та здатність системи до багатомовності.

Для користувачів на Apple Silicon (M1/M2/M3) або системах з картами NVIDIA RTX рекомендується використовувати nomic-embed-text через Ollama. Це забезпечує стабільну роботу індексації навіть для великих сховищ (понад 10 000 нотаток), запобігаючи таймаутам, які часто виникають при використанні більш важких моделей на кшталт BGE-M3 на мобільних процесорах.

Векторні бази даних: DuckDB vs LanceDB

Локальні плагіни Obsidian зазвичай використовують вбудовані векторні сховища, щоб уникнути встановлення складних баз даних на кшталт Pinecone або Milvus.

• DuckDB з розширенням VSS: використовується в кастомних рішеннях та деяких плагінах для ефективного зберігання метаданих нотаток та їх векторних представлень в одному файлі .duckdb. Це дозволяє виконувати SQL-запити, що поєднують семантичний пошук з фільтрацією за тегами.
• LanceDB: використовується в AnythingLLM та архітектурах на базі Python. Вона оптимізована для роботи з великими обсягами даних безпосередньо на диску, що критично для систем, де індекс не поміщається в оперативну пам’ять.

Глибокий аналіз інструментарію: Neural Composer та LightRAG

Neural Composer представляє собою вершину розвитку RAG для Obsidian у 2026 році. Його ключовою відмінністю є використання LightRAG – графової системи RAG, яка замість простого пошуку за подібністю будує складний граф сутностей та зв’язків.

Механізм побудови Knowledge Graph

При індексації папки (включаючи PDF та DOCX) Neural Composer використовує LLM для вилучення сутностей (наприклад, "Проєкт", "Методологія", "Автор") та визначення типів зв’язків між ними ("спричиняє", "базується на", "заперечує"). Це дозволяє системі відповідати на синтетичні запити, такі як: "Порівняй підходи до управління часом у документах PDF з моїми власними нотатками за минулий місяць".

Для якісної екстракції графа необхідні моделі з кількістю параметрів від 14B (наприклад, Qwen2.5 14B). Моделі меншого розміру (3B-7B) часто створюють "брудні" графи з нечіткими зв’язками, що нівелює переваги графового підходу.

Оптимізація для великих сховищ (9000+ PDF)

При роботі з екстремально великими базами документів (наприклад, 9000 PDF-файлів) стандартні плагіни Obsidian можуть спричиняти збої через обмеження пам’яті Electron-процесу. Neural Composer вирішує цю проблему шляхом винесення індексації в окремий Python-процес. Це гарантує, що інтерфейс Obsidian залишається чуйним, поки фоновий сервер обробляє важкі файли за допомогою CUDA на відеокартах типу RTX 3090. При роботі на механічних дисках (HDD) рекомендується встановлювати MAX_PARALLEL_INSERT=1 у налаштуваннях .env плагіна, щоб уникнути критичного навантаження на диск через постійні операції пошуку секторів.

Зовнішні екосистеми: AnythingLLM та PrivateGPT

Якщо можливостей вбудованих плагінів недостатньо, користувачі звертаються до зовнішніх систем, які підключаються до папки Obsidian як до джерела даних.

AnythingLLM: універсальний локальний десктоп

AnythingLLM пропонує найбільш дружній інтерфейс для користувачів, які не хочуть працювати з терміналом. Він підтримує "робочі простори" (Workspaces), де можна комбінувати нотатки Obsidian з відео транскриптами YouTube, веб-сторінками та документами Word.

Ключові особливості AnythingLLM для Obsidian:

• Автоматичне розпізнавання папок: можливість вибрати цілу папку з підпапками для рекурсивної індексації.
• Керування вікном контексту: користувач може вручну встановити кількість фрагментів (context snippets), що передаються моделі (зазвичай 4-6 для балансу точності та шуму).
• Гібридний режим: використання вбудованого векторного двигуна LanceDB, який забезпечує високу продуктивність на звичайному залізі.

PrivateGPT: конфіденційність корпоративного рівня

PrivateGPT побудований на базі LlamaIndex і орієнтований на розробників та організації з жорсткими вимогами до безпеки. Він підтримує складні конвеєри інгесту (simple, batch, parallel), що дозволяє максимально ефективно використовувати багатоядерні процесори при початковій індексації бази знань.

PrivateGPT особливо сильний у підтримці різноманітних форматів: окрім стандартних PDF та DOCX, він "з коробки" підтримує .epub, .ipynb, .json та .mbox. Для формату ODT він використовує ті ж механізми, що і для текстових файлів, але за потреби дозволяє додавати кастомні завантажувачі через Python-інтерфейс.

Сучасні техніки покращення релевантності

У 2026 році ефективність RAG визначається не лише пошуком, а й етапами до- та після-обробки.

Локальне переранжування (Local Reranking)

Семантичний пошук часто повертає фрагменти, які є математично близькими, але контекстуально нерелевантними. Впровадження локального переранжувальника (reranker), такого як BAAI/bge-reranker-v2-m3, дозволяє значно підвищити якість відповідей. Система спочатку знаходить 20-50 кандидатів за допомогою швидкого векторного пошуку, а потім використовує більш важку модель для їхнього точного ранжування. Цей процес додає лише 100-500 мс до часу відповіді, але радикально зменшує кількість галюцинацій.

Цитування та петля "Open in Obsidian"

Для професійного використання RAG-система повинна надавати докази своїх тверджень. Найкращі реалізації (наприклад, Vault RAG або EZRAG) включають у відповідь ШІ прямі посилання на джерела. За допомогою протоколу URI Obsidian (obsidian://open?vault=...&file=...) відповідь чат-бота стає інтерактивною: клік на цитату миттєво відкриває відповідну нотатку або документ у самому Obsidian, перетворюючи ШІ з простого генератора тексту на потужний інструмент навігації по базі знань.

Гібридний пошук (Hybrid Search)

Комбінація векторної схожості (60%) та ключових слів через алгоритм BM25 (40%) дозволяє системі бути гнучкою. Векторний пошук знаходить ідеї, а BM25 гарантує, що специфічні терміни, абревіатури або власні імена, які можуть бути відсутні у словнику моделі ембеддінгів, все одно будуть знайдені.

Вимоги до апаратного забезпечення та продуктивність

Локальний RAG висуває високі вимоги до компонентів ПК. Для комфортної роботи з базою знань, що містить велику кількість бінарних документів, рекомендуються наступні конфігурації.

Використання Apple Silicon є особливо вигідним завдяки об’єднаній пам’яті (Unified Memory), що дозволяє запускати моделі з великою кількістю параметрів (наприклад, 14B-20B) навіть на ноутбуках, де стандартні відеокарти ПК мали б обмеження у 8GB VRAM.

Висновки та рекомендації

Побудова локальної системи RAG на базі Obsidian є багатошаровим завданням, успіх якого залежить від якості підготовки даних. Для роботи з Markdown-нотатками критичним є впровадження графових структур, які відображають інтелектуальну топологію бази знань. При роботі з PDF необхідно орієнтуватися на інструменти з підтримкою візуального контексту та глибоких посилань, що забезпечує верифікованість відповідей ШІ.

Обробка форматів DOCX та ODT залишається найбільш трудомісткою частиною конвеєра, що вимагає або використання просунутих XML-парсерів, або попередньої пакетної конвертації у Markdown. Найбільш перспективним рішенням на 2026 рік є використання плагінів на базі LightRAG (Neural Composer), які об’єднують векторну близькість із потужністю графів знань.

Для професійних користувачів рекомендується:

1. Стандартизація чанкінгу: Використання фрагментів розміром близько 2000 символів з перекриттям у 15% та обов’язковим збереженням ієрархії заголовків.
2. Модельна ієрархія: Використання легких моделей для ембеддінгів (Nomic) та потужних моделей для генерації та переранжування (Qwen/Llama 14B+).
3. Гібридна стратегія: Використання Obsidian як основного інтерфейсу, але за потреби залучення зовнішніх систем типу AnythingLLM для первинної обробки гігантських масивів бінарних даних.

Впровадження цих технологій дозволяє перетворити Obsidian з пасивного цифрового архіву на повноцінного інтелектуального партнера, здатного до глибокого аналізу та синтезу персональних знань у повністю приватному режимі.

Олександр Славінський

Часті запитання:

1. Чи безпечно використовувати локальний RAG для конфіденційних даних? Так, це одна з головних переваг локального RAG. Оскільки вся архітектура (від векторної бази даних до мовної моделі) працює суто на вашому залізі, дані не передаються на зовнішні сервери чи хмарні API. Ви повністю зберігаєте суверенітет над своєю інформацією.

2. Чи потрібне надпотужне "залізо" для такої системи? Це залежить від завдань. Для базової роботи з нотатками достатньо сучасного процесора та 8-16 ГБ оперативної пам’яті. Однак для комфортної індексації великих архівів (9000+ PDF) та роботи з графовими структурами (GraphRAG) рекомендується відеокарта з 16 ГБ+ VRAM (наприклад, серії RTX 3090/4090) або пристрої Apple Silicon з об’єднаною пам’яттю.

3. У чому головна відмінність між векторним пошуком та GraphRAG? Стандартний векторний пошук шукає інформацію за "схожістю" контексту, тоді як GraphRAG будує карту зв’язків між сутностями. Це дозволяє ШІ не просто видавати фрагменти тексту, а "розуміти", як різні теми, автори чи проєкти пов’язані між собою в межах вашої бази знань.

4. Які формати документів підтримуються найкраще? Markdown є рідним форматом Obsidian, тому він індексується найшвидше і найякісніше. PDF, DOCX та ODT вимагають попередньої обробки – екстракції тексту або конвертації, щоб система могла "читати" їх без помилок форматування.

5. Що робити, якщо система "гальмує" при індексації великої бази? При роботі з дуже великими сховищами важливо виносити процес індексації в окремий фоновий Python-процес, щоб не блокувати роботу основного інтерфейсу Obsidian. Також можна обмежити паралельність операцій (MAX_PARALLEL_INSERT=1), щоб знизити навантаження на диск.