Architektūros kūrimas ir vertinimas dirbtinio intelekto pirmai paieškos API

Keičiamo mastelio, dirbtiniu intelektu pagrįstos paieškos API kūrimas kelia unikalių tyrimų uždavinių informacijos paieškos, dirbtinio intelekto ir sistemų dizaino sankirtoje. Skirtingai nuo tradicinių paslaugų, veikiančių su apibrėžtais duomenimis, paieškos API turi nuolat indeksuoti milijardus dokumentų, suprasti užklausos ketinimą įvairiomis kalbomis bei domenais ir per milisekundes pateikti svarbius rezultatus. Dirbtinio intelekto agentų pasaulyje paieškos API taip pat turi kruopščiai parinkti kontekstą, pateikiamą kūrėjų modeliams, kad būtų užtikrintas optimalus šių modelių veikimas ir įtraukta maksimaliai tiksli informacija. Veiksmingam konteksto konstravimui reikia, kad API ne tik fiksuotų dokumento lygmens svarbą, bet ir traktuotų atskiras dokumentų dalis bei atkarpas kaip lygiaverčius vienetus.

Šiame straipsnyje pristatome „Perplexity“ paieškos API dizainą ir įvertinimą. Pirmiausia išnagrinėjame architektūrą bei pagrindinius techninius sprendimus, kuriais pagrįsta mūsų gamybinė paieškos infrastruktūra, apdorojanti 200 milijonų užklausų per dieną. Mūsų architektūra sujungia hibridinius paieškos mechanizmus, daugiapakopius reitingavimo konvejerių, paskirstytąjį indeksavimą ir dinaminį jūsų turinio supratimo modulio analizavimą.

Tada aprašome savo požiūrį į empirinį paieškos API našumo vertinimą naudojant naujai atvirojo kodo vertinimo sistemą. Atlikę išsamius lyginamuosius testus su esamomis komercinėmis API, pademonstruojame aukščiausio lygio kokybės ir delsos rodiklius. „Perplexity“ paieškos API šiandien tampa prieinama kūrėjams visame pasaulyje.

[Rasti search_evals „GitHub“]

Paieškos sistemos, optimizuotos dirbtinio intelekto modeliams, kūrimas

Nuo pat įkūrimo pradžios supratome, kad patikimos paieškos galimybės bus esminės norint sukurti kategoriją apibrėžiančius dirbtinio intelekto produktus, kuriuos norėjome pristatyti. Iš pradžių tikėjomės, kad šios galimybės jau egzistuoja viešai prieinama forma. Eksperimentavome su 2002 m. pabaigoje prieinamu paieškos API portfeliu, o pati pirmoji „Perplexity“ atsakymų variklio versija iš tikrųjų integruodavo kai kuriuos iš šių pasiūlymų. Konkrečiai, analizuodavome vartotojų užklausas, formuluodavome ir siųsdavome užklausas šioms API bei rinkdavome rezultatus kaip kontekstą mūsų tolesniam generavimo konvejeriui.

Tačiau vartotojams plūstant į „Perplexity“, greitai supratome, kad šios API neaugs kartu su mūsų plėtra. Susidūrėme su milžiniškomis kainomis – vienas pirmaujantis API teikėjas taikė 200 JAV dolerių mokestį už tūkstantį užklausų. Bet kas dar pavojingiau – šios senstelėjusios API paprasčiausiai nebuvo pritaikytos naujoms paieškos paradigmoms, kurias pristatė pažangiausios dirbtinio intelekto sistemos.

Padidinti

Pirma, šių senstelėjusių API užklausų ir atsakymų formatai buvo sukurti pasauliui, kuriame žmonės būtų išskirtiniai paieškos rezultatų vartotojai. Dėl to šios API teikė pirmenybę dokumento lygmens rezultatams, ignoruodamos smulkesnę informaciją, kurią atskleidžia po-dokumentiniai vienetai. Dirbtinio intelekto modelio sėkmė priklauso nuo pateikto konteksto kokybės ir glaustumo, ir mes iš arti pamatėme, kaip pernelyg plati paieškos apimtis gali sužlugdyti dirbtinio intelekto modelius, nepriklausomai nuo to, kiek gauti dokumentai kaip visuma atrodo svarbūs. Mūsų bandymai įsprausti tikslumą į netikslius rezultatus davė nedidelių vaisių.

