Проект YaGo родился из практической потребности: автору требовался быстрый локальный API, совместимый с Tavily, для собственных AI-агентов, которые выполняют циклы поиска, уточнения запросов и извлечения содержимого страниц. Использование оригинального YaCy на Java показало неудовлетворительную производительность — около шести секунд на один поисковый запрос на тестовом стенде. Для агента, делающего десять обращений к поиску и extract подряд, это превращается в минуту чистого ожидания ещё до запуска модели. Tavily, напротив, предлагает удобный контракт, который уже понимают многие agent frameworks, включая endpoints /search, /extract, /crawl и /map. Однако зависимость от внешнего сервиса с тарификацией за каждый запрос и невозможность контролировать содержимое индекса стали ключевыми ограничениями. Так возникла идея взять от YaCy самое ценное — его peer-протокол и совместимость — и пересобрать всё остальное на современном стеке.

YaGo не является форком YaCy с новым интерфейсом или набором плагинов. От оригинального проекта заимствуются только сетевые протоколы: peer identity и seed lists, endpoints /yacy/hello.html и /yacy/query.html, обмен RWI (Reverse Word Index) и метаданными через transferRWI и transferURL, удалённый поиск по RWI, выбор узлов по DHT-кольцу, а также клиентские поверхности yacysearch.* и OpenSearch. Всё остальное — локальное хранилище, полнотекстовый индекс, краулер, ранжирование, админка, API, безопасность, метрики и процедура обновления — проектируется заново. Ключевой архитектурный принцип сформулирован так: YaCy RWI/DHT — это протокол обмена и совместимости, а Bleve с document vault — локальный поисковик. RWI хорош как общий сетевой формат для хешей слов, postings и URL metadata, но заставлять его работать как современный полнотекстовый движок нецелесообразно. Поэтому YaGo хранит YaCy-совместимый слой для peer-протокола, а локальную выдачу строит в отдельном индексе Bleve, что даёт BM25, поля, анализаторы, нормальные сниппеты и отдельный ranking pipeline.

Техническая реализация включает два основных процесса: yago-node (поисковая машина с документами, индексом, peer identity, DHT, поиском, API, порталом и админкой) и yago-crawler (расходный компонент, который ходит наружу, скачивает страницы, обрабатывает кодировки и при необходимости запускает Firefox). Для хранения используется embedded storage на базе bbolt, а для ранжирования — pipeline из современных работ по information retrieval, включая BM25 и LambdaMART. Вся архитектура написана на Go, что обеспечивает лёгкость и предсказуемость работы в отличие от тяжёлой Java-машины оригинального YaCy. Автор подчёркивает, что минимальная установка состоит из двух процессов, которые могут работать на одном сервере или быть разделены для масштабирования. При этом оригинальный YaCy никуда не исчезает — проект предлагает совместимый скелет, вокруг которого собраны новые внутренности.

История YaCy на русскоязычном рынке знакома многим разработчикам: на Хабре публиковались обзоры в 2011 и 2014 годах, а комментарии к ним часто содержали более полезную информацию, чем сами статьи. Пользователи, устанавливавшие ноду в виртуалку, быстро находили реальные проблемы: Java-процесс охотно ел память, глобальная выдача была медленной и не всегда убедительной, HTTP- и HTTPS-версии одной страницы могли приходить как два разных результата, русскоязычный индекс рос медленно, настройка краулера обнаруживалась не там, где её ожидали, а вокруг robots.txt, remote crawl и сетевого поведения хватало сюрпризов. Устройство DHT проще было вычитать из исходников, чем из документации. Эти старые вопросы хорошо легли поверх практической задачи автора YaGo: первый критерий был не романтическим, а сугубо прагматическим — локальный API должен быстро и предсказуемо отвечать агенту. Уже вокруг этого пришлось заново решить хранение, crawl, релевантность, совместимость, безопасность и эксплуатацию.

Для российского рынка, где вопросы импортозамещения и контроля над данными становятся всё более актуальными, появление self-hosted поискового решения с открытым протоколом и современной архитектурой может иметь значение. Коммерческие сервисы вроде Tavily или Google Custom Search требуют оплаты за запросы и передачи данных внешнему провайдеру, что не всегда приемлемо для корпоративных или исследовательских задач. YaGo предлагает альтернативу: разработчик может развернуть собственную поисковую ноду, контролировать индекс, настраивать ранжирование и не зависеть от внешних лимитов. При этом совместимость с YaCy позволяет войти в существующий swarm и обмениваться данными с Java-нодами, что расширяет возможности индексации без необходимости краулить всё самостоятельно. В комментариях к оригинальной публикации уже отметили, что такой подход напоминает идею «распределённого поисковика для своих», но с современным бэкендом.

Перспективы проекта YaGo пока остаются открытыми. Автору предстоит решить ряд вопросов: насколько стабильной будет работа в swarm с Java-нодами, как быстро можно будет нарастить русскоязычный индекс, какие сценарии использования окажутся наиболее востребованными. Также неясно, будет ли проект развиваться как open-source или останется нишевым инструментом для энтузиастов. Однако сама идея — взять проверенный протокол распределённого поиска и пересобрать его на современном стеке с акцентом на скорость и совместимость с AI-агентами — выглядит логичным шагом в эпоху, когда локальные AI-решения требуют быстрых и контролируемых источников данных. Возможно, YaGo станет тем самым «бесплатным Tavily», которого не хватало разработчикам, или, по крайней мере, покажет, как можно воскресить старые идеи с новой архитектурой.