Mozilla AI pyta: Kto przeszukuje internet dla Twojego agenta?

Mozilla AI kwestionuje łączenie wyszukiwania z agentami dzięki Otari, które pozwala zespołom wybierać usługę wyszukiwania niezależnie od modelu. Kto przeszukuje internet dla Twojego agenta? Wpis z 19 października konkretyzuje to pytanie: wybór modelu AI nie musi określać, dokąd trafiają jego zapytania wyszukiwania.

Otari działa między agentem, czyli oprogramowaniem wykorzystującym narzędzia do realizacji zadań, a dostawcą modelu. Mozilla AI twierdzi, że ta pozycja pozwala przekierowywać wyszukiwania przy zachowaniu obsługiwanych interfejsów klienta. Proponowana zmiana dotyczy tego, kto kontroluje pozyskiwanie informacji, a nie tego, który model tworzy odpowiedź.

Konkurujące podejścia są proste: zaakceptować wyszukiwanie połączone z usługą modelu albo zarządzać wyszukiwaniem jako odrębną zależnością. Claude Code stanowi użyteczny punkt odniesienia, ponieważ jego wbudowane wyszukiwanie korzysta z backendu Anthropic. Otari podważa ten układ, czyniąc trasowanie wyszukiwania niezależną decyzją, z dodatkową odpowiedzialnością po stronie tego, kto ją podejmuje.

Kto przeszukuje internet dla Twojego agenta? Otari wyraźnie wskazuje wybór

W swojej analizie wyszukiwania przez agentów Mozilla AI opisuje trzy możliwości: wyszukiwanie obsługiwane przez Otari, konto wyszukiwania klienta albo hostowany samodzielnie punkt końcowy. Firma wymienia Brave, Exa i Tavily wśród usług, które klienci mogą połączyć, używając własnych poświadczeń.

Według Mozilla AI klienci mogą zachować Claude, GPT lub Gemini, jednocześnie zmieniając usługę obsługującą wyszukiwania. Poświadczenia wyszukiwania pozostają w bramie, pośredniku trasującym żądania, zamiast trafiać do agenta. Firma opisuje również kontrolę przestrzeni roboczej i rejestry wyszukiwania powiązane z użyciem modeli.

Istotna zmiana polega na tym, że wyszukiwanie staje się zależnością, którą zespoły mogą wybierać niezależnie od modelu.

To rozróżnienie łatwo przeoczyć, gdy aplikacja prezentuje jedno pole odpowiedzi. Użytkownik zadaje pytanie, czeka i otrzymuje odpowiedź zawierającą cytowania. Interfejs może sprawiać wrażenie, że pozyskiwanie informacji i rozumowanie są jedną operacją, nawet gdy wykonują je różne usługi.

Rozdzielenie tych operacji zmienia sposób, w jaki nabywcy oceniają system. Ocena modelu odpowiada na pytanie, czy model wykonuje instrukcje i skutecznie rozumuje. Ocena wyszukiwania pyta, czy system pozyskuje odpowiednie dowody, akceptowalnie obsługuje zapytania i wspiera wymagania operacyjne organizacji.

Żadna z tych ocen nie zastępuje drugiej. Dobre rozumowanie nie odzyska dokumentu, który nigdy nie trafił do zbioru dowodów. Silne wyszukiwanie nie zapobiegnie każdemu niepopartemu wnioskowi. Traktowanie ich oddzielnie daje zespołom jaśniejszy sposób badania błędów bez przypisywania wszystkiego modelowi.

Wpis Mozilla AI należy też dokładnie odczytywać jako deklarację kierunku produktu i udokumentowanych możliwości. Data publikacji nie ustala, kiedy każda z podstawowych funkcji stała się dostępna. Ogłoszenie nie dowodzi również, że klienci już osiągnęli lepsze odpowiedzi lub niższe koszty operacyjne.

