Mistral Agentic Search: pięć narzędzi zamiast RAG-u

Mistral dodał do klasycznego wyszukiwania warstwę, która nie kończy pracy na pierwszej paczce fragmentów. Agentic Search pozwala modelowi wyszukać dokument, otworzyć go, przejść do sąsiedniej sekcji, odczytać konkretny zakres i znaleźć dokładną frazę. W testach producenta taka pętla podniosła wynik GLM-5.2 na FinanceBench z 26,7% dla jednorazowego RAG-u do 86%. To duża różnica, ale na razie potwierdzona wyłącznie przez Mistral.

Komunikat z 20 sierpnia 2026 r. dotyczy przede wszystkim pracy na długich, obszernych dokumentach: raportach finansowych, umowach, dokumentacji wewnętrznej i archiwach administracji. Agentic Search jest dostępny przez Search Toolkit, jako zestaw narzędzi MCP oraz w zarządzanych Libraries w Studio i Vibe.

Najważniejsze fakty

• Agentic Search korzysta z pięciu narzędzi: search, open, navigate, read i grep.
• Nie zastępuje indeksu ani wyszukiwania wektorowego. Orkiestruje kolejne kroki nad istniejącym indeksem.
• Wyniki 86% na FinanceBench i 51,9% na OfficeQA Pro dotyczą GLM-5.2 w stosie Mistral i są pomiarami producenta.
• Search Toolkit jest pakietem dla Pythona 3.12+ na licencji Apache 2.0; starter wykorzystuje Dockera i Vespę.
• Mistral nie podał osobnej ceny Agentic Search. Trzeba liczyć koszt modeli, embeddingów lub OCR, infrastruktury oraz dodatkowych wywołań.

Agentic Search nie jest „nowym retrieverem”

W prostym RAG-u pytanie zostaje zamienione na zapytanie do indeksu, system wybiera kilka najlepiej ocenionych fragmentów, a model układa odpowiedź na ich podstawie. Takie podejście działa dobrze, gdy właściwy fragment rzeczywiście znajdzie się w pierwszym top-k. Traci skuteczność, gdy odpowiedź wymaga przejścia przez długi dokument, połączenia danych z kilku plików albo sprawdzenia, co dokładnie oznacza liczba w tabeli.

Dokumentacja Mistral opisuje Agentic Search jako warstwę orkiestracji nad wyszukiwaniem leksykalnym, semantycznym lub hybrydowym. Model może obejrzeć trafienie, rozszerzyć jego kontekst, przejść w przód lub w tył, znaleźć dokładny termin i ponowić wyszukiwanie z listą fragmentów, których nie należy już zwracać. To ostatnie ogranicza krążenie po tych samych wynikach.

Różnica przypomina pracę analityka. Zwykłe wyszukiwanie podaje mu kilka stron uznanych za podobne do pytania. Pętla agentowa pozwala zajrzeć do dokumentu, sprawdzić przypis, wrócić do definicji, porównać okresy i dopiero wtedy sformułować odpowiedź. Nie jest to jednak magia: jakość nadal zależy od ekstrakcji tekstu, podziału na fragmenty, indeksu, modelu i instrukcji agenta.

Pięć narzędzi do pracy wewnątrz dokumentu

Pięć narzędzi dotyczy samego retrievalu. Gotowy serwer MCP w Search Starter App udostępnia łącznie siedem narzędzi, ponieważ obejmuje również operacje techniczne związane z przygotowaniem indeksu. Agent zgodny z MCP może odkryć je i stosować według dołączonej instrukcji. Z kolei SDK daje programiście kontrolę nad ładowaniem dokumentów, ekstrakcją, dzieleniem tekstu, embeddingami, przechowywaniem, rerankingiem i cache’em semantycznym.

Wyniki Mistral: największy skok daje sama pętla

Mistral przetestował rozwiązanie na FinanceBench i OfficeQA Pro, korzystając z domyślnego stosu Search Toolkit, bez dostrajania konfiguracji. Użyto Mistral Medium 3.5 oraz GLM-5.2. To ważne rozróżnienie: Agentic Search jest warstwą retrievalu, a nie nowym modelem językowym. GLM-5.2 opisywaliśmy wcześniej jako model open-weight, tutaj pełni on rolę silnika rozumowania w środowisku Mistral.

Na FinanceBench największą część poprawy przyniosło samo wielokrotne wyszukiwanie: +47,3 punktu procentowego dla Mistral Medium 3.5 i +52,6 punktu dla GLM-5.2 względem one-shot RAG-u. Nawigacja dołożyła odpowiednio 8,7 i 6,7 punktu. Benchmark obejmował 150 pytań nad 368 dokumentami SEC o łącznej długości około 53,9 tys. stron.

OfficeQA Pro jest trudniejszy: 133 pytania wymagają pracy na skanach historycznych biuletynów skarbowych z rozbudowanymi tabelami. Pełna pętla osiągnęła 28,6% dla Mistral Medium 3.5 i 51,9% dla GLM-5.2. Nawet najlepszy raportowany wynik oznacza więc, że niemal połowa zadań nadal nie została rozwiązana poprawnie. To mocny argument za użyciem człowieka do kontroli odpowiedzi w finansach, prawie i innych procesach wysokiego ryzyka.

