Cloudflare wprowadza Web Search API przez AI Gateway, zamieniając wyszukiwanie w infrastrukturę
Cloudflare wprowadza Web Search API przez AI Gateway z trzema dostawcami wyszukiwania, przenosząc pobieranie aktualnych danych z sieci do tej samej warstwy kontroli co wnioskowanie modeli. Wersja beta obsługuje Ceramic.ai, Exa i Linkup za pośrednictwem jednego interfejsu. Deweloperzy mogą wywoływać ją z backendu, Cloudflare Worker lub przepływu pracy agenta.
Istotna zmiana nie polega na tym, że pojawił się kolejny punkt końcowy wyszukiwania w sieci. Cloudflare umieszcza wyszukiwanie obok routingu modeli, logów, kontroli bezpieczeństwa, poświadczeń i zarządzania użyciem. Takie pozycjonowanie przekształca pobieranie danych z odizolowanej integracji w zarządzaną infrastrukturę AI.
Ten ruch tworzy też wyraźną rywalizację. Deweloperzy mogą korzystać z narzędzi wyszukiwania wbudowanych w platformy modeli, łączyć się bezpośrednio ze wyspecjalizowanymi firmami wyszukiwawczymi lub umieścić pobieranie danych za niezależną bramą. Cloudflare zakłada, że zespoły będą chciały wybrać trzecią opcję, zwłaszcza gdy jedna aplikacja korzysta z kilku modeli i dostawców wyszukiwania.
Wprowadzenie Web Search API przez AI Gateway zmienia punkt kontroli
Cloudflare zapewnia teraz deweloperom jedną zarządzaną trasę do trzech niezależnych usług wyszukiwania, bez wiązania pobierania danych z konkretnym modelem językowym.
Firma ogłosiła wersję beta 2 października 2026 r. Według ogłoszenia premiery żądania mogą korzystać z Ceramic.ai, Exa lub Linkup. Ceramic.ai staje się domyślnym wyborem, gdy aplikacja nie określi dostawcy.
Każda odpowiedź ma wspólną strukturę zawierającą tytuł, URL i opis każdego wyniku. Metadane mogą także obejmować zapytanie, identyfikator żądania i informacje o opóźnieniu. Ta spójność ma znaczenie, ponieważ różnice specyficzne dla dostawców często przenikają do kodu aplikacji.
Deweloperzy mogą uzyskać dostęp do usługi przez standardowy punkt końcowy REST. Użytkownicy Cloudflare Workers mogą zamiast tego wywołać env.AI.websearch() przez powiązanie AI. Obie metody wysyłają żądanie przez istniejący AI Gateway.
Trasa REST przyjmuje zapytanie, nazwę dostawcy, limit wyników i konfigurację bramy. Powiązanie Workers udostępnia równoważne mechanizmy kontroli przez JavaScript lub TypeScript. Przewodnik implementacyjny Cloudflare wskazuje, że zapytanie może zawierać do 1 024 znaków, a jedno żądanie zwraca do 10 wyników.
Ten limit pokazuje, do czego zaprojektowano produkt. Jest to warstwa pobierania kontekstu dla wywołań modeli, a nie zamiennik klasycznej strony wyników wyszukiwania. Aplikacja zbiera skoncentrowany zestaw źródeł i umieszcza istotne fragmenty w kontekście roboczym modelu.
Usługa obsługuje dwie ścieżki poświadczeń. Zespoły mogą wykorzystywać kredyty AI Gateway albo przechowywać klucz dostawcy i wybierać go przez alias bring-your-own-key. Cloudflare pobiera te poświadczenia wewnątrz bramy, zamiast wymagać od aplikacji przesyłania ich przy każdym żądaniu wyszukiwania.
Ta architektura zapewnia zespołom wspólną granicę uwierzytelniania. Ogranicza też liczbę zewnętrznych poświadczeń rozproszonych między aplikacjami, systemami wdrożeniowymi i komputerami deweloperów. Przejęty token aplikacji nadal stanowi zagrożenie, ale rozrost liczby poświadczeń staje się łatwiejszy do opanowania.
Cloudflare twierdzi, że żądania wyszukiwania w sieci pojawiają się w zwykłych logach obserwowalności AI Gateway. Zespoły mogą analizować aktywność żądań obok ruchu modeli, zamiast obsługiwać osobny stos monitoringu. Zasady dostępu mogą również określać, które aplikacje docierają do konkretnych dostawców wyszukiwania.
Ta integracja tworzy główne napięcie artykułu. Bezpośrednie API wyszukiwania oferuje mniej pośredników, a brama zapewnia większą kontrolę operacyjną. Cloudflare musi udowodnić, że warstwa kontroli oszczędza więcej złożoności, niż wprowadza.
Wyszukiwanie staje się częścią stosu AI Gateway
Presja konkurencyjna spada na platformy modeli i wyspecjalizowanych dostawców wyszukiwania, ponieważ Cloudflare oddziela aktualne pobieranie danych od modelu, który je wykorzystuje.
Wiele modeli oferuje już natywne wyszukiwanie w sieci. Istniejąca dokumentacja bramy Cloudflare wymienia obsługiwane narzędzia wyszukiwania od OpenAI, Anthropic, xAI i Alibaba. Narzędzia te pozostają związane z odpowiednimi interfejsami dostawców i możliwościami modeli.
Natywne wyszukiwanie może być wygodne, gdy zespół decyduje się na jedną rodzinę modeli. Model rozstrzyga, kiedy wyszukiwać, dostawca formatuje dowody, a ta sama usługa tworzy odpowiedź. Taka ścieżka może ograniczyć pracę związaną z orkiestracją w przypadku prostego asystenta.
Staje się mniej wygodna, gdy aplikacja zmienia modele. Schematy narzędzi, obsługiwane modele, formaty cytowań, dostępność regionalna i warunki retencji mogą się różnić. Zespół może potrzebować osobnych implementacji dla każdego dostawcy, nawet jeśli każda ścieżka wykonuje to samo podstawowe zadanie pobierania danych.
Cloudflare Web Search API zmienia tę granicę. Wyszukiwanie staje się krokiem kontrolowanym przez aplikację, o wspólnym formacie odpowiedzi. Pobrane materiały mogą zasilać model dostępny przez Workers AI, model kierowany przez AI Gateway lub inną usługę wnioskowania.
To rozdzielenie ma znaczenie dla agentów, którzy często wykonują kilka wyszukiwań przed utworzeniem jednej odpowiedzi. Agent badawczy może zacząć od szerokiego zapytania, zidentyfikować firmę lub dokument, a następnie wystosować bardziej precyzyjne zapytania uzupełniające. Te wywołania wymagają przewidywalnego logowania i uprawnień, ponieważ mogą przewyższać liczbą końcowe żądanie do modelu.
Podejście oparte na bramie wspiera też jawny wybór dostawcy. Deweloper może skierować jedno obciążenie do Ceramic.ai, a inne do Exa lub Linkup. Aplikacja nie musi zmieniać całej integracji, gdy zmienia się wybrany dostawca.
Cloudflare opisuje każdego dostawcę jako obsługującego inny profil pobierania danych. Jego dokumentacja dostawców wskazuje, że Ceramic.ai korzysta z niezależnego indeksu obejmującego ponad 40 miliardów stron. Zwraca długie opisy, które mogą dostarczać agentowi znaczącego kontekstu.
Exa łączy metody słów kluczowych z wyszukiwaniem opartym na embeddingach, które porównuje reprezentacje semantyczne zamiast polegać wyłącznie na dopasowaniu terminów. Cloudflare konfiguruje ją tak, aby zwracała wyróżnienia istotne dla zapytania z pobranych stron. Ten format pasuje do promptów wymagających zwięzłych dowodów.
Linkup zwraca fragmenty ze źródłami w trybie szybkiego wyszukiwania, bez tworzenia syntetycznej odpowiedzi. Pozwala to oddzielić pobieranie danych od rozumowania. Aplikacja może zdecydować, który model analizuje wyniki i jak pojawiają się cytowania.
Te różnice dają Cloudflare powód do obsługi wielu dostawców. Jakość wyszukiwania nie jest jednowymiarowa. Świeżość, pokrycie indeksu, trafność semantyczna, opóźnienie, długość fragmentów i wybór źródeł mogą mieć większe znaczenie w zależności od zadania.
Ta sama różnorodność komplikuje też produkt. Znormalizowana odpowiedź nie czyni dostawców równoważnymi. Deweloperzy nadal potrzebują ewaluacji mierzących, czy każda usługa pobiera właściwe dowody dla ich domeny.
Cloudflare wywiera więc presję na firmy wyszukiwawcze w dwóch kierunkach. Daje im dystrybucję przez uznaną platformę deweloperską, ale jednocześnie przedstawia je jako wymienne opcje za wspólnym interfejsem. Może to przesunąć część relacji z klientem w stronę bramy.
Dostawcy modeli mierzą się z innym wyzwaniem. Ich zintegrowane narzędzia wyszukiwania mogą wspólnie optymalizować pobieranie i generowanie. Podejście Cloudflare zakłada, że wiele zespołów będzie bardziej cenić przenośność, niezależny wybór dostawcy i scentralizowane zasady niż ściśle powiązane doświadczenie.
Vercel realizuje pokrewną strategię. Jego AI Gateway niedawno dodał narzędzia search and fetch, które działają między modelami obsługującymi wywołania narzędzi. Bliskość tych premier sugeruje, że bramy rozszerzają się poza routing modeli w kierunku kompletnych warstw narzędzi dla agentów.
Nie jest to rywalizacja o to, kto pierwszy połączył model z wyszukiwaniem. Jest to rywalizacja o to, która platforma zarządza tym połączeniem. Zwycięzca kontroluje poświadczenia, logi, decyzje routingu, ustawienia retencji i powierzchnię integracji dewelopera.
Mechanizm jest prosty, ale zmiana architektoniczna większa
Cloudflare przekształca wyszukiwanie w wielokrotnego użytku prymityw pobierania danych, który aplikacje mogą wywoływać przed, w trakcie lub między wywołaniami modeli.
Podstawowy przepływ pracy rozpoczyna się od pytania użytkownika. Aplikacja wysyła to pytanie lub utworzone na jego podstawie zapytanie do Web Search API. Otrzymuje uporządkowane wyniki i umieszcza wybrane opisy w prompcie modelu.
Agent może także zdecydować, kiedy wywołać usługę. Deweloper definiuje narzędzie funkcji web_search, czyli operację wywoływalną opisaną modelowi. Gdy model zażąda tego narzędzia, kod aplikacji wykonuje wyszukiwanie i zwraca wyniki.
Model otrzymuje następnie drugie wywołanie wnioskowania zawierające oryginalne pytanie i pobrane dowody. Ten wzorzec jest często nazywany generowaniem wspomaganym narzędziami, ponieważ model zbiera zewnętrzne informacje podczas realizacji zadania. Różni się od polegania wyłącznie na wiedzy zapisanej w parametrach modelu.
Cloudflare twierdzi, że natywne narzędzia serwerowe pojawią się później. Przeniosłyby one większą część orkiestracji do samego AI Gateway. Na razie deweloperzy muszą zaimplementować pętlę, która odbiera wywołanie narzędzia, uruchamia wyszukiwanie i zwraca wynik modelowi.
To rozróżnienie jest ważne. Obecna wersja beta oferuje usługę wyszukiwania i wspólne mechanizmy kontroli bramy. Nie zapewnia jeszcze w pełni zarządzanego agenta badawczego, który określa zapytania, filtruje dowody, rozstrzyga sprzeczne źródła i tworzy odpowiedź z cytowaniami.
Samodzielna konstrukcja nadal ma przydatne zalety. Zespoły mogą sprawdzać surowe wyniki, zanim trafią do modelu. Mogą odrzucać zablokowane domeny, wymagać zatwierdzonych źródeł, usuwać zduplikowane strony lub ograniczać pobieranie do dokumentów spełniających wewnętrzną politykę zaufania.
Praktycznym przykładem jest asystent wsparcia. Gdy klient pyta o niedawno zmienione API, agent może przeszukać aktualną dokumentację, zamiast odpowiadać na podstawie starszego obrazu danych treningowych. Aplikacja może zachować pobrane URL-e do weryfikacji.
Agent programistyczny może korzystać z tego samego wzorca podczas rozwiązywania błędów. Może wyszukać nową informację o wydaniu, zmienioną opcję konfiguracji lub aktualne ostrzeżenie o zgodności. Wyniki wyszukiwania stają się dowodami, podczas gdy model pozostaje odpowiedzialny za ich interpretację.
Produkty badawcze i monitorujące mogą wysyłać kilka ukierunkowanych zapytań. Jedno żądanie może znaleźć oficjalne ogłoszenie, inne dokumentację, a trzecie sprawdzić niezależne relacje. Dobry przepływ pracy porównuje te źródła zamiast przyjmować pierwszy wynik.
Pracownicy wiedzy mierzą się z podobnym problemem w prywatnych materiałach. System musi łączyć zewnętrzne wydarzenia z notatkami, dokumentami i utrwalonym kontekstem organizacyjnym. Ten proces przypomina knowledge blending, w którym nowe dowody stają się przydatne dopiero po połączeniu z informacjami, którym użytkownik już ufa.
Brama może rejestrować wywołania pobierania danych związane z takimi przepływami pracy. Daje to operatorom wyraźniejszy zapis, gdy odpowiedź zawodzi. Mogą zapytać, czy zapytanie było słabe, dostawca pominął stronę, fragmentowi brakowało kontekstu, czy też model błędnie odczytał dobre dowody.
To rozdzielenie wspiera lepszą ewaluację. Jakość pobierania i jakość odpowiedzi można mierzyć niezależnie. Bez tego podziału odpowiedź niskiej jakości niewiele mówi o tym, czy problem spowodowało wyszukiwanie, czy generowanie.
Umożliwia to także etapowe mechanizmy awaryjne. Aplikacja może wysłać zapytanie do jednego dostawcy, sprawdzić liczbę wyników i ponowić próbę z innym dostawcą, gdy pokrycie jest słabe. Cloudflare nie twierdzi, że wersja beta automatycznie podejmuje takie decyzje dotyczące jakości, więc deweloperzy muszą je samodzielnie tworzyć i testować.
To samo dotyczy buforowania. Niektóre pytania o bieżące wydarzenia szybko się dezaktualizują, podczas gdy zapytania dotyczące stabilnej dokumentacji mogą ponownie wykorzystywać wyniki. Odpowiedzialna aplikacja potrzebuje zasad dotyczących wygasania, aktualizacji źródeł i powtarzanych żądań.
Istniejąca obsługa wyszukiwania przez gateway w Cloudflare już teraz pośredniczy w natywnych narzędziach kilku dostawców modeli. Nowe API dodaje inną ścieżkę: niezależne od dostawcy wywołanie pobierania informacji, działające niezależnie od tych natywnych narzędzi.
Oznacza to, że zespoły mają teraz dwa wzorce wyszukiwania w szerszej platformie Cloudflare. Mogą zachować natywne zachowanie narzędzi dostawcy modelu albo korzystać z nowego, samodzielnego API. Właściwy wybór zależy od przenośności, kontroli i tego, jak dużą część orkiestracji zespół chce przejąć na siebie.
Mechanizm wygląda na skromne rozszerzenie API. Architektonicznie nadaje jednak wyszukiwaniu ten sam status co inferencji, pamięci masowej, kolejkom i innym usługom kompozycyjnym. Agenci mogą traktować aktualne informacje z sieci jako infrastrukturę, a nie jako specjalną funkcję dołączoną do jednego modelu.
AI Gateway Web Search podnosi stawkę w zakresie obserwowalności
Scentralizowane logi są najcenniejsze wtedy, gdy zespoły potrafią powiązać wygenerowane twierdzenie z dokładnymi etapami pobierania informacji, które je potwierdzały.
Cloudflare przedstawia AI Gateway jako płaszczyznę sterowania dla aplikacji modelowych. Usługa już oferuje widoczność żądań, mechanizmy kontroli bezpieczeństwa i zarządzanie użyciem. Dodanie pobierania informacji rozszerza tę obserwowalność na etap, który często decyduje o aktualności odpowiedzi.
Model może rozumować ostrożnie, a mimo to wygenerować błędną odpowiedź, gdy jego dowody są niepełne. Wyszukiwanie może zwrócić nieaktualną stronę, skopiowany artykuł albo wynik używający właściwego słownictwa, ale dotyczący innego tematu. Operatorzy potrzebują widoczności, zanim będą mogli odróżnić te rodzaje błędów.
Identyfikatory żądań i metadane opóźnień stanowią punkt wyjścia. Mogą pomóc skorelować wolne lub nieskuteczne wyszukiwania z konkretnym uruchomieniem agenta. Logi mogą także ujawnić, czy aplikacja wysyła niepotrzebne zapytania albo wielokrotnie pobiera te same strony.
Logowanie ruchu wyszukiwania rodzi jednak własne pytania dotyczące zarządzania. Zapytania użytkowników mogą ujawniać poufne plany, nazwy klientów, incydenty bezpieczeństwa, kwestie medyczne lub szczegóły wewnętrznych projektów. Scentralizowany gateway musi więc jasno określać granice dostępu i zasady retencji danych.
Cloudflare podaje, że wszyscy trzej partnerzy premierowi obsługują Zero Data Retention dla żądań kierowanych przez tę usługę. Zero Data Retention oznacza, że dostawca nie zachowuje danych żądania po przetworzeniu, zgodnie z obowiązującymi ustaleniami. Nie odpowiada to jednak automatycznie na wszystkie pytania o prywatność w całej aplikacji.
Deweloper nadal kontroluje to, co trafia do zapytania. Cloudflare nadal obsługuje gateway i jego logi. Końcowy dostawca modelu otrzymuje każdy pobrany kontekst, który aplikacja mu przekazuje. Każdy etap wymaga przemyślanej polityki danych.
Obsługa własnych kluczy również wymaga starannej konfiguracji. Dokumentacja Cloudflare wskazuje, że jawny alias powoduje niepowodzenie żądania, gdy ten klucz jest niedostępny. Bez jawnego aliasu gateway może użyć skonfigurowanego klucza domyślnego lub dostępnych kredytów gatewaya.
Takie zachowanie zapewnia wygodę, lecz zespoły powinny zdecydować, czy mechanizm awaryjny jest akceptowalny. Obciążenie regulowane może wymagać konkretnej umowy z dostawcą. Niejawne przejście na inną ścieżkę komercyjną może kolidować z wewnętrznymi mechanizmami kontroli, nawet gdy wynik techniczny jest prawidłowy.
Obserwowalność musi również zachować wystarczająco dużo szczegółów do oceny, nie przechowując nadmiernej ilości wrażliwych danych. Same liczby i opóźnienia nie wyjaśnią błędów trafności. Pełne zapytania i fragmenty wyników mają większą wartość diagnostyczną, lecz zwiększają też ekspozycję.
Właściwa równowaga będzie różna w zależności od aplikacji. Publiczny asystent informacyjny może logować więcej szczegółów pobierania niż wewnętrzny system badań prawnych. Przewaga Cloudflare zależy od tego, czy administratorzy mogą wyrazić te różnice za pomocą zrozumiałych zasad.
Kontrola operacyjna obejmuje także zapobieganie nadużyciom. Agent uwięziony w pętli narzędzi może wysyłać wiele powtarzanych wyszukiwań. Limity szybkości, budżety żądań i uprawnienia dla poszczególnych aplikacji mają znaczenie, ponieważ pobieranie informacji może stanowić istotną część aktywności agenta.
Scentralizowane logi pomagają zidentyfikować takie zachowanie. Same go jednak nie zapobiegają. Zespoły nadal potrzebują maksymalnej liczby wywołań narzędzi, limitów czasu, zasad dotyczących domen i jasnych warunków zakończenia w swoim frameworku agentowym.
Ta sama zasada dotyczy bezpieczeństwa. Wyniki wyszukiwania zawierają niezaufany tekst, a strony internetowe mogą obejmować instrukcje mające manipulować agentem. Prompt injection występuje, gdy zewnętrzna treść próbuje zastąpić zamierzone zasady aplikacji.
Znormalizowana odpowiedź wyszukiwania nie neutralizuje złośliwej treści. Model nadal może zinterpretować wrogi fragment jako instrukcję. Deweloperzy powinni oznaczać pobrany materiał jako dowód, ograniczać działania dostępne po pobraniu i unikać umieszczania sekretów w kontekstach z włączonymi narzędziami.
Nowe API ułatwia centralizację tych praktyk, lecz nie może ich zastąpić. Cloudflare sprzedaje lepszy punkt kontroli. Klienci nadal odpowiadają za zachowanie agenta działającego za tym punktem.
Zasady dla crawlerów tworzą użyteczną obietnicę i trudny test
Cloudflare wiąże premierę z odpowiedzialnym crawlowaniem, lecz zgodność nie gwarantuje kompletnych, dokładnych ani reprezentatywnych wyników wyszukiwania.
Firma wymaga, aby uczestniczący dostawcy identyfikowali swoje crawlery, respektowali robots.txt i umieszczali linki do pobranych treści. Podaje także, że crawlery dostawców muszą spełniać wymagania Cloudflare dotyczące zweryfikowanych botów.
Zweryfikowany bot to zautomatyzowana usługa, której tożsamość Cloudflare potwierdziło. Weryfikacja daje operatorom witryn wyraźniejszy sygnał przy podejmowaniu decyzji, czy zezwolić crawlerowi na dostęp, czy go blokować. Zmniejsza niejednoznaczność w porównaniu z niezidentyfikowanym ruchem twierdzącym, że reprezentuje firmę wyszukiwawczą.
Cloudflare przedstawia to jako standard sprawiedliwszej relacji między usługami wyszukiwania AI a wydawcami. Polityka zapewnia twórcom większą widoczność tego, kto uzyskuje dostęp do ich stron. Linki do źródeł pozwalają także użytkownikom sprawdzać materiał źródłowy.
Te zobowiązania odróżniają premierę od nieprzejrzystego scrapingu. Są szczególnie istotne, ponieważ wydawcy coraz częściej kwestionują sposób, w jaki systemy AI pozyskują, streszczają i komercjalizują treści internetowe. Dostawcy wyszukiwania potrzebują dostępu, podczas gdy właściciele witryn chcą egzekwowalnej kontroli.
Kompromis polega na tym, że pełne szacunku crawlowanie może ograniczyć zasięg. Niektóre witryny blokują automatyczny dostęp, ograniczają konkretne boty albo umieszczają materiały za uwierzytelnianiem. Wyniki wyszukiwania mogą odzwierciedlać wyłącznie strony, które dostawca zindeksował i nadal ma prawo wykorzystywać.
Trzej dostawcy mogą zatem zwracać różne obrazy sieci. Korzystają z odrębnych indeksów, systemów rankingu, harmonogramów odświeżania i procesów generowania fragmentów. Wspólny schemat API ukrywa te szczegóły implementacyjne, nie eliminując ich skutków.
Atrybucja źródeł stwarza kolejne wyzwanie. Zwrócenie adresu URL jest konieczne, ale nie dowodzi, że wygenerowana odpowiedź dokładnie przedstawia treść strony. Aplikacje muszą zachowywać związek między każdym twierdzeniem a wynikiem, który je wspiera.
Końcowy model może połączyć kilka fragmentów w stwierdzenie, którego żadne źródło wprost nie potwierdza. Może też przeoczyć daty publikacji lub pomylić zaktualizowany dokument ze starszą wersją. Obecności cytowania nie należy mylić z dokładnością cytowania.
Ranking wyszukiwania dodaje kolejną niepewność. Strony silnie zoptymalizowane mogą wyprzedzać źródła pierwotne. Kopie syndykowane mogą być bardziej widoczne niż oryginalne materiały. Pobrany opis może pomijać zastrzeżenia, które stają się oczywiste dopiero na pełnej stronie.
Obecne API Cloudflare zwraca wyniki wyszukiwania, a nie weryfikację pełnej strony. Aplikacja wymagająca wysokiego poziomu pewności powinna pobierać ważne strony, sprawdzać ich treść, porównywać daty i preferować dokumenty pierwotne. Jedno wywołanie wyszukiwania służy odkrywaniu, a nie dowodzeniu.
Opóźnienia mogą również wpływać na decyzje dotyczące jakości. Agenci często działają w ramach budżetów czasu odpowiedzi, więc deweloperzy mogą wybrać szybkiego dostawcę lub zakończyć pracę po pierwszym wiarygodnie wyglądającym wyniku. Taka optymalizacja może kolidować z potrzebą weryfikacji wrażliwego twierdzenia za pomocą kilku źródeł.
Status beta ma tu znaczenie. Cloudflare udokumentowało interfejs i cechy dostawców, lecz publiczne dowody dotyczące porównawczej trafności pozostają ograniczone. Deweloperzy powinni traktować opisy dostawców jako wskazówki projektowe, a nie niezależnie zweryfikowane rankingi wydajności.
Nie istnieje też uniwersalny benchmark dla każdej aplikacji. Dostawca dobrze radzący sobie z dokumentacją oprogramowania może mieć trudności z lokalnymi wiadomościami, literaturą naukową lub mało znanymi dokumentami spółek. Zespoły potrzebują zestawów testowych opartych na własnych spodziewanych zapytaniach.
Użyteczna ocena powinna rejestrować, czy właściwa strona się pojawia, jak wysoko jest klasyfikowana, jak jest aktualna oraz czy fragment zachowuje istotny kontekst. Powinna też testować strony antagonistyczne, niejednoznaczne nazwy i zapytania ze zmieniającymi się odpowiedziami.
Koszt należy uwzględnić w tej ocenie, nawet gdy dokładne warunki komercyjne są różne. Przepływy agentowe mogą zwielokrotnić jedno pytanie użytkownika do kilku wyszukiwań i wywołań modeli. Zespoły powinny mierzyć całkowity koszt zadania, zamiast porównywać pojedyncze żądanie.
Pozycjonowanie Cloudflare jako rozwiązania bez narzutu zmniejsza jedną z obaw, lecz nie określa wartości. Droższa ścieżka pobierania może być opłacalna, jeśli pozwala uniknąć dodatkowych wywołań lub poprawia dokładność odpowiedzi. Tańsza ścieżka może stać się kosztowna, gdy słabe wyniki wywołują ponowne próby.
Standard dla crawlerów nadal jest istotną częścią ogłoszenia. Cloudflare wykorzystuje swoją pozycję między witrynami a zautomatyzowanymi klientami, aby ustalać wymagania uczestnictwa. Test polega na tym, czy te zasady zapewnią rozliczalne pobieranie informacji bez tworzenia martwych punktów, których deweloperzy nie zauważą.
Co deweloperzy powinni obserwować po premierze wersji beta
Kolejna faza pokaże, czy Cloudflare Web Search API stanie się trwałym prymitywem gatewaya, czy pozostanie wygodną nakładką na endpointy partnerów.
Pierwszym sygnałem będzie pojawienie się natywnych narzędzi serwerowych. Cloudflare podaje, że wyszukiwanie w sieci będzie jednym z pierwszych narzędzi zintegrowanych bezpośrednio z płaszczyzną sterowania AI Gateway. To wydanie ograniczyłoby kod orkiestracji, który deweloperzy obecnie utrzymują.
Użyteczna implementacja narzędzia serwerowego musi robić więcej niż ukrywać wywołanie funkcji. Deweloperzy powinni obserwować, jak obsługuje uprawnienia narzędzi, maksymalną liczbę użyć, ponowne próby, limity czasu, pochodzenie wyników i wybór dostawcy. Te mechanizmy kontroli decydują o tym, czy zespoły mogą bezpiecznie wykorzystywać je w agentach produkcyjnych.
Jeśli narzędzia serwerowe zachowają wspólne działanie między modelami, teza Cloudflare dotycząca gatewaya stanie się silniejsza. Platforma kontrolowałaby zarówno dostęp do modeli, jak i orkiestrację pobierania informacji. Jeśli każdy model nadal będzie wymagał znacznej obsługi niestandardowej, korzyść zawęzi się do rozliczeń i obserwowalności.
Drugim sygnałem będzie mierzalna przenośność między dostawcami. Wspólny format odpowiedzi Cloudflare sprawia, że przełączanie wygląda na proste na poziomie API. Rzeczywista przenośność wymaga porównywalnej jakości wyników, przewidywalnej obsługi błędów i stabilnego działania pod obciążeniem produkcyjnym.
Zespoły powinny uruchamiać te same zestawy zapytań przez Ceramic.ai, Exa i Linkup. Powinny porównywać pokrycie źródeł, aktualność, ranking, opóźnienia i użyteczność fragmentów. Powinny również sprawdzać, jak wyniki zmieniają się w przypadku pytań niejednoznacznych lub antagonistycznych.
Mocne strony charakterystyczne dla dostawcy są wartościowe tylko wtedy, gdy deweloperzy mogą je wybierać świadomie. Jeśli większość aplikacji pozostanie przy ustawieniu domyślnym bez oceny, element marketplace'u stanie się mniej znaczący. Jeśli zespoły będą kierować ruch według rodzaju obciążenia, Cloudflare zyska trudną do podważenia rolę koordynacyjną.
Trzecim sygnałem jest reakcja konkurencji. Vercel już udostępnia narzędzia wyszukiwania na poziomie gatewaya, podczas gdy firmy tworzące modele nadal rozwijają natywne przeglądanie sieci. Inne platformy chmurowe mogą łączyć wyszukiwanie, modele i środowiska uruchomieniowe agentów w ramach własnych płaszczyzn kontroli.
Warto obserwować, czy konkurenci dodają więcej niezależnych dostawców wyszukiwania, skuteczniejsze narzędzia ewaluacyjne lub ujednolicone formaty cytowań. Ta reakcja pokaże, czy niezależne od dostawcy wyszukiwanie stanie się standardową funkcją gatewaya, czy jedynie tymczasowym wyróżnikiem.
Deweloperzy powinni także śledzić zmiany w politykach dotyczących botów i kontrolach wydawców. Jakość pozyskiwania informacji zależy od utrzymania dostępu do użytecznych źródeł. Rosnący podział między treściami dostępnymi dla crawlerów a ograniczonymi wpłynąłby na każdego dostawcę, nawet jeśli każdy crawler przestrzega deklarowanych zasad.
Na początek wybierz zadanie, którego odpowiedzi często się zmieniają i mają możliwe do zidentyfikowania źródła pierwotne. Informacje o wydaniach, statusie usług, dokumentacja produktów i publiczne zgłoszenia regulacyjne oferują wyraźniejsze cele ewaluacyjne niż szerokie pytania o opinie.
Przed zintegrowaniem wyszukiwania z agentem dostępnym dla użytkowników utwórz niewielki benchmark. Zapisz oczekiwane źródło, akceptowalną datę publikacji oraz fakty, które musi zawierać poprawna odpowiedź. Następnie osobno przetestuj pozyskiwanie informacji i generowanie odpowiedzi.
W miarę możliwości zachowuj adresy URL źródeł w interfejsie aplikacji. Użytkownicy powinni mieć możliwość sprawdzenia dowodów, zwłaszcza gdy odpowiedź wpływa na istotną decyzję. Cytowanie powinno potwierdzać konkretne twierdzenie, a nie jedynie ozdabiać całą odpowiedź.
Ustal budżet wyszukiwania dla każdego zadania. Ogranicz powtarzające się zapytania, zatrzymuj zapętlone wywołania narzędzi i wymagaj dodatkowego potwierdzenia, zanim agent podejmie działanie zewnętrzne. Wyszukiwanie dostarcza modelowi nowych informacji, ale nie nadaje im autorytetu.
Premiera Introducing Web Search API via AI Gateway ostatecznie skłania deweloperów do ponownego rozważenia, gdzie powinno znajdować się wyszukiwanie. Czy jest funkcją modelu, bezpośrednią relacją z dostawcą czy wspólną usługą kontrolowaną przez platformę aplikacyjną?
Cloudflare przedstawił wiarygodne argumenty za modelem wspólnej usługi. Beta łączy trzech dostawców, jeden interfejs, logi gatewaya, zarządzanie poświadczeniami oraz jasno określone standardy dla crawlerów. Jej wartość będzie zależeć od niezawodności, jakości pozyskiwania informacji i obiecanej warstwy narzędzi serwerowych.
Dla zespołów, które już korzystają z AI Gateway lub Workers, praktycznym kolejnym krokiem jest kontrolowana ewaluacja na rzeczywistych zapytaniach. Porównaj trzech dostawców, sprawdź każde źródło i zmierz kompletne wyniki zadań. Czy niezależna warstwa wyszukiwania ulepszy Twojego agenta, czy kolejna granica gatewaya stworzy więcej pracy, niż wyeliminuje?