Bezpośrednia wiadomość jest zatem węższa niż twierdzenie, że wyszukiwanie przez agentów zostało rozwiązane. Mozilla AI czyni dostawcę wyszukiwania wyraźną częścią rozmowy zakupowej i architektonicznej. Tworzy to praktyczną alternatywę dla akceptowania dowolnej usługi pozyskiwania informacji towarzyszącej wybranemu modelowi.

Dla zespołów już zadowolonych z połączonego wyszukiwania alternatywa musi uzasadnić dodatkowe obciążenie operacyjne. Dla zespołów blokowanych przez nieakceptowalny układ wyszukiwania rozdzielenie tej zależności rozwiązuje zupełnie inny problem. Potrzebują wyboru, który mogą ocenić, a nie kolejnego rankingu modeli.

Samo zapytanie zasługuje na analizę

Zapytanie wyszukiwania jest ujawnieniem informacji na zewnątrz, nawet gdy żądana odpowiedź dotyczy informacji publicznych.

Rozważmy hipotetycznego asystenta programistycznego badającego awarię oprogramowania. Przydatne publiczne zapytanie mogłoby opisywać komunikat błędu i wersję biblioteki. Niepotrzebnie szczegółowe zapytanie mogłoby zawierać również nazwę wewnętrznej usługi, identyfikator klienta lub nazwę nieopublikowanego projektu.

Rozróżnienie dotyczy tego, co opuszcza organizację, a nie tego, czy publiczną dokumentację można bezpiecznie czytać. Asystent może mieć uzasadniony powód do wyszukiwania, a jednocześnie tworzyć niewłaściwe zapytanie. Wybór dostawcy wyszukiwania dotyczy odbiorcy; analiza konstrukcji zapytania dotyczy treści.

To rozdzielenie ma znaczenie dla menedżerów inżynierii i nabywców korporacyjnych. Zatwierdzenie modelu nie odpowiada na każde pytanie o narzędzia z nim połączone. Każda dodatkowa usługa wprowadza relację operacyjną, która zasługuje na własną ocenę, szczególnie gdy zapytania pochodzą z prywatnego kontekstu pracy.

Rozsądną odpowiedzią jest prześledzenie rzeczywistego zadania. Jakie informacje trafiły do promptu? Jaki tekst stał się zapytaniem wyszukiwania? Która usługa go otrzymała? Jakie wyniki wróciły i które z nich wpłynęły na odpowiedź?

Te pytania czynią rozmowę zakupową bardziej konkretną. Ujawniają też miejsce, w którym kończy się dane twierdzenie. Znajomość miejsca docelowego zapewnia wgląd w trasowanie. Nie dowodzi jednak, że każde zapytanie było konieczne, odpowiednio sformułowane lub objęte akceptowalnymi warunkami przetwarzania.

To samo rozumowanie dotyczy badań klientów. Wyobraźmy sobie asystenta przygotowującego briefing o potencjalnym kliencie. Publiczne informacje o firmie należą do procesu badawczego. Prywatne notatki sprzedażowe, proponowane zapisy umowy i wewnętrzne oceny wymagają odrębnej decyzji, zanim pojawią się w zewnętrznych zapytaniach.

To przykładowe scenariusze, a nie udokumentowane wdrożenia Otari u klientów. Ich wartość polega na pokazaniu, dlaczego wybór wyszukiwania ma znaczenie wykraczające poza preferencje deweloperów. Pozornie zwyczajne wyszukiwanie może przekroczyć granicę, której ostateczna odpowiedź nie ujawnia.

Pracownicy wiedzy potrzebują także rozróżnienia między odkrywaniem publicznych źródeł a przeszukiwaniem własnych materiałów. Osobista baza wiedzy odpowiada na potrzebę informacyjną inną niż znajdowanie nowych źródeł publicznych. Skuteczny przepływ pracy powinien określać, jakiego rodzaju dowodów wymaga zadanie, zanim wybierze miejsce wyszukiwania.