Więcej wywołań a jednak mniej tokenów i niższe opóźnienie

Intuicyjnie agent wykonujący kilka kroków powinien być droższy i wolniejszy. Wyniki Mistral pokazują bardziej złożony obraz. Na FinanceBench dodanie nawigacji do pętli opartej wyłącznie na kolejnych wyszukiwaniach zmniejszyło zużycie tokenów o 23,9% dla Mistral Medium 3.5 i 33,7% dla GLM-5.2. P90 czasu odpowiedzi spadło z 255 do 154 sekund, a średnia ze 108 do 71 sekund.

Nie jest to porównanie pełnej pętli z pojedynczym wyszukaniem. Mistral zestawia tutaj dwa warianty agentowe: pętlę search-only oraz pętlę, która po znalezieniu dobrego dokumentu potrafi pozostać w nim i przejść do właściwego miejsca. Zamiast wielokrotnie przeszukiwać cały korpus, agent używa tańszych, bardziej precyzyjnych operacji. Wynik sugeruje, że dobrze zaprojektowane narzędzia mogą ograniczyć marnowanie kontekstu, ale nie dowodzi, że agentowa architektura zawsze będzie szybsza od prostego RAG-u.

Dostępność, licencja i rzeczywisty koszt

Najbardziej elastyczna droga prowadzi przez Mistral Search Toolkit. Pakiet dla Pythona 3.12+ jest dostępny na PyPI na licencji Apache 2.0, a komponenty można wymieniać. Oficjalny quickstart używa Vespy jako indeksu, Dockera do uruchomienia usługi i klucza API Mistral do embeddingów oraz pracy modelu. Starter App ma licencję MIT i tworzy gotowy szkielet projektu z serwerem MCP.

Druga ścieżka to Libraries w Studio i Vibe. To zarządzane biblioteki dokumentów, które można tworzyć przez API, współdzielić w organizacji i podłączać do agentów. Mistral nie podał jednak w komunikacie osobnego cennika Agentic Search. Otwartość kodu Search Toolkit nie oznacza darmowej usługi: rachunek może obejmować modele, embeddingi, OCR, przechowywanie, Vespę, transfer i monitoring. Własne wdrożenie daje większą kontrolę nad danymi, ale przenosi na zespół odpowiedzialność za utrzymanie indeksu i uprawnień.

W przypadku skanów istotny może być Mistral OCR. Jego najnowszą wersję i mechanizm wskazywania położenia informacji opisaliśmy w artykule o Mistral OCR 4. Sam Agentic Search nie naprawi błędnie odczytanej tabeli: jeśli warstwa ekstrakcji zgubi kolumnę, jednostkę albo przypis, agent może sprawnie nawigować po błędnym materiale.

Kiedy pętla agentowa ma sens?

Najlepszym przypadkiem użycia są pytania, których nie da się rozstrzygnąć na podstawie jednego oczywistego fragmentu. Dotyczy to porównywania wielu raportów, śledzenia definicji i przypisów, pracy na długich umowach, wyszukiwania wartości w tabelach oraz przygotowywania odpowiedzi z dowodami. W takich zadaniach ważna jest nie tylko podobność semantyczna, ale też położenie fragmentu i relacja z sąsiednimi stronami.

Prosty RAG nadal będzie lepszy dla krótkiego FAQ, dobrze opisanej dokumentacji i odpowiedzi, które powinny pojawić się w pierwszych trafieniach. Baza danych z jednoznacznym schematem często wymaga zapytania SQL, a nie agenta przeglądającego dokumenty. Każde dodatkowe wywołanie narzędzia zwiększa też liczbę miejsc, w których może wystąpić błąd, dlatego wdrożenie potrzebuje limitów kroków, rejestrowania źródeł, testów regresji i kontroli dostępu.

To zgodne z praktyczną zasadą opisaną szerzej w tekście o tym, jak nie skończyć z „agentem do niczego”: najpierw trzeba zdefiniować mierzalne zadanie, dane i warunek poprawności. Agentic Search jest narzędziem do konkretnego problemu retrievalu, a nie uniwersalnym dodatkiem, który automatycznie ulepszy każdą aplikację AI.

Co zmienia ta premiera?

Najciekawszy element Agentic Search nie polega na porzuceniu RAG-u. Mistral pokazuje, że indeks i początkowy retrieval mogą być dopiero początkiem pracy, a nie jej końcem. Pięć prostych operacji daje modelowi możliwość prowadzenia kontrolowanego dochodzenia wewnątrz korpusu i ogranicza koszt powtarzania szerokich zapytań.

Na razie trzeba oddzielić obiecującą architekturę od marketingowego skrótu. Wyniki są wysokie, lecz pochodzą od producenta i zależą od konkretnego harnessu. Najważniejszym kolejnym krokiem będzie niezależna replikacja na innych korpusach oraz porównanie całkowitego kosztu, nie tylko tokenów generowanych przez model. Jeśli te wyniki się utrzymają, największą zmianą może być przesunięcie uwagi z wyboru jednego „najlepszego” retrievera na projektowanie całej ścieżki wyszukiwania, nawigacji i weryfikacji.