Taip pat pastebėjome, kad senstelėjusios API buvo arba per pasenusios, arba per lėtos. Nepriklausomai sukurtos paieškos API rėmėsi indeksais, kurie buvo nekomplektiški ir atnaujinami per retai. Ekranų kopijavimu (angl. scraping) pagrįstos API, pavyzdžiui, įvairios neoficialios „Google“ paieškos SERP API, turėjo naudos iš išsamesnio indekso, tačiau pasižymėjo nepriimtinai didele delsa dėl neefektyvumo, kuris būdingas užklausų siuntimui trečiosios šalies paieškos varikliui. Dėl didelės delsos API tapo netinkamos vartotojams skirtoms programoms, o pasenimas užklausų rinkinius pavertė netinkamais naudoti bet kuriai dirbtinio intelekto sistemai, siekiančiai būti tiksliai ir patikimai.

Galiausiai pastebėjome, kad dirbtinio intelekto ekosistema išsišakojo į leksinę ir semantinę paieškas, atsirandant sistemoms, kurios buvo per daug optimizuotos vienai modalumui kito sąskaita. Pamatėme vektorių duomenų bazių iškilimą, kurios negalėjo deramai palaikyti net paprastų Būlio filtrų. Tradicinės paieškos posistemės pasirodė ne geriau, turėdamos primityvų palaikymą semantiniam reitingavimui ir paieškos galimybėms, kurias atrakino dirbtinis intelektas.

Supratę, kad norint padaryti „Perplexity“ dar geresne reikės sukurti savo specializuotą paieškos infrastruktūrą, savo pastebėjimus apibendrinome į tris pagrindinius kriterijus:

Išsamumas, naujumas ir greitis: paieškos indeksas turi būti išsamus, nuolat atnaujinamas ir pritaikytas realaus laiko delsai.

Smulkmeniškas turinio supratimas: dirbtinio intelekto modelio trapumas ir riboti konteksto langai reikalauja, kad paieškos rezultatai būtų pateikiami ir reitinguojami kuo smulkesniu lygiu.

Hibridinė paieška ir reitingavimas: tiek paieškos, tiek reitingavimo konvejeriai turi apimti leksinius ir semantinius signalus, kad rezultatai būtų naudingi dirbtiniam intelektui.

Padidinti

Indeksavimo ir duomenų rinkimo infrastruktūra

Veikimas „Perplexity“ mastu reikalauja infrastruktūros, galinčios išsamiai atvaizduoti žiniatinklį ir reaguoti į nuolatinę jo evoliuciją. Mūsų paieškos indeksas seka per 200 milijardų unikalių URL adresų, turėdamas pajėgumų stebėti dar daug šimtų milijardų.

Užtikrinti, kad mūsų indeksas apimtų pakankamai išsamią interneto dalį ir kad kiekvienas dokumentas atspaudintų naujausią būseną, yra sunkus žygdarbis. Tarp išsamumo ir naujumo tvyro vidinė įtampa: esant fiksuotam indeksavimo biudžetui, esamų puslapių atnaujinimo operacijos turi konkuruoti su naujų, neaplankytų puslapių indeksavimo operacijomis. Šią įtampą suderiname derindami mastelio keitimą (kuris palengvina optimizavimo suvaržymą didinant indeksavimo biudžetą) ir mašininiu mokymusi pagrįstą prioritetų nustatymą (kuris užtikrina, kad kiekviena indeksavimo operacija būtų maksimaliai vertinga visam indeksui).

Sukūrėme egzabaito mastelio indeksavimo ir duomenų rinkimo aparatūrą, kuri horizontaliai plečiasi tiek su dydžiu, tiek su užklausų apimtimi. „Perplexity“ naršyklės ir indeksavimo parkai kartu apima dešimtis tūkstančių procesorių ir šimtus terabaitų RAM, turėdami didelę atsargą tolesniam mastelio keitimui. Šią skaičiavimo infrastruktūrą deriname su šaltosios ir šiltosios atminties pusiausvyra. Naudojame ir išmokytus modelius, ir pritaikytas euristikas, kad nustatytume, kuriuos dokumentus reikėtų laikyti aktyvioje atmintyje, teikdami pirmenybę autoritetingų domenų dokumentams, nepakankamai nušviestų temų dokumentams ir kitoms kategorijoms, turinčioms didelį potencialą praturtinti mūsų indeksą.