Dla menedżera produktu może to oznaczać konsultację z wewnętrznymi badaniami przed wyszukaniem aktualnych informacji o konkurencji. Dla inżyniera może to oznaczać sprawdzenie prywatnych decyzji projektowych przed sięgnięciem po publiczną dokumentację. Chodzi o celowe pozyskiwanie informacji, a nie wysyłanie każdej niepewności do otwartego internetu.

Wywiera to presję na osoby zatwierdzające wdrożenia agentów. Potrzebują wystarczającej widoczności, aby wyjaśnić ścieżkę informacji, w tym jej ograniczenia. Produkt ujawniający miejsce docelowe wyszukiwania może wspierać takie wyjaśnienie, ale organizacja nadal musi zdecydować, jakie informacje powinny znaleźć się na tej ścieżce.

Kto przeszukuje internet dla Twojego agenta? Dla nabywców odpowiednia odpowiedź obejmuje operatora, właściwą umowę i zakres wysyłanych informacji. Samo wskazanie rozpoznawalnego modelu pozostawia część tej odpowiedzi dotyczącą wyszukiwania nieukończoną.

Połączone wyszukiwanie oferuje wygodę, a oddzielne wyszukiwanie zwiększa odpowiedzialność

Najsilniejszym argumentem za połączonym wyszukiwaniem jest wygoda. Deweloper otrzymuje obsługiwany interfejs narzędziowy bez składania każdego elementu pozyskiwania informacji. Organizacja może preferować taki układ, gdy jej wymagania są zgodne z usługą dostawcy i udokumentowanym zachowaniem.

Narzędzie wyszukiwania w internecie Anthropic ilustruje podejście zintegrowane. Claude określa, kiedy wyszukiwać, usługa wykonuje wyszukiwania, a końcowa odpowiedź zawiera cytowania. Dokumentacja opisuje również kontrolę domen i różne wersje narzędzia.

Te możliwości mają znaczenie, ponieważ konfigurowalne wyszukiwanie nie jest unikalne dla niezależnej bramy. Klienci powinni rozróżniać kontrolę nad zachowaniem wyszukiwania od kontroli nad dostawcą wyszukiwania. Dostawca może udostępniać użyteczne ograniczenia, zachowując jednocześnie odpowiedzialność za obsługę podstawowej usługi.

Kluczowy wybór dotyczy tego, kto jest właścicielem decyzji o pozyskiwaniu informacji oraz pracy wymaganej do ich utrzymania.

Propozycja Otari przemawia do zespołów, które chcą mieć tę odpowiedzialność. Niezależność wprowadza jednak obowiązki, które usługi połączone przejmują lub upraszczają. Ktoś musi zarządzać poświadczeniami, oceniać zachowanie usługi, badać błędy i utrzymywać działającą relację między agentem a jego narzędziami wyszukiwania.

Ollama oferuje kolejne użyteczne porównanie. Jego dokumentacja dotycząca hostowanego wyszukiwania w internecie określa uwierzytelnione żądanie do ollama.com/api/web_search. Odpowiedź zawiera wyniki obejmujące tytuły stron, adresy i fragmenty treści.

Ten przykład ustala ograniczony, lecz istotny punkt: korzystanie z lokalnego modelu nie oznacza, że jego wyszukiwania w internecie pozostają lokalne. Udokumentowane żądanie wyszukiwania trafia do hostowanej usługi. Klienci muszą osobno analizować inferencję, wyszukiwanie i pobieranie stron, oceniając, gdzie zachodzi przetwarzanie.

Nie jest to dowód, że hostowane wyszukiwanie jest z natury nieodpowiednie. Usługa hostowana może być akceptowalnym wyborem, gdy jej warunki, zachowanie i niezawodność spełniają potrzeby organizacji. Istotnym błędem jest założenie, że jeden wybór architektoniczny automatycznie określa każdy inny komponent.

