YaGo: как идея бесплатного self-hosted Tavily API привела к возрождению YaCy
Всё началось с практической задачи, а не с желания создать "поисковик нового поколения". Для собственных рабочих и личных AI-проектов мне понадобился быстрый локальный сервис, который мог бы выступать как self-hosted поисковик и предоставлять совместимый с Tavily API интерфейс. Хотелось избавиться от оплаты за каждый запрос, не отправлять рабочие данные во внешний сервис и самостоятельно управлять индексом.
На первый взгляд решение казалось очевидным: поднять YaCy. Когда-то я уже запускал его ноду и хорошо помнил сильные стороны проекта - собственный краулер, индекс, поисковый сервер и возможность обмениваться данными с другими узлами. Но практический опыт оказался неоднозначным. Java-процесс требовал немало памяти, а на моей конфигурации один поисковый запрос занимал около шести секунд.
Для человека это просто небольшая задержка. Для AI-агента, который последовательно выполняет несколько поисков, уточняет запросы, извлекает страницы и повторяет процедуру, ситуация меняется радикально. Десять обращений к поиску и extract легко превращаются в минуту ожидания - ещё до того, как к работе приступит языковая модель.
Почему понадобился собственный API
Типичный агентский сценарий состоит из нескольких этапов:
- отправить поисковый запрос;
- получить набор кандидатов;
- переформулировать запрос;
- извлечь содержимое выбранных страниц;
- при необходимости запустить ограниченный crawl или построить карту сайта;
- повторить цикл, пока не будет собрано достаточно фактов.
Именно поэтому меня интересовал не пользовательский портал с красивой главной страницей, а машинный интерфейс для агентов. Tavily оказался удобной точкой совместимости: его контракт уже поддерживают многие фреймворки, а методы `/search`, `/extract`, `/crawl` и `/map` покрывают значительную часть исследовательских задач.
Задача выглядела как поиск хорошего бесплатного API поиска, но быстро стало понятно: одной HTTP-обёртки недостаточно. Если оставить внешний движок в основе, сохраняются ограничения провайдера, зависимость от его индекса и риск недоступности. Поэтому появился YaGo - самостоятельная поисковая нода на Go, использующая сетевую совместимость с YaCy, но построенная вокруг более лёгкой архитектуры.
О развитии этой идеи и устройстве проекта подробно рассказывается в материале о [self-hosted поисковике для AI-агентов](https://habr.com/ru/articles/1060298/?utm_campaign=1060298&utm_source=habrahabr&utm_medium=rss).
Что осталось от YaCy
Я не стал делать очередной метапоиск поверх нескольких внешних систем. Такой подход быстро запускается, но не решает главную проблему: выдача, лимиты и доступность по-прежнему находятся под чужим контролем. Другой вариант - собрать crawler вместе с Elasticsearch и самостоятельно реализовать весь жизненный цикл документа. Это дало бы свободу, но потребовало бы заново проектировать сетевую модель и совместимость.
В итоге от YaCy была сохранена сама идея распределённой поисковой ноды и соответствующий протокол, а реализация переписана на Go. В новой системе используются отдельный краулер, embedded-хранилище, API и самостоятельный ranking pipeline. Для хранения данных применяются Bleve и bbolt, для взаимодействия между компонентами - gRPC.
Так появился проект, который можно рассматривать как современный Tavily API аналог для локального развёртывания. Он не пытается полностью повторить историческую архитектуру YaCy, а берёт из неё наиболее полезную часть - модель самостоятельных узлов.
Индекс и релевантность
Собственный индекс - это не дополнительный режим, а фундамент всей системы. Без него невозможно контролировать полноту данных, скорость ответа и правила обновления документов. Однако построить индекс недостаточно: поисковик должен ещё и правильно ранжировать результаты.
В YaGo процесс разделён на несколько стадий. Сначала формируется широкий список кандидатов. Затем запрос расширяется с учётом словоформ и связанных терминов. Несколько наборов результатов объединяются, после чего система анализирует уже сами документы. Финальным этапом становится машинное ранжирование.
Вместо набора случайных коэффициентов используются классические методы information retrieval: BM25, анализ текста и подходы learning to rank, включая LambdaMART. Это позволяет постепенно улучшать выдачу на реальных данных, а не бесконечно подправлять параметры вручную.
При разработке я опирался не только на документацию библиотек, но и на научные публикации по полнотекстовому поиску, нормализации запросов и оценке релевантности. Такой подход сложнее, чем "добавить ещё один boost", зато даёт понятную основу для дальнейшего развития.
Краулер, хранилище и сетевой слой
Краулер оказался отдельной инженерной задачей. Нужно учитывать robots.txt, ограничивать глубину обхода, предотвращать дублирование страниц, различать HTTP- и HTTPS-версии и не превращать небольшой сервер в источник чрезмерной нагрузки для сайтов.
Важна и политика хранения. Диск не бесконечен, поэтому YaGo должен уметь контролировать размер индекса, удалять устаревшие документы и не сохранять лишнее содержимое там, где достаточно метаданных и фрагментов текста.
Сетевую часть также пришлось проектировать с учётом реальных условий. DHT нельзя воспринимать как магическую кнопку: при нестабильных соединениях, неполных таблицах маршрутизации и проблемных узлах поиск пиров требует диагностики. Поэтому особое внимание уделено журналированию и наблюдаемости - иначе понять причину проблем можно только методом случайного перебора.
Отдельно была сделана административная панель. Настройки краулера, состояние индекса, сетевые параметры и служебные операции должны находиться в очевидных местах, а не обнаруживаться после долгого изучения форумов и старых обсуждений.
Запуск и ограничения
Быстрый старт должен сводиться к запуску одной ноды, настройке адреса API и добавлению первых URL для обхода. При этом важно понимать, что "бесплатный" сервис не означает отсутствие затрат вообще. Провайдеру действительно не нужно платить за каждый запрос, но электричество, дисковое пространство, память и обслуживание остаются на стороне владельца.
YaGo не является универсальной заменой крупным поисковым системам. Он не обещает мгновенно построить глобальный индекс всего интернета и не скрывает стоимость самостоятельного хостинга. Это инструмент для контролируемых коллекций, локальных проектов, внутренних баз знаний и агентских сценариев, где особенно важны автономность и предсказуемость.
Полезный результат можно получить, если заранее определить область обхода: документация, технические сайты, внутренние ресурсы компании или ограниченный набор тематических площадок. В таких условиях собственный индекс часто оказывается практичнее универсального внешнего поиска.
Что получилось в итоге
Изначальная цель была довольно узкой: получить быстрый локальный endpoint, совместимый с Tavily, чтобы AI-агенты могли искать и извлекать информацию без обязательной зависимости от внешнего провайдера. Но в процессе выяснилось, что задача требует полноценного поискового движка - от краулера и хранения до ранжирования и распределённого взаимодействия.
Так YaGo стал не просто обёрткой API, а попыткой переосмыслить YaCy в более лёгком и удобном для современных сценариев виде. В нём сохранилась идея самостоятельной сетевой поисковой ноды, но исчезла необходимость тащить за собой тяжёлую JVM-архитектуру.
Если нужен поисковик для ИИ, работающий рядом с локальными моделями и агентами, такой подход особенно интересен: запросы остаются под собственным контролем, индекс можно адаптировать под конкретную предметную область, а API - встроить в существующий pipeline. Именно сочетание автономности, совместимого интерфейса и управляемой выдачи стало главным итогом проекта.
При этом YaCy не исчез окончательно. Его протокол, накопленный опыт и старые инженерные решения оказались полезной базой для новой реализации. В некотором смысле YaGo - это не буквальное продолжение проекта, а его практическая реинкарнация, рассчитанная на современные AI-нагрузки и локальное развёртывание. Подробности архитектуры, эксперименты с релевантностью и дальнейшие планы проекта собраны в [описании YaGo и его поискового API](https://habr.com/ru/articles/1060298/?utm_campaign=1060298&utm_source=habrahabr&utm_medium=rss).
