Skip to main content
Antigravity 3.5 FlashTavilyRAG

Antigravity 3.5 Flash und Tavily: Erkenntnisse aus den Tests

Erste Nutzertests von Antigravity 3.5 Flash loben das Modell für seine starke Architekturplanung. Es zeigte sich jedoch eine weitere Erkenntnis: Tavily kann im RAG versagen, besonders bei nicht-englischen Anfragen. Für die KI-Automatisierung ist dies wichtig, da der Fehler oft in einer fehlerhaften Suchschicht liegt und nicht im Modell.

Technischer Kontext

Ich habe mir das erste Live-Feedback zu Antigravity 3.5 Flash angesehen und bin nicht am Hype hängen geblieben, sondern an einem Muster: Das Modell wird genau dort gelobt, wo die Dinge normalerweise schnell auseinanderfallen, nämlich bei der Architekturplanung. Wenn sich dies in breiteren Tests bestätigt, ist das ein starkes Signal für die KI-Implementierung: Das Modell vervollständigt nicht nur Code-Schnipsel, sondern behält die Systemstruktur im Blick.

Nach den verfügbaren Daten ist das Bild nicht nur schwarz-weiß. Google bewirbt 3.5 Flash als schnelles agentisches Modell mit starken Ergebnissen in Terminal-Bench, MCP Atlas und diversen Tool-Use-Aufgaben. In SWE-Bench Pro sieht es jedoch nicht wie der absolute Spitzenreiter aus, und das ist in Ordnung: Es ist eine Sache, einen Lösungsweg zu entwerfen, eine andere, durchweg harte Software-Engineering-Evaluationen zu gewinnen.

Und hier wird es interessant. In Diskussionen loben die Nutzer das Modell, kritisieren aber Tavily: Eine allgemeine Suchanfrage zieht oft glattgebügelte Pressemitteilungen anstelle echter Nutzertests. Ich habe das oft erlebt: Wenn die Retrieval-Schicht eine Pressemitteilung anstelle von Rohdaten liefert, wirkt jedes smarte Modell entweder zu genial oder völlig inkompetent.

Andererseits haben mich Beschwerden über nicht-englische Suchanfragen nicht überrascht. Das ist ein altes Problem bei RAG: Im Russischen und in anderen Sprachen leidet die Suche oft unter schlechterem Recall, schlechterem Ranking und zieht bereitwillig englisches Rauschen an. Die Leute geben dann dem LLM die Schuld, obwohl das Problem in der Search API liegt.

Business und Automatisierung

Die praktische Schlussfolgerung ist einfach: Wenn Antigravity 3.5 Flash die Architektur wirklich so gut beibehält, lohnt es sich, es für die KI-Automatisierung in Betracht zu ziehen, wo ein Agent Handlungsketten planen muss und nicht nur plaudern soll. Dies gilt insbesondere für interne Copilot-Szenarien, in denen die Kosten für einen strukturellen Fehler weitaus höher sind als für einen Fehler in einer einzigen Codezeile.

Aber hier gewinnen nicht alle. Die Gewinner sind Teams, die den gesamten Stack messen: Modell, Retrieval, Reranking, Abfragesprache und Token-Kosten. Die Verlierer sind diejenigen, die ein angesagtes Modell auf eine zerbrechliche Suchschicht setzen und sich dann wundern, warum ihr RAG mit solchem Selbstvertrauen teure Lügen erzählt.

Bei Nahornyi AI Lab lösen wir genau diese Dinge in der Praxis: Wir wählen kein Modell aufgrund einer auffälligen Ankündigung aus, sondern entwickeln eine funktionierende KI-Lösungsarchitektur für einen bestimmten Prozess. Wenn Ihre Suche bereits Rauschen erzeugt und der Agent Entscheidungen in einem schlechten Kontext trifft, lassen Sie uns diese Schleife entwirren und eine KI-Integration so zusammenstellen, dass das System Ihnen Zeit spart und nicht Ihr Budget für Token und Debugging aufbraucht.

Zuvor haben wir bereits einen ähnlichen Fall von überzogenen Erwartungen mit Codex 5.2 analysiert, bei dem das Fehlen einer durchdachten Architektur eine laute Demo in einen Mythos verwandelte. Diese Erfahrung zeigt deutlich, warum man bei der Bewertung vielversprechender Alternativen immer deren technische Einschränkungen sorgfältig prüfen sollte.

Diesen Artikel teilen