Ta sama dyscyplina dotyczy jakości odpowiedzi. Zmiana usług wyszukiwania zmienia dowody dostępne dla modelu. Ocena, która jednocześnie zmienia model i wyszukiwanie, nie może łatwo wyjaśnić, która zmiana poprawiła lub pogorszyła wynik.

Rozdzielenie tych zmiennych wspiera bardziej miarodajne porównania. Zespoły mogą utrzymać model bez zmian podczas badania pozyskiwania informacji, a następnie utrzymać dowody bez zmian podczas badania syntezy. Takie oceny nadal wymagają starannego projektu, ale unikają traktowania całej aplikacji jako niepodzielnej czarnej skrzynki.

Ocena wyszukiwania w internecie przez Otari powinna zatem zaczynać się od własnych zadań zespołu. Wyszukiwanie publicznej dokumentacji, aktualne badanie firm i specjalistyczne odkrywanie techniczne mogą wymagać różnych dowodów. Uniwersalne twierdzenie, że jedna usługa wyszukiwania jest najlepsza, wymagałoby dowodów wykraczających poza te pojedyncze obciążenia.

Ogłoszenie Mozilla AI nie przedstawia niezależnego badania porównawczego ustanawiającego takiego zwycięzcę. Silniejsza interpretacja jest taka, że klienci powinni móc wybierać i testować tę zależność. To argument za kontrolą i oceną, a nie wykazany ranking wyszukiwarek.

Presja dotyczy obu podejść. Dostawcy usług połączonych muszą wystarczająco jasno wyjaśniać swoje rozwiązania wyszukiwania, aby nabywcy mogli je ocenić. Niezależna infrastruktura musi pokazać, że dodatkowa kontrola pozostaje użyteczna, gdy zmieniają się klienci, modele i interfejsy narzędziowe.

Wyszukiwanie w internecie przez Otari zależy od zachowania oczekiwań klienta

Konfigurowalna usługa wyszukiwania pomaga tylko wtedy, gdy agent potrafi korzystać z niej prawidłowo. Aplikacje oczekują więcej niż listy linków. Zależą od rozpoznawalnych odpowiedzi narzędziowych, zachowania w przypadku błędów i wystarczających informacji o źródłach, aby kontynuować zadanie.

Dokumentacja przechwytywania wyszukiwania Otari opisuje przejmowanie obsługiwanych deklaracji wyszukiwania nazwanych po dostawcach, gdy przechwytywanie jest włączone. Przechwytywanie oznacza obsługę żądania, które w przeciwnym razie trafiłoby do narzędzia dostawcy. Dokumentacja odróżnia to zachowanie od przekazywania natywnych żądań dostawcy.

Opisuje również ograniczenia obszaru roboczego, w tym wyłączanie wyszukiwania, ograniczanie wyników i zawężanie domen. Dokumentacja ostrzega, że dołączona konfiguracja SearXNG jest ograniczana pod względem liczby zapytań przy długotrwałym użyciu. To ostrzeżenie ma znaczenie przy ocenie gotowości produkcyjnej, a nie krótkiej demonstracji.

Zachowanie interfejsu ogranicza nakład pracy związany z integracją, lecz nie zapewnia identycznego działania.

Klient może zaakceptować odpowiedź, otrzymując jednocześnie inne dowody. Może też prawidłowo obsłużyć udane wyszukiwanie, a słabo zareagować na niedostępną usługę. Zgodność musi zatem obejmować zarówno zwykłe działanie, jak i przypadki, które je przerywają.

Hipotetyczne zadanie programistyczne uwidacznia tę różnicę. Asystent wyszukuje przewodnik po migracji, czyta wynik i proponuje zmianę w kodzie. Użyteczna ocena sprawdza, czy odnaleziony przewodnik odpowiada właściwej wersji oprogramowania i uzasadnia proponowaną zmianę.

