Skip to main content
Antigravity 3.5 FlashTavilyRAG

Antigravity 3.5 Flash и Tavily: выводы из тестов

Первые пользовательские тесты Antigravity 3.5 Flash хвалят модель за сильное архитектурное планирование, но параллельно всплыл другой вывод: Tavily может подводить в RAG, особенно на неанглийских запросах. Для AI automation это важно, потому что ошибка часто не в модели, а в сломанном поисковом слое.

Технический контекст

Я посмотрел на первые живые отзывы по Antigravity 3.5 Flash и зацепился не за хайп, а за паттерн: модель хвалят именно там, где обычно всё быстро рассыпается, в архитектурном планировании. Если это подтверждается в серии тестов, то для AI implementation это сильный сигнал: модель умеет не только дописывать куски кода, а держать структуру системы в голове.

По доступным данным картина не чёрно-белая. Google продвигает 3.5 Flash как быстрый agentic-класс с сильными результатами в Terminal-Bench, MCP Atlas и ряде задач на tool use. Но в SWE-Bench Pro она выглядит уже не как безусловный лидер, и это нормально: одно дело строить ход решения, другое дело стабильно выигрывать жёсткие software engineering evals.

И вот тут самое интересное. В обсуждениях модель хвалят, а Tavily ругают: общий поисковый запрос часто тянет полированный официоз, а не реальные пользовательские тесты. Я с таким сталкивался не раз: если retrieval-слой приносит пресс-релиз вместо сырой фактуры, то любая умная модель начинает выглядеть либо слишком гениальной, либо слишком тупой.

Отдельно меня не удивили жалобы на неанглийские запросы. Для RAG это старая боль: на русском и других языках поиск часто хуже по recall, хуже по ранжированию и охотнее тащит англоязычный шум. Потом люди винят LLM, хотя проблема сидит в search API.

Бизнес и автоматизация

Практический вывод простой: если Antigravity 3.5 Flash действительно так хорошо держит архитектуру, её стоит смотреть для AI automation, где агент должен планировать цепочки действий, а не просто болтать. Особенно в внутренних copilot-сценариях, где цена ошибки в структуре выше цены ошибки в одной строчке кода.

Но выигрывают тут не все. Побеждают команды, которые меряют стек целиком: модель, retrieval, reranking, язык запроса, стоимость токенов. Проигрывают те, кто ставит модную модель поверх хрупкого поиска и потом удивляется, почему RAG врёт уверенно и дорого.

Мы в Nahornyi AI Lab как раз решаем такие вещи на практике: не выбираем модель по красивому анонсу, а собираем рабочую AI solutions architecture под конкретный процесс. Если у вас поиск уже шумит, а агент принимает решения на плохом контексте, давайте разберём этот контур и соберём AI integration так, чтобы система экономила время, а не бюджет на токены и отладку.

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

Поделиться статьёй