Ši infrastruktūra leidžia „Perplexity“ apdoroti dešimtis tūkstančių indeksavimo operacijų per sekundę. Tačiau net ir turint tokį santykinai dosnų biudžetą, interneto mastas yra per didelis, kad būtų galima dažnai ir periodiškai indeksuoti kiekvieną atskirą URL. Čia pagalbą pasitelkiamas mašininis mokymasis. Apmokome mašininio mokymasis modelį, kuris prognozuoja, ar kurį nors tam tikrą kandidatą URL reikia indeksuoti. Mokymo tikslas suformuotas taip, kad užtikrintume indeksavimo sprendimo kalibravimą tiek pagal konkretaus URL svarbą, tiek pagal numatomą atnaujinimo dažnumą. Taip pat remiamės mašininiu mokymusi, kad tiksliai sužinotume, kada suplanuoti indeksavimo operaciją. Svetainėms su įprastu publikavimo ir atnaujinimo ciklu tai leidžia atidėti operacijas iki to laiko, kai jos bus naudingos labiausiai. Nuolat tobulindami šiuos mašininio mokymosi modelius, sugebame palaikyti indeksą, kuris atitinka tiek išsamumo, tiek naujumo reikalavimus.

Nors mūsų duomenų rinkimo infrastruktūra lengvai plečiasi horizontaliai, suprantame, kad svetainių operatoriai susiduria su skirtingais techniniais apribojimais. Esame atsargūs ir palaikome nuspėjamą bei valdomą užklausų dažnį bet kuriam domenui. „PerplexityBot“, mūsų paieškos naršyklė, laikosi aiškių apribojimų, nustatytų robots.txt failuose, arba nesant domeno nustatytų apribojimų – pramonės standarto normų dėl užklausų dažnio. Taip pat koreguojame savo naršymo elgseną, kai aptinkame svetainės nepasiekiamumą. Mūsų paskirstyta sistema sukurta taip, kad šie apribojimai būtų taikomi net ir atliekant dešimtis tūkstančių vienalaikių operacijų.

Savarankiškai tobulėjantis turinio supratimas interneto mastu

Net ir turint vieną didžiausių ir naujausių paieškos indeksų planetoje, kiekvienos užklausos rezultatų kokybė priklauso nuo to, kaip mūsų sistema supranta kiekvieno dokumento turinį. Čia susiduriame su esminiu iššūkiu: žiniatinklis yra chaotiška vieta. Jokia fiksuotų analizės taisyklių aibė negali susidoroti su begaline maketų, struktūrų ir stilių įvairove, randama visame internete.

Šį iššūkį išsprendėme sukurdami turinio supratimo modulį, kuris analizuoja svetaines ir išskiria semanticiškai prasmingą turinį naudodamas dinamines taisyklių rinkinius. Svetainė, kurioje gausu gerai struktūruotų duomenų sąrašų arba lentelių forma, gali gauti naudos dinamiškesnių analizės ir išskyrimo taisyklių, o kita svetainė, kurioje daugiausia dominuoja laisvos formos vartotojo sukurtas turinys, gali reikalauti laisvesnio taisyklių rinkinio. Kadangi žiniatinklis per trumpus laiko tarpus iš esmės yra statiškas, pastebime, kad konkrečios taisyklės gyvavimo trukmė yra palyginti ilga. Tačiau svetainėms evoliucionuojant laikui bėgant ir mums sužinant daugiau apie geriausius būdus informacijai išgauti, mūsų taisyklių rinkiniams taip pat reikalingas nuolatinis tvarkymas.

Siekdami palengvinti šį dinaminį pritaikymą, (žinoma) kreipiamės į dirbtinį intelektą. „Perplexity“ mastu matome neįtikėtinai turtingą žiniatinklio pjūvį kas valandą aptarnaudami milijonus vartotojų užklausų. Tai sudaro pagrindą kartotiniam savarankiško tobulėjimo ciklui. Stebime analizės elgseną ir išskirtas esamų taisyklių rinkinių išvestis visoje mūsų užklausų visatoje. Tada naudojame pažangiausius didelius kalbos modelius (LLM), kad įvertintume našumą pagal du pagrindinius matmenis:

Išsamumas: mūsų indeksas turėtų gauti kuo daugiau semanticiškai prasmingo turinio, kartu vengiant neinformatyvios arba nesąmoningos medžiagos išskyrimo.

Kokybė: mūsų indeksas remiasi turiniu, kuris yra aukštos kokybės tiek turinio, tiek formos prasme. Informacija turi būti fiksuojama taip, kad būtų išsaugota originali turinio struktūra ir maketas.

Atkreipkite dėmesį, kad išsamumas ir kokybė kelia dar vieną vidinę įtampą: rankiniu būdu optimizuoti kokybę įmanoma, tačiau gautos analizės taisyklės gali nesugebėti užfiksuoti svarbaus turinio. Panašiai galėtume rankiniu būdu užkoduoti leidžiančias taisykles, kurios taiko minimalų filtravimą žaliajam turiniui, o tai galėtų pagerinti išsamumą, bet kokybės sąskaita. Štai kodėl kreipiamės į dirbtiniu intelektu pagrįstą savarankišką tobulėjimą, kad išvystytume savo taisyklių rinkinį taip, kad būtų galima optimizuoti abu aspektus vienu metu adaptyviu būdu.

Konkrečiai, po kiekvieno didžiųjų kalbos modelių (LLM) atlikto analizės našumo įvertinimo mūsų sistema suformuluoja siūlomų taisyklių rinkinio pakeitimų rinkinį, skirtą spręsti reikšmingiausias klaidų klases. Šie taisyklių rinkiniai yra papildomai tikrinami, po to naująją versiją įdiegiame savo indekse. Atsižvelgiant į tai, kad analizės ir išskyrimo logikos patobulinimai gali būti naudingi tik būsimoms indeksavimo operacijoms, mūsų investicijos į mašininio mokymosi optimizuotą pakartotinį indeksavimą yra ypač svarbios: nuolatinis didelio srauto dokumentų atnaujinimas naudojant naujausią šios logikos versiją užtikrina tvirtą savarankiško tobulėjimo ciklą.

Šios taisyklės yra svarbios ne tik bazinei analizės našumui, bet ir segmentavimui į po-dokumentinius vienetus. Kalbant apie pažangiausius didelius kalbos modelius (LLM), kiekvienas konteksto žetonas yra brangus. Daugybė ankstesnių tyrimų dokumentavo, kaip LLM našumas mažėja didėjant konteksto dydžiui ir teršiant kontekstą nesvarbia informacija. Turėdami gerai struktūruotą, išsamią analizę, galime suskaidyti dokumentus į savaime pakankamas atkarpas, kurių kiekvieną galima atskirai gauti ir reitinguoti užklausos metu.

Paieškos ir reitingavimo konvejeris

Šiuolaikinė paieška reikalauja užtikrinti tiek išsamumą, tiek svarbą esant griežtam delsos biudžetui. „Perplexity“ paieškos ir reitingavimo konvejeris tai pasiekia per daugiapakopę architektūrą, kuri palaipsniui tobulina rezultatus naudodama vis sudėtingesnių modulių seriją. Galimas kliūtis sprendžiame horizontaliai plečias bet kokius galimus susiaurėjimus iki maksimalaus įmanomo lygio.

Konvejeris prasideda paieška iš mūsų indekso. Mes neperšame pasirinkimo tarp leksinės ir semantinės paieškos. Vietoj to pateikiame užklausą paieškos indeksui per abi modalumus ir sujungiame rezultatus į hibridinį kandidatų rinkinį. Šiame etape prioritetas teikiamas išsamumui, o ne tikslumui – vėlesni konvejerio etapai optimizuos tikslumą.

Konvejeris tęsiasi su išankstinio filtravimo etapais, kuriuose taikome pagrindines euristikas ir pirminius filtrus, kad iš kandidatų rinkinio pašalintume akivaizdžiai nereaguojantį arba pasenusį turinį.