To samo zadanie powinno pozostać zrozumiałe, gdy wyszukiwanie nie zwraca żadnych wyników. Agent, który jasno zgłasza brak dowodów, zachowuje się inaczej niż ten, który improwizuje odpowiedź. Format odpowiedzi bramy ma znaczenie, podobnie jak interpretacja niepowodzenia przez klienta.

W tym miejscu porównania oparte wyłącznie na płynności odpowiedzi stają się mylące. Dopracowane wyjaśnienie może ukrywać słabe dowody. Mniej dopracowana odpowiedź, która wskazuje własne ograniczenia, może być bardziej użyteczna przy istotnej decyzji technicznej.

Konfiguracja wyszukiwania Otari dokumentuje nazwane instancje wyszukiwania oraz wybór domyślny. Opisuje również ustawienia specyficzne dla dostawców i wymagania dotyczące poświadczeń. Szczegóły te pokazują, że niezależność wyszukiwania jest konfiguracją operacyjną, a nie jedynie preferencją wyrażoną w promptcie.

Dla zespołów platformowych konfiguracja rodzi znane pytania dotyczące utrzymania. Kto może zmienić ustawienie domyślne? Jak zmiana trafia do różnych obszarów roboczych? Jakie dowody pokazują, że żądanie wykorzystało zamierzoną usługę? Odpowiedzi określają, czy kontrola przetrwa zwykłą działalność organizacyjną.

Ustawienie może istnieć, nie stając się skuteczną polityką. Ocena musi ustalić, co dzieje się w rzeczywistej konfiguracji wdrożenia, w tym przy dozwolonych wyjątkach. W przeciwnym razie demonstracja możliwości wyboru wyszukiwania może zostać pomylona z zapewnieniem dotyczącym każdego żądania produkcyjnego.

To rozróżnienie staje się szczególnie ważne, gdy aplikacja ma kilka sposobów docierania do zewnętrznych informacji. Narzędzie wyszukiwania, mechanizm pobierania stron i przeglądarka mogą reprezentować różne ścieżki. Kontrolowanie jednej ścieżki nie oznacza kontroli nad wszystkimi.

Ta obserwacja jest kwestią architektoniczną, a nie ustaleniem, że Otari ma konkretne obejście zabezpieczeń. Kupujący powinni prosić o dowody pokrycia odpowiadające ich klientom i włączonym narzędziom. Szerokie sformułowania, takie jak „cały ruch agentów”, wymagają szerszej weryfikacji niż udane przechwycone wyszukiwanie.

Mechanizm jest obiecujący, ponieważ umieszcza decyzję o routingu poza osądem modelu. Jego praktyczna wartość zależy od tego, czy otaczająca aplikacja konsekwentnie korzysta z tej kontrolowanej trasy. Ocena musi śledzić całe zadanie, włącznie z momentami, gdy oczekiwana trasa zawodzi.

Samodzielne hostowanie zmienia zakres odpowiedzialności, lecz nie eliminuje zależności

Samodzielne uruchamianie pośrednika wyszukiwania nie oznacza prowadzenia niezależnego indeksu internetu.

Architektura metawyszukiwania SearXNG agreguje wyniki z innych wyszukiwarek. To precyzuje znaczenie samodzielnego hostowania: organizacja może prowadzić usługę agregacji, nadal polegając na nadrzędnych wyszukiwarkach w zakresie wyników.

W przypadku wdrożenia Otari korzystającego z SearXNG to rozróżnienie zapobiega zawyżonym twierdzeniom o prywatności. Operator kontroluje własną instancję, lecz skonfigurowane przez nią relacje z dostawcami nadrzędnymi nadal mają znaczenie. Pełna ocena śledzi zapytanie poza pierwszy serwer organizacji.

To użyteczny sceptyczny test szerszego przekazu. Jeśli samodzielne hostowanie jest przedstawiane jako pełna niezależność, metawyszukiwanie komplikuje tę obietnicę. Jeśli przedstawia się je jako kontrolę nad określonym komponentem, twierdzenie jest węższe i łatwiejsze do oceny.

Ta sama dyscyplina powinna obowiązywać przy porównaniach kosztów. Usunięcie opłaty za dołączone wyszukiwanie nie usuwa pracy związanej z obsługą pobierania informacji. Infrastruktura, utrzymanie, reagowanie na incydenty i uwaga personelu należą do oceny, nawet jeśli nie pojawiają się jako opłata za pojedyncze zapytanie.

Nie ma tu podstaw, by uznać samodzielne hostowanie za zawsze tańsze. Właściwe porównanie zależy od obciążenia, wymagań usługowych i istniejących możliwości organizacji. Zespół, który już obsługuje pokrewną infrastrukturę, stoi przed inną decyzją niż zespół bez takiej wiedzy.

Kontrola poświadczeń również wymaga precyzyjnej interpretacji. Trzymanie poświadczeń z dala od agenta ogranicza jedną ścieżkę ekspozycji. Usługa przechowująca te poświadczenia pozostaje wrażliwym systemem, który wymaga odpowiedniej administracji i kontroli dostępu.

Rejestry wyszukiwania tworzą kolejny kompromis. Mogą pomagać wyjaśnić, dlaczego agent wygenerował odpowiedź, ale mogą też zachowywać wrażliwy tekst zapytań. Organizacja dążąca do rozliczalności powinna zdecydować, kto może przeglądać te rejestry i jak długo pozostają użyteczne.

Większa widoczność tworzy zatem własne zadanie w zakresie zarządzania. Szczegółowe rejestry nie są automatycznie lepsze w każdym kontekście. Celem jest wystarczający materiał dowodowy do badania sprawy, przy zasadach postępowania odpowiednich do informacji zawartych w tych rejestrach.

Ograniczenia domen mają podobnie ograniczoną wartość. Mogą zawężać pulę kwalifikujących się źródeł. Nie dowodzą, że każda strona z dozwolonej domeny jest dokładna, aktualna lub odpowiednia dla konkretnego zadania.

Wybór dostawcy wyszukiwania nie rozwiązuje też problemu prompt injection, czyli złośliwych treści zaprojektowanych tak, by przekierować zachowanie asystenta. Pobrane strony pozostają zewnętrznymi danymi wejściowymi. Agent musi traktować je jako dowody do oceny, a nie instrukcje mające władzę nad jego zadaniem.

Ograniczenia te nie podważają argumentów za niezależnym wyszukiwaniem. Określają, co te argumenty mogą uzasadniać. Wybór zależności daje organizacjom miejsce do stosowania osądu; nie gwarantuje, że osąd będzie właściwy.

Wiarygodnym rezultatem jest większa rozliczalność za możliwe do zidentyfikowania wybory. Kupujący może zapytać, dlaczego wybrano usługę, jakie założenia ją wspierają i co uruchomiłoby zmianę. Pytania te pozostają wartościowe nawet wtedy, gdy wybraną odpowiedzią jest dostawca zarządzany.

Wdrożenie wyszukiwania internetowego Otari powinno być oceniane względem tych konkretnych obowiązków. Samo ogłoszenie nie dowodzi lepszego pobierania informacji, uniwersalnej zgodności ani pełnego rezultatu w zakresie prywatności. Te wnioski muszą opierać się na dowodach z rzeczywistego środowiska zespołu.

Obserwuj zgodność, dowody porównawcze i ujawnianie informacji przez dostawców

Kolejne okno raportowania powinno koncentrować się na obserwowalnych zmianach, a nie na obietnicach bardziej otwartego stosu AI. Do końca 2026 roku i na początku 2027 roku użyteczne sygnały będą dotyczyć tego, czy niezależne wyszukiwanie staje się łatwiejsze w obsłudze i ocenie.

Najmocniejsze dowody pokażą niezawodną kontrolę podczas rzeczywistych zadań, w tym awarii i zmian.

Pierwszym sygnałem są opublikowane dowody zgodności dla klientów i interfejsów narzędziowych, z których zespoły faktycznie korzystają. Użyteczne wydanie wskazywałoby przetestowane zachowania, obsługiwane wersje i znane ograniczenia. Powtarzalne przykłady wzmocniłyby argument, że klienci mogą zachować swoje aplikacje, zmieniając jednocześnie wyszukiwanie.

Odwrotnie, powtarzające się obejścia specyficzne dla klienta osłabiłyby praktyczne twierdzenie o niezależności. Usługa teoretycznie możliwa do zastąpienia oferuje ograniczoną swobodę, jeśli każde zastąpienie wymaga istotnej naprawy aplikacji. Zgodność musi pozostać zrozumiała wraz z ewolucją otaczającego oprogramowania.

Drugim sygnałem jest ocena porównawcza z kontrolowanym obciążeniem. Należy utrzymać stałość modelu i zadań, a następnie zbadać trafność pobierania, aktualność, czas odpowiedzi, awarie i całkowity nakład operacyjny. Wynik powinien wskazywać, gdzie każde rozwiązanie się sprawdza, w tym przypadki, w których dołączone wyszukiwanie nadal pozostaje preferowane.

Przekonująca ocena opublikowałaby wystarczająco dużo szczegółów, aby czytelnicy mogli zrozumieć jej granice. Wyniki wyszukiwania dokumentacji nie powinny przeradzać się w twierdzenia dotyczące każdego zadania badawczego. Dowody selektywnych korzyści byłyby bardziej wiarygodne niż niewyjaśniona deklaracja ogólnej wyższości.

Trzecim sygnałem jest jaśniejsze ujawnianie informacji lub dodatkowy wybór dostawcy ze strony dostawców usług dołączonych. Bardziej jednoznaczna dokumentacja pomogłaby klientom ocenić istniejące usługi bez przyjmowania kolejnego pośrednika. Wspierany przez dostawcę wybór sprawdziłby również, czy klienci przede wszystkim chcą niezależności, czy po prostu jaśniejszych mechanizmów kontroli.

Taki rozwój wzmocniłby podstawowy argument Mozilla AI, zmieniając jednocześnie pozycję konkurencyjną Otari. Wyszukiwanie stałoby się bardziej widoczną decyzją zakupową, nawet gdyby kupujący korzystali z tego wyboru gdzie indziej. Trwałą kwestią pozostaje to, kto może podjąć i wyjaśnić tę decyzję.

Kto przeszukuje internet dla Twojego agenta? Odpowiedź powinna stawać się bardziej konkretna wraz z rozwojem tych sygnałów. Powinna wskazywać rzeczywistą ścieżkę informacji i dowody uzasadniające jej użycie, zamiast opierać się na założeniach wynikających z nazwy modelu.

Przed rozszerzeniem przepływu pracy agenta przeanalizuj reprezentatywne zadanie od promptu do końcowej odpowiedzi. Zidentyfikuj wychodzące zapytanie, jego odbiorcę, zwrócone źródła i dowody wspierające wniosek. Następnie zapytaj, czy dane rozwiązanie odpowiada wrażliwości i celowi pracy. Zachowaj dołączone wyszukiwanie, gdy jego udokumentowane zachowanie spełnia te potrzeby. Oceń oddzielną usługę wyszukiwania, gdy wybór dostawcy, kontrola operacyjna lub jaśniejsze rejestry odpowiadają konkretnemu wymaganiu. W przypadku zadań łączących prywatną wiedzę z badaniami publicznymi przeanalizuj tę granicę wprost, zamiast traktować każde wyszukiwanie jednakowo. Użytecznym kolejnym krokiem jest decyzja, którą zespół potrafi wyjaśnić: z której usługi wyszukiwania powinien korzystać ten agent i jakie dowody uzasadniają ten wybór?