Obsidian вместо RAG: когда простая база знаний выигрывает

Я несколько дней строил «правильную» базу знаний: RAG, индексы, будущие агенты, слои, поиск, архитектура на вырост.

Потом остановился и переехал в Obsidian.

Снаружи это выглядит как откат. Был замах на технологичную систему, а получилось: папки, Markdown-файлы, ссылки и локальное приложение. Но именно этот откат оказался полезным.

Проблема была не в RAG. Проблема была в том, что я начал строить инфраструктуру раньше, чем рабочий ритм.

Что пошло не туда

Сложная база знаний очень быстро начинает притворяться продуктом.

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

В какой-то момент я поймал себя на простой мысли: я уже обслуживаю систему, в которую ещё почти не пишу.

Для предпринимателя это плохой знак. База знаний нужна не для того, чтобы восхищаться схемой. Она нужна, чтобы каждый день фиксировать решения, отчёты, клиентские сигналы, идеи и выводы.

Если инструмент усложняет фиксацию мысли, он уже проигрывает.

Почему Obsidian сейчас сильнее

Obsidian выиграл не потому, что он идеален. Он выиграл потому, что снижает трение.

Открыл — написал. Файл остался файлом. Markdown понимает человек, редактор, Git и AI. Заметку можно связать с проектом, решением, отчётом, статьёй или задачей. Если завтра поменяется инструмент, текст не окажется заперт внутри чужого формата.

Для AI-ассистента это важнее, чем кажется. Ему нужна не «магическая память», а понятный слой источников:

• где лежит решение;
• какая версия актуальна;
• какой отчёт описывает день;
• где клиентский сигнал;
• что можно использовать в статье;
• что нельзя отдавать модели.

В статье «База знаний компании» я называю это слоем правды. Obsidian сам по себе его не создаёт, но даёт нормальную основу: сначала живые источники и дисциплина, потом умный поиск.

Где RAG всё равно нужен

RAG, embeddings и векторный поиск не стали плохими инструментами. Просто им рано быть первым шагом.

Они понадобятся, когда появится объём:

• много источников;
• разные уровни доступа;
• повторяемые вопросы;
• несколько интерфейсов;
• сценарии, где AI должен быстро находить фрагменты и показывать, на что опирается.

Но если живых заметок мало, а система уже требует поддержки, порядок действий перепутан.

Сначала нужно накопить то, что действительно стоит искать:

• решения;
• ежедневные отчёты;
• клиентские вопросы;
• рабочие правила;
• материалы для статей;
• описания процессов;
• зафиксированные ошибки.

Только после этого RAG становится усилителем, а не дорогой декорацией.

Что это значит для VAAI

Для VAAI это важный редакционный вывод.

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

Obsidian в этом смысле не «ещё один инструмент для заметок». Это временный, но рабочий фундамент для AI-помощника: база, которую можно читать, пополнять, версионировать и подключать к агентам.

Технически я использую Claude Code как помощника для структуры и сборки. Содержательно эта тема продолжает материалы про ИИ-агентов для бизнеса и про то, как ИИ-помощник должен видеть бизнес-сигналы.

Вывод

Сейчас мой критерий простой: база знаний должна быть такой, чтобы в неё хотелось писать каждый день.

Если она выдерживает ежедневные отчёты, решения и клиентские сигналы, её можно усиливать RAG, агентами и интерфейсами. Если не выдерживает — сложная архитектура только маскирует пустоту.

Начинать стоит не с самой умной системы, а с той, которая помогает не терять мысль сегодня.