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, де відсутність продуманої архітектури перетворила гучне демо на міф. Цей досвід наочно показує, чому при оцінці багатообіцяючих альтернатив завжди варто уважно вивчати їхні технічні обмеження.

Поділитися статтею