Создаем Детерминированный Механизм Выявления Связей в Obsidian и Bases
Последние тренды ИИ в софте кажутся чем-то поистине магическим: мы уверенно движемся к системам, которые не просто говорят с нами, выдают нужную информацию или синтезируют новые идеи, а по сути думают за нас.
Но возникает один вопрос: если позволить им это делать, не несет ли это скрытых издержек?
Чтобы избавить вас от глубокого погружения в когнитивистику и нейробиологию, отвечу коротко — «да, несет». Чтение ИИ-саммари — это не мышление. Видеть связанные заметки — не то же самое, что эти связи создавать. Автоматическое тегирование заметок не заменит понимания того, «какие области сюда относятся».
Последние пару месяцев я выстраивал систему, цель которой — сохранить баланс. Систему, которая бы не просто создавала иллюзию порядка, но позволяла бы всем имеющимся у меня знаниям реально работать, а также находить неочевидные связи среди них. Удивительно, но AI и ML плагины для Obsidian (такие как Similarity или Similar Notes) не могут правдоподобно ответить на вопрос "какие ещё заметки возможно относятся в той, что у меня сейчас открыта?", несмотря на создание индексов, чанкинг и так далее.
Оказалось, AI с его "вероятностным" подходом, и не нужен. Obsidian и его плагин Bases могут быть базой для детерминированного решения задачи – а это значит результаты, которые можно 100% проверить, на которые можно положиться.
При условии, что вы готовы а) думать над тегами и б) погрузиться на продвинутый уровень Obsidian.
Внесём Ясность
Я не буду делать вид, что Bases превосходит Claude, натравленного на вашу базу знаний. Cowork не просто найдет заметку, которая «кажется связанной» – он просто ответит на вопрос, даже если вы ничего не линковали и не тегировали. Это реальная сила.
Но Оракул, отвечающий на вопросы – не имеет ничего общего с вашими знаниями. Теми, что у вас в голове, а не "на диске".
То, что дает описанный ниже сетап — совершенно другое: детерминированное, структурное отображение. Если вы проделали некоторую изначальную работу, Bases покажет вам связи, основанные на логике, которую вы можете прочитать и проверить. Ноль галлюцинаций. Никаких «почему он это выбрал?». Никаких подписок. Никакой отправки ваших личных мыслей через чужой API. Никаких сторонних ИИ-плагинов.
Но ясность на выходе требует усилий на входе. Вы расплачиваетесь собственной осознанностью каждый раз, когда ставите ссылку или тег.
Запомните эту мысль — скоро мы поймем, что эта "оплата" на самом деле "инвестиция".
Когнитивные процессы
Что я усвоил на опыте: в любой системе управления знаниями (PKM) я считаю и линкование заметок, и их тегирование когнитивными процессами, несущими «хорошую» ментальную нагрузку.
Проще говоря, перед тем как поставить тег, нужно подумать — и именно это размышление улучшает ваше понимание. Точно так же нужно подумать перед тем, как связать заметки ссылкой, — и это размышление очень ценно с когнитивной точки зрения.
Вот почему эти действия не должны автоматизироваться или исключаться.
Если вы чувствуете ментальное напряжение, если вам сложно подобрать тег для чего-либо — это как раз очень хороший сигнал. Сигнал того, что сейчас ваше мышление делает настоящую работу. Так же, как и формулирование ответа на вопрос "как именно эти два элемента связаны" перед тем как поставить очередную вики-ссылку.
Это один из ключевых принципов, делающих данный сетап по-настоящему ценным.
Сетап
- Теги (Tags) главный компонент для поддержания связей с самыми отдаленными уголками вашего Графа. Отвечают на вопрос
Какие темы с этим связаны?. Теги работают ровно как они и задумывались когда-то – как "ключевые слова", отражая только связанные темы (можно сказать, "что приходит на ум"). Например,#operations,#automation,#ai/agents,#business-development,#sales-enablement,#finance/investmentsи так далее. - Ссылки (Links) между заметками отвечают на вопрос
Как именно связаны две заметки?Как и тег, сама ссылка это уже результат ментальной работы. Вопрос "Как эти штуки связаны?" подразумевает что вы действительно подумаете над этим, а не просто вставите "См. также". - Папки (Folders) – опциональны. Но часто ответ на вопрос
Что это?тоже важен, поэтому в небольших сетапах за него могут отвечать именно папки — для каждого типа своя папка. Для больших коллекций, особенно с "объектно-ориентированными" заметками, свойствоТип:/Type:работает лучше. Например,"type: article","type: project","type: person","type: workflow"и так далее.
Вот и всё. Никаких навороченных структур — но и никаких пересечений функций между компонентами. Я не использую ссылки, чтобы объяснить принадлежность к теме или к типу. Теги же не отражают суть (Что это?) — у меня нет тега #project. Теги также не отвечают на вопрос Какой тут статус? — для этого есть свойства (properties).
Волшебная боковая панель (Sidebar)
Теперь поговорим о плагине Bases в Obsidian. По факту, ваша коллекция заметок это уже база данных. Bases в этом случае это окошки в неё, которые показывают что-то подходящее под определённые критерии. Например, у вас может быть отдельная база «Проекты», которая покажет все заметки типа project вместе с другими релевантными свойствами, или база «Путешествия» со всеми поездками из папки /Trips, и так далее.
Но я узнал вот что (и для многих это неочевидно): Obsidian позволяет перетащить любую настроенную базу на любую боковую панель — левую или правую — чтобы сохранить её связь с заметкой, открытой в основной части интерфейса.
Примечание к мобильным устройствам: В десктопной версии это работает интуитивно, а вот для мобильных устройств понадобится плагин Mobile Sidebar Notes, который позволяет делать то же самое на iPhone и iPad. Поистине киллер-фича для этого сетапа, если iPad — ваш основной рабочий инструмент.
Настоящая магия этой функции раскрывается в запросах Bases с использованием this.file. Тех самых запросах, которые позволяют ссылаться на текущий открытый файл, чтобы выводить актуальную именно для него информацию.
Идея в том, что когда вы перетаскиваете такую базу на боковую панель, она будет показывать результаты, основанные на той заметке, которая открыта прямо сейчас.
Если вы настроите фильтр базы как file.name.contains(this.file.name), то при переносе базы в сайдбар она покажет все заметки, в названии которых содержится название текущего открытого файла. Что-то вроде несвязанных упоминаний (unlinked mentions), но только для имен файлов.
Но наш сетап — это не просто жонглирование названиями. Все немного... сложнее.
Запрос 1: Связанные файлы
По умолчанию Obsidian разделяет обратные ссылки (backlinks) и исходящие (outgoing links) на две разные панели. Но когда я читаю заметку, я хочу видеть всё, с чем она связана, в обоих направлениях, в одном месте.
Я, конечно, могу залипнуть в граф, разглядывая узлы и линии (под расслабляющую музыку). Но есть вариант получше — создать короткий запрос для базы из двух строк:
file.hasLink(this.file) this.file.hasLink(file)
Первая строка выводит каждый файл, который ссылается на текущую заметку (ваши бэклинки). Вторая выводит каждый файл, на который ссылается текущая заметка (исходящие). Объедините их в одной базе, перетащите на боковую панель, и у вас появится единая панель всех связей.
Это минимально-жизнеспособная версия магии. Собирается за 30 секунд. Меняет само ощущение от приложения.
Запрос 2: Файлы, содержащие в названии имя файла
Кажется глупостью, пока не попробуешь.
file.name.contains(this.file.name)
Запрос выводит каждую заметку, чей заголовок содержит заголовок текущей заметки как подстроку. Я не сразу понял, зачем мне это нужно: это идеально работает для концепций и дат.
К заметке про Google панель покажет все заметки, где есть Google в названии – Google Workspace for businesses, Google revenue report 2024, Google Gemini 3.1 release notes, и так далее. Понятно, что пример примитивный – реальная польза, когда панель выводит более сложные понятия, которые вы подзабыли (например внезапный Sales Training, или заметку про клиента).
Это также блестяще работает для дат. Если вы стабильно используете формат yyyy-mm-dd в именах файлов, то для ежедневной заметки 2026-05-19 боковая панель покажет все файлы, в названии которых есть 2026-05-19:
Запрос 3: Заметки с общими тегами
Бэклинки срабатывают только если вы явно поставили ссылку. Но часто две заметки могут принадлежать одной теме, иметь один и тот же контекст — просто у вас не дошли руки их слинковать, или — что интереснее — связь раньше не была очевидна.
В моем сетапе именно теги несут этот сигнал.
Первая версия запроса, с которым я работал — file.tags.containsAny(this.file.tags) — возвращала все заметки, у которых совпадает хотя бы один тег из всех, принадлежащих основной заметке. Если у неё 3 или 4 тега, панель превращалась в неюзабельный ужас. Поэтому я ужесточил фильтр:
file.tags.filter(this.file.tags.contains(value)).length >= 2
Этот запрос перебирает теги файлов, оставляет только те, которые также есть в текущей заметке, и требует наличия минимум двух совпадений.
Допустим, у вас есть заметка с тегами #cognition, #pkm, #software. Запрос покажет вам все заметки, тегированные как:
#pkmи#software#pkmи#cognition#cognitionи#software- и, конечно, те, в которых присутствуют все три тега
Именно здесь обитают неожиданные связи. Сотни таких связей. Обратите внимание на логическую силу именно комбинации двух тегов – смотреть на все заметки отдельно "про Software" или отдельно "про PKM" не имеет пользы. Сила тегов именно в возможности их комбинировать — конкретно "PKM software", конкретно "Cognition in PKM" — вот что релевантно в заметке, которая имеет все три тега.
Пожалуй, это самая фундаментальная часть системы. Один этот запрос извлек на свет столько неожиданных связей, что я даже не могу ни с чем это сравнить. Если вы делаете свою «работу по тегированию», этот запрос поднимет релевантные вещи из самых тёмных уголков вашего хранилища, будьте уверены.
Собираем всё вместе: Панель связанных заметок
Все эти запросы — не отдельные трюки, а единая система. Объедините их в одну базу (Base) и либо перетащите ее на боковую панель, либо напрямую встройте в заметку с помощью ![[]].
Объединенная база считывает четыре сигнала — входящие ссылки, исходящие ссылки, общие теги и совпадения в названиях — и показывает всё, что заслуживает места рядом с этой заметкой хотя бы по одной из этих осей.
В какой-то степени, это как ездить на механике, когда все пересели на унылые вариаторы — полностью ручное обнаружение заметок. Каждая потенциальная связь, которая всплывает — это связь, о которой вы когда-то подумали: явно написав ссылку, выбрав тег или дав имя файлу. Система не строит догадок. Она лишь читает вслух то, что вы сами построили.
Звучит как ограничение. На самом деле в этом-то и весь смысл.
Формула релевантности
Финальный штрих – называние вещей своими именами :) В больших коллекциях при множестве совпадений, мне хотелось внятно видеть степень релевантности заметок. Если заметки связаны напрямую, это одно, но если высоко релевантны, но пока не связаны, это другое.
Эту задачу можно решить через создание кастомной формулы в базе:
if(file.hasLink(this.file) || this.file.hasLink(file) || file.name.contains(this.file.name), "direct", if(file.tags.filter(this.file.tags.contains(value)).length >= 3, "very high", if(file.tags.filter(this.file.tags.contains(value)).length >= 2, "high", "low")))
Вы просто создаете новое поле типа formula в нужной базе (в моём случае она называется Related Notes.base), и вставляете вот это в поле формулы. Логика формулы следующая:
- Прямая связь: поле примет это значение, когда заметки уже связаны (или есть совпадение по имени). Сюда мы, в общем-то, стремимся.
- Очень высокая релевантность: когда совпадает 3 и более тегов. Это либо 100%-ная связь, которую вы не сделали, либо полные дубликаты заметок.
- Высокая релевантность: когда совпадает как минимум 2 тега. Часто самые интересные кандидаты здесь.
- Возможная (низкая) релевантность: когда совпадает только один тег.
Дальше вы настраиваете группировку по этому полю, и вуаля — будете видеть, какие конкретно заметки связаны напрямую, какие являются потенциалом для связи, а какие отдаленно напоминают, совпадая лишь по одному тегу. Иногда и их полезно проглядеть. Или же наоборот, вы захотите отфильтровать именно по релевантности, убрав всё, что "low".
В моём случае я также настроил дополнительное представление с группировкой по типу: таким образом видно что конкретно релевантно – возможно наблюдения, идеи, проекты, а может быть люди или вообще места.
Понимание нельзя делегировать
Всё это работает, если вы линкуете и ставите теги осознанно. Система не сможет компенсировать неряшливую структуру. Если ваши теги непоследовательны (здесь #mgmt, там #management), если вы забываете ставить ссылки, если ваша таксономия плывет — Bases отразит ровно то, что вы в нее заложили. ИИ прикрывает все эти дыры статистическими догадками. Bases так не делает – и не должен. Когда боковая панель пуста, это тоже информация: ваша структура слаба. Bases скажет как есть.
Я не против ИИ в приложениях для управления знаниями. Я против той тихой сделки, которую он предлагает: откажись от размышлений, но сохрани видимость наличия мыслей. В вашей собственной системе знаний работа по выстраиванию структуры не подлежит делегированию. Делегируя её, вы получаете результат без самого когнитивного события (доказательством которого этот результат и должен был стать).
Ссылка — это работа. Тег — это работа. Эта работа и есть ваш личный апгрейд.
Описанный в статье сетап не заменяет ничего из вышеперечисленного — он дает этому место, чтобы проявиться. Вы сознательно строите структуру, и система отражает ее именно тогда, когда вам это нужно.
А побочный эффект заключается в том, что вы действительно начинаете понимать свои собственные заметки.
P.S. Если вам понравилась тема на скриншотах — можете свободно забрать ее с GitHub, или в официальном магазине тем – ищите Nu Ayu.