Tuomet pasitelkiame kelis palaipsniui pažangėjančio reitingavimo etapus. Ankstyvieji etapai remiasi greičiui optimizuotais leksiniais ir įterpiniais pagrįstais vertintojais. Kandidatų rinkiniui pamažu mažėjant, naudojame galingesnius kryžminio kodavimo (angl. cross-encoder) perrinkimo modelius, kad atliktume galutinį rezultatų rinkinio formavimą. Dėl gausių investicijų į inferencijos našumą galime išnaudoti pažangiausias modelių architektūras šiems vėlesniems etapams, kartu išlaikydami žemą bendrą reitingavimo delsą.

Viso šio konvejerio metu mes gauname ir įvertiname rezultatus tiek dokumento, tiek po-dokumentiniuose lygmenyse. Kaip aptarta pirmiau, dirbtiniam intelektui reikia kruopščio konteksto konstravimo. Mūsų konvejeris sukurtas taip, kad modeliui pateiktų pačius atominius vienetus, kad tolesni vartotojai galėtų įtraukti tuos tikslius vienetus netraukdami nesvarbaus konteksto iš kitų šaltinio dokumentų vietų.

Užtikrinti aukštą kokybę kiekviename šio konvejerio etape įmanoma tik kartu kuriant su „Perplexity“ produktų portfeliu. Kiekviena reitingavimo steko detalė sukurta taip, kad išnaudotų turtingą signalą, kurį sukuria milijonai vartotojų užklausų, aptarnaujamų kiekvieną paros valandą. Didžioji dalis šio signalo yra automatizuota, o kiekvienas sugeneruotas „Perplexity“ atsakymas suteikia empirinį duomenų tašką apie paieškos kokybę, naudojamą realiame agentiniame darbo eigoje. Deriname dirbtinio intelekto pagrįstus vertinimus su tiesioginiu žmonių grįžtamuoju ryšiu, kad praturtintume savo įterpimo ir reitingavimo modelių mokymo duomenis gerokai labiau, nei gali pasiūlyti bet kuris rankiniu būdu sudarytas duomenų rinkinys.

Ši sinergija tarp paieškos ir produkto yra unikali „Perplexity“. Senstelėjusios paieškos varikliai apsiriboja grubiu signalu, teikiamu mėlynųjų nuorodų telemetrijos. Naujesni paieškos pasiūlymai bandė įgyvendinti kai kurias iš šių į priekį orientuotų dirbtinio intelekto koncepcijų, tačiau jiems trūksta realaus pasaulio aplinkų, kurios galėtų patvirtinti paieškos kokybę ir suteikti signalo sodrumą, reikalingą greitiems tobulėjimo ciklams. Esame laimingi turėdami trūkstamą ingredientą: gyvą paieškos kokybės bandymų poligoną, kurį maitina pažangiausi dideli kalbos modeliai ir kurį nuolat testuoja milijonai smalsių vartotojų visame pasaulyje.

Naujos kokybės ir našumo ribos nustatymas

Sukūrę Perplexity Search API ir SDK, kad mūsų paieškos infrastruktūra būtų prieinama kūrėjams visame pasaulyje, norėjome suprasti, kaip įvairūs komerciniai API pasiūlymai atitinka realaus pasaulio dirbtinio intelekto naudojimo atvejus. Tapo įprasta vertinti paieškos modelius, tačiau mums reikėjo šio šablono posūkio: įvertinti paieškos API kokybę, kai jas iškviečia dirbtinio intelekto modeliai.

Pirmiausia kreipėmės į atvirojo kodo ekosistemą, kad suprastume ankstesnį darbą. Radome daug pagrindinių ingredientų griežtam vertinimui, tačiau jokia sistema neintegravo šių ingredientų į paruoštą naudoti lyginamųjų testų sprendimą. Todėl nusprendėme sukurti vertinimo sistemą, kurią galėtų naudoti ne tik „Perplexity“, bet ir bet kuris tyrėjas ar kūrėjas, siekiantis atlikti paieškos API lyginamuosius testus.

Naudodami šią vertinimo sistemą, griežtai palyginome „Perplexity Search API“ su kitais pasiūlymais. Paieškos našumo optimizavimas yra sudėtingas, su daugybe niuansuotų kompromisų tarp kokybės ir greičio. Tai pergalė kūrėjams: nustatėme, kad „Perplexity Search API“ nustato naują kokybės ir delsos standartą. Kūrėjams nebereikia rinktis tarp žaibiškai greitų programų kūrimo ir aukštos kokybės rezultatų užtikrinimo – su „Perplexity“ jie gali gauti abu.

Padidinti

Patikimų vertinimų kūrimas agentinės paieškos darbo eigoms

Pradėjome apibrėždami tris pagrindinius mūsų vertinimo sistemos principus:

Kompleksiškumo spektras: vertinimo sistema turėtų matuoti našumą tiek tiesmukuose, tiek sudėtinguose agentinio dirbtinio intelekto naudojimo atvejuose.

Neutralumas: vertinimo sistema turėtų vertinti visas API lygiomis sąlygomis.

Paprastumas: nors tam tikri naudojimo atvejai gali būti sudėtingi, pati sistema turėtų būti kuo paprastesnė, kad kiti galėtų ją suprasti, atgaminti rezultatus ir išplėsti sistemą su minimaliu vargu.

Mūsų lengva vertinimo sistema search_evals pasiekia šiuos tikslus naudodama paprastą moduliniu dizainu pagrįstą struktūrą. Sukūrėme du dirbtinio intelekto agentų įrankių rinkinius, skirtus užfiksuoti tiek klasikinius vienkartinės paieškos naudojimo atvejus, tiek pažangias agentines darbo eigas (kurių pavyzdys yra įvairūs vartotojų rinkoje plačiai prieinami „giluminis tyrimas“ produktai). Abu rinkiniai buvo įgyvendinti paprastu būdu, nepaliekančiu daug vietos paslėptam pranašumui.

Siekdami paskatinti mūsų vertinimus, pritaikėme keturis lyginamuosius testus: SimpleQA ir FRAMES vieno žingsnio paieškai bei BrowseComp ir HLE giluminiams tyrimams. Kartu šie testai suteikia gerai priimtus matus žinių agentams. Laikydamiesi nusistovėjusių konvencijų, visus testus vertiname naudodami tą pačią užuominų klasifikatoriaus metodologiją, naudotą pradiniame darbe. Tikslias testų implementacijas (įskaitant vertintojo logiką) galima peržiūrėti mūsų „GitHub“ saugykloje.

Sukurėme sistemą turėdami omenyje atkuriamumą ir išplečiamumą. Su kiekvienu paleidimu saugomi tiek užduoties lygmens balai, tiek pagrindiniai agento rezultatai. Papildomus įrankius, testus ir paieškos API pasiūlymus galima lengvai integruoti. Tyrėjai ir kūrėjai gali paskaityti mūsų „GitHub“ dokumentaciją, jei nori daugiau informacijos apie sistemos išplėtimą siekiant patenkinti jūsų tikslius poreikius.

Vertinimo rezultatai

Ginkluoti šia vertinimo sistema, nusprendėme įvertinti savo paieškos API palyginti su kitais API pasiūlymais. Visuose išbandytuose testuose „Perplexity“ išsiskiria kaip greičiausia ir aukščiausios kokybės API rinkoje.

Padidinti

Nustatėme, kad mūsų anksčiau aprašytos investicijos į indekso, paieškos ir reitingavimo efektyvumą atsipirko su kaupu. „Perplexity“ mediana (delika) siekia 358 ms, ya 150 ms lenkė antrą pagal greitumą teikėją. 95-ojo procentilio delsa patogiai išlieka žemiau 800 ms. Esant ilgesniems dabartinių pažangiausių modelių TTFT (laiko iki pirmojo žetono) metrikoms, kiekviena milisekundė svarbi kuriant puikią vartotojo patirtį. Pastaruosius dvejus metus praleidome optimizuodami delsą savo vartotojams ir džiaugiamės, kad šios pačios investicijos dabar bus naudingos ir kūrėjų bendruomenei.

Paieškos API delsa

(užklausos inicijuotos iš AWS us-east-1)

„Search API“ užklausų iš AWS us-east-1 inicijuotų užklausų delsos percentiliai.

* Daugelis paieškos API tiekėjų kaip savo rezultatų pagrindą naudoja SERP duomenų rinkimą (angl. scraping). Norėdami įvertinti tokių metodų našumą, naudojame reprezentatyvią „Google“ SERP pagrįstą API, kurią siūlo „Tavily“.

Šis greičio pranašumas nesiekiamas kokybės sąskaita. „Perplexity Search API“ užtikrina naujausio lygio našumą tiek vieno žingsnio paieškos, tiek giluminių tyrimų nustatymuose. Kiekviename išbandytame teste „Perplexity“ pirmauja teikdama aukštos kokybės rezultatus, galinčius maitinti įvairaus sudėtingumo dirbtinio intelekto darbo eigas. Atstumas tarp „Perplexity“ ir geriausios alternatyvos ypač ryškus „SimpleQA“ ir „HLE“ testuose, o tai rodo, kad šie rezultatai yra tvirti visame užduočių sudėtingumo spektre.

Padidinti

Kaip ir delsos atveju, mūsų lyderystė paieškos kokybės srityje kyla iš mūsų lyderystės kuriant puikius, didelio srauto dirbtinio intelekto produktus. Mūsų milijonai vartotojų naudoja „Perplexity“ savo smalsumui patenkinti bet kuria įsivaizduojama tema, o gaunami kokybės ir svarbos signalai leidžia mūsų paieškos modeliams tobulėti su kiekviena praėjusia valanda.

Paieškos API kokybės testai

„Search API“ kokybės įverčiai SimpleQA, FRAMES, BrowseComp ir HLE.

Esame dar ankstyvojoje dirbtinio intelekto variklių paieškos eros stadijoje, ir matavimo menas bei mokslas neabejotinai tobulės. Kviečiame bendruomenę prisidėti kuriant griežtus ir kūrybiškus metodus paieškos variklių vertinimui dirbtinio intelekto agentų amžiuje.

Kitas dirbtinio intelekto skyriaus pamatas

Agentinių sistemų ir išmaniųjų asistentų ateitis priklausys nuo turtingų programinių sąsajų į pasaulio kolektyvines žinias prieinamumo. Šių dienų senstelėję paieškos varikliai pasiekė naudojimo sotumą maždaug ties 10¹⁰ užklausų per dieną, ir šis skaičius tikriausiai pasiekė piką. Kitos kartos paieškos ir gavimo sistemos aptarnaus keliomis eilėmis didesnį užklausų skaičių, nes vis didėjanti dirbtinio intelekto agentų visata jomis remiasi tikslios realaus laiko informacijos.

Mūsų pastangos iki šiol mus pozicionavo kaip greičiausią, našiausią paieškos variklį, pasiekiamą per API. Tačiau reikės dar ambicingesnių inovacijų, kad galėtume paskatinti kitą dirbtinio intelekto skyrių. Kaip efektyviai padidinti šių sistemų mastelį augančios paklausos akivaizdoje? Kaip šios paieškos sistemos gali būti optimizuotos atsižvelgiant į naujus konteksto konstravimo ir po-mokymo metodus? Ir kaip orientuotis nuolatiniame įtempime tarp išsamumo, naujumo ir delsos? Tai atviri klausimai, kuriuos „Perplexity“, su mūsų produkto pėdsaku, mastu ir techniniu talentu, yra unikaliai pasirengusi spręsti.

Citata

@online{perplexity2025ArchitectingAndEvaluatingAnAiFirstSearchApi,
  author = {{Perplexity} and Aleksandr Bogutskii and Aleksandr Nikolenko and Aleksei Bykov and Alexander Pecheny and Alexandr Yarats and Arsenii Shevchenko and Denis Bykov and Dmitry Pervukhin and Ismail Gadzhiev and James Liounis and Kevin Hu and Kirill Priemko and Maksim Gaiduk and Maksim Morozov and Marko Kevac and Michael Liang and Mikhail Galanin and Nandor Licker and Nataliya Pevgova and Nikita Kireev and Nikolai Tretiak and Paul Schofield and Saif Ali Raja and Saleh Alghusson and Sebastian Sepulveda and Sergei Miller and Svyatoslav Feldsherov and Vitalii Polshkov and Vladimir Zaytsev and Denis Yarats},
  title = {{Architecting and evaluating an AI-first Search API}},
  date = {2025-09-25},
  url = {https://www.perplexity.ai/hub/blog/architecting-and-evaluating-an-ai-first-search-api}
}