Гибридный поиск по заметкам Obsidian в сервисе Obsync.

Как работает реализованный read‑model поиск сервиса Obsync: FTS, pg_trgm, ранжирование, matchedBy, REST API и MCP без отдельного поискового сервера.

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

В Obsync поиск перенесён на сервер, в read model. После синхронизации заметка разбирается на части: выделяются заголовок, путь, фрагмент, теги, ссылки, plain text и общий search_text. На основе этих данных строится search_vector, а режим fts_trgm ищет не просто подстроку, а релевантное совпадение.

Гибридный поиск в Obsync — это не обещание, что ИИ «всё поймёт». Это конкретная связка технологий: FTS отвечает за текстовую релевантность, pg_trgm помогает справляться с опечатками в заголовке и пути, свежесть правок влияет на ранг, а matchedBy показывает, где именно найдено совпадение.

Что вы получаете

В рамках экосистемы Obsync, контур Гибридный поиск включает значительные возможности:

  • Поиск по серверному индексу — не только через локальное приложение Obsidian.
  • Ранжирование по нескольким сигналам: FTS‑релевантность, похожесть заголовка или пути, свежесть документа.
  • Fuzzy‑поиск для заголовков и путей: заметку можно найти даже с неточной формулировкой, если запрос достаточно длинный.
  • matchedBy в ответе: видно, совпал заголовок, путь, общий текст, похожий заголовок или похожий путь.
  • rank в ответе: значения final, fts, trigram, recency помогают API‑клиенту или MCP‑агенту оценить качество выдачи.
  • Единый поиск для REST API и MCP‑инструмента obsync_search_notes; старые клиенты получают привычные поля.
  • Версионированный cursor для поисковой выдачи: результаты сортируются по rankKey, updatedAt и id, а не ломаются из‑за float‑ранга.
  • Контролируемые границы нагрузки: короткие запросы уходят в legacy‑ветку, ranked query получает statement timeout, лимит результатов остаётся ограниченным.

Для кого будет полезна функция

  • Для пользователей MCP‑клиентов: агент получает не хаос заметок, а нормальный инструмент поиска.
  • Для интеграций через REST API: CRM, n8n, Make, внутренние панели, скрипты, рабочие боты.
  • Для больших баз Obsidian, где важна релевантность, а не просто порядок обновлений.
  • Для командных и публикационных сценариев: один серверный индекс обслуживает несколько интерфейсов.
  • Для диагностики качества поиска: matchedBy и rank помогают понять, почему выбрана конкретная заметка.
  • Для будущего semantic/vector‑слоя: FTS + trigram дают базовую метрику качества — с ней потом можно сравнивать embeddings, не смешивая всё в первой версии.
Локальный поиск заставляет запускать Obsidian и часто сортирует не так, как надо внешнему инструменту. Гибридный поиск Obsync объединяет FTS, fuzzy‑совпадения по заголовку и пути, свежесть правок и объяснение matchedBy в одном серверном индексе.

Преимущества экосистемы Obsync

Гибридный поиск усиливает не какую‑то отдельную функцию, а весь серверный слой Obsync. Синхронизация передаёт изменения, read model преобразует markdown в удобный индекс, REST API и MCP работают с одной выдачей, а публикационные и входящие сценарии используют общую базу данных вместо разрозненных копий.

Для пользователя всё просто: заметка написана в Obsidian, синхронизирована на сервер, попала в read model и стала доступна внешним инструментам. Разработчику это даёт меньше интеграционных задач: не нужно отдельно извлекать markdown, чистить разметку, строить индекс, придумывать cursor и объяснять агенту, почему выбран конкретный файл.

Вернуться в журнал