AI-első keresési API tervezése és értékelése

A skálázható, AI-központú keresési API építése egyedi kutatási kihívásokat tartogat az információkeresés, a mesterséges intelligencia és a rendszertervezés metszéspontján. Ellentétben a korlátozott adatokon alapuló hagyományos szolgáltatásokkal, egy keresési API-nak folyamatosan milliárdnyi dokumentumot kell indexelnie, meg kell értenie a lekérdezési szándékot a különböző nyelveken és tartományokon keresztül, valamint ezredmásodperceken belül releváns találatokat kell nyújtania. Az MI-ügynökök világában a keresési API-nak gondosan össze kell válogatnia a fejlesztők modelljei számára biztosított kontextust is, hogy azok optimálisan működjenek, és a lehető legpontosabb információkat építsék be. A hatékony kontextustervezés megköveteli, hogy az API ne csak a dokumentumszintű relevanciát rögzítse, hanem a dokumentumok egyes részeit és egységeit is önálló, első osztályú egységként kezelje.

Ebben a cikkben bemutatjuk a Perplexity Search API tervezését és értékelését. Először a napi 200 millió lekérdezést feldolgozó éles keresési infrastruktúránk mögött álló architektúrát és kulcsfontosságú technikai döntéseket tárgyaljuk. Architektúránk ötvözi a hibrid visszakeresési mechanizmusokat, a többlépcsős rangsorolási folyamatokat, az elosztott indexelést és a dinamikus elemzést egy önfejlesztő tartalomértelmező modul segítségével.

Ezt követően ismertetjük a keresési API teljesítményének empirikus értékelésére szolgáló megközelítésünket egy újonnan nyílt forráskódú értékelési keretrendszeren keresztül. A meglévő kereskedelmi API-k mellett végzett átfogó teljesítményértékelés révén csúcsteljesítményt mutatunk be mind a minőség, mind a késleltetés terén. A Perplexity Search API a mai naptól kezdve világszerte elérhető a fejlesztők számára.

[Keresd meg a search_evals projektet a GitHubon]

Az AI-modellekre optimalizált keresőrendszer építése

Alapításunk óta tisztában voltunk azzal, hogy a robusztus keresési képességek elengedhetetlenek lesznek a kategóriateremtő MI-termékeink piacra dobásához. Eredetileg reméltük, hogy ezek a képességek már léteznek nyilvánosan elérhető formában. Kísérleteztük a 2022 végén elérhető keresési API-k portfóliójával, és a Perplexity válaszadási motorjának legelső verziója valójában tartalmazott is néhány ilyen megoldást. Konkrétan elemeztük a felhasználói lekérdezéseket, kérelmeket fogalmaztunk meg és küldtünk ezeknek az API-kknak, majd az eredményeket összegyűjtöttük kontextusként a lefelé irányuló generálási folyamatunk számára.

Ahogy azonban a felhasználók a Perplexity felé özönlöttek, hamar rájöttünk, hogy ezek az API-k nem fognak a növekedésünkkel együtt skálázódni. A tapasztalt árak túlzóak voltak, az egyik vezető API-szolgáltató ezer lekérdezésként 200 dollárt számított fel. Ennél is végzetesebb however, hogy ezeket a régi típusú API-kat egyszerűen nem az élvonalbeli MI-rendszerek által bevezetett új visszakeresési paradigmákra tervezték.

Nagyítás

Kezdésnek ezen örökölt API-k kérés- és válaszformátumait olyan világra tervezték, ahol a keresési eredmények kizárólagos fogyasztói az emberek voltak. Ennek eredményeként ezek az API-k a dokumentumszintű eredményeket részesítették előnyben, kizárva a dokumentumokon belüli egységek által feltárt finomabb információkat. Egy MI-modell sikere a megadott kontextus minőségén és tömörségén múlik, és saját szemünkkel láttuk, hogy a túl tágan értelmezett visszakeresés hogyan siklóthatja ki az MI-modelleket, függetlenül attól, hogy a visszakeresett dokumentumok egésze mennyire tűnik relevánsnak. A pontosság kényszerítése a pontatlan eredményekre korlátozott sikerrel járt.

Azt is észrevettük, hogy a régi típusú API-k vagy túl elavultak, vagy túl lassúak voltak. A függetlenül fejlesztett keresési API-k olyan indexekre támaszkodtak, amelyek hiányosak és túl ritkán frissültek. A webes leképezésen (scraping) alapuló API-k, mint például a Google Keresés különféle nem hivatalos SERP API-jai, átfogóbb index előnyeit élvezték, de elfogadhatatlanul magas késleltetést mutattak a harmadik féltől származó keresőmotor lekérdezéséből fakadó hatékonysatlanság miatt. A magas késleltetés alkalmatlanná tette az API-kat a felhasználói alkalmazásokhoz, míg az elavultság használhatatlanná tette az eredménysorozatot bármilyen pontos és megbízható MI-rendszer számára.

Végül azt tapasztaltuk, hogy az MI-ökoszisztéma kettévált a lexikális és a semantikus keresés között, és olyan rendszerek jöttek létre, amelyek túlságosan egyetlen modalitásra voltak optimalizálva a másik kárára. Megfigyeltük a vektormatricák terjedését, amelyek még az egyszerű logikai szűrőket sem tudták megfelelően támogatni. A hagyományos keresési háttérrendszerek sem jártak sokkal jobban, mivel kezdetleges támogatást nyújtottak az MI által megnyitott szemantikus rangsorolási és visszakeresési lehetőségekhez.

Amikor rájöttünk, hogy a Perplexity még jobbá tétele saját dedikált keresési infrastruktúra építését igényli, megfigyeléseinket három kulcsfontosságú kritériumba sűrítettük:

Teljesség, frissesség és sebesség: a keresési indexnek átfogónak, folyamatosan frissítettnek és valós idejű késleltetésre tervezettnek kell lennie.

Finomhangolt tartalomértelmezés: az MI-modell törékenysége és a korlátozott kontextusablakok megkövetelik, hogy a keresési eredmények a lehető legrészletesebb szinten legyenek bemutatva és rangsorolva.

Hibrid visszakeresés és rangsorolás: a visszakeresési és rangsorolási folyamatoknak egyaránt tartalmazniuk kell lexikális és szemantikus jeleket ahhoz, hogy az eredmények hasznosak legyenek az MI számára.

Nagyítás

Cserkészési (crawling) és indexelési infrastruktúra

A Perplexity léptékű működés olyan infrastruktúrát igényel, amely átfogóan képes feltérképezni a webet és reagálni annak folyamatos változásaira. Keresési indexünk több mint 200 milliárd egyedi URL-t követ, és további sok százmilliárd követésére van kapacitása.

Annak biztosítása, hogy indexünk az internet elegendően átfogó részét fedje le, és hogy minden dokumentum a legfrissebb állapotot tükrözze, nehéz feladat. A teljesség és a frissesség között belső feszültség feszül: egy rögzített indexelési keretösszeg esetén a meglévő oldalak frissítési műveleteinek versenyezniük kell az új, még nem látogatott oldalak indexelési műveleteivel. Ezt a feszültséget a skálázás (amely az indexelési keret növelésével lazítja az optimalizációs korlátot) és az MI-vezérelt priorizálás kombinációjával egyensúlyozzuk ki (amely biztosítja, hogy minden indexelési művelet a lehető legnagyobb értékű legyen az index egészére nézve).

Exabájt léptékű indexet és webléptékű cserkésző apparátust építettünk, amely vízszintesen skálázódik a mérettel és a lekérdezési volumennel egyaránt. A Perplexity cserkésző és indexelő flottája tízezernél is több CPU-t és több száz terabájt RAM-ot foglal magában, jelentős tartalékkal a további skálázáshoz. Ezt a számítási infrastruktúrát a hideg és meleg tárolás egyensúlyával párosítjuk. Tanult modelleket és finomhangolt heurisztikákat egyaránt használunk annak meghatározására, hogy mely dokumentumokat érdemes melegen tartani, prioritásként kezelve a mérvadó tartományokból származó dokumentumokat, a kevésbé lefedett témákat érintő dokumentumokat, valamint az indexünk gazdagítására alkalmas egyéb kategóriákat.

Ez az infrastruktúra képessé teszi a Perplexityt másodpercenkénti tízezres nagyságrendű indexelési művelet feldolgozására. Ám még ezzel a viszonylag nagyvonalú kerettel is az internet léptéke túl hatalmas ahhoz, hogy minden egyes URL-t gyakori és ismétlődő jelleggel indexelni lehessen. Itt lép képbe a gépi tanulás (ML). Egy MI-modellt tanítunk be annak előrejelzésére, hogy egy adott jelölt URL-t indexelni kell-e. A betanítási célkitűzést úgy alakítjuk ki, hogy az indexelési döntésünket az adott URL fontosságához és várható frissítési gyakoriságához kalibráljuk. Az MI-re támaszkodunk abban is, hogy pontosan megmondja, mikor kell időzíteni az indexelési műveletet. A rutin szerinti publikálási és frissítési ütemű oldalak esetében ez lehetővé teszi számunkra, hogy a műveleteket arra az időpontra halasszuk, amikor azok valószínűleg a leghasznosabbak lesznek. Ezen MI-modellek folyamatos finomításával olyan indexet tudunk fenntartani, amely teljesíti a teljességre és frissességre vonatkozó elvárásokat.

Bár cserkészési infrastruktúránk könnyen skálázódik vízszintesen, tisztában vagyunk azzal, hogy a webhelykezelők eltérő technikai korlátokkal szembesülnek. Ügyelünk arra, hogy fenntartható és kezelhető kéréssebességet tartsunk fenn bármely adott domain felé. A PerplexityBot, a keresési cserkészőnk, betartja a robots.txt fájlokban meghatározott explicit korlátokat, vagy a domainspecifikus korlátok hiányában a kéréssebességre vonatkozó iparági szabványokat. Cserkészési viselkedésünket akkor is módosítjuk, ha webhelyelérhetetlenséget észlelünk. Elosztott rendszerünket úgy terveztük, hogy ezeket a korlátokat még tízezernél is több párhuzamos művelet esetén érvényesítse.

Önfejlesztő tartalomértelmezés internetes léptékben

Még a bolygó egyik legnagyobb és legfrissebb keresési indexével is minden egyes lekérdezés találati minősége azon múlik, hogy a rendszerünk mennyire érti meg az egyes dokumentumok tartalmát. Itt alapvető kihívással szembesülünk: a web egy rendetlen hely. A sablonos elemzési szabályok egyetlen készlete sem képes kezelni az egész interneten található elrendezések, szerruktúrák és stílusok végtelen sokféleségét.

Ezt a kihívást úgy oldottuk meg, hogy egy olyan tartalomértelmező modult fejlesztettünk ki, amely dinamikus szabványsorok használatával elemzi a webhelyeket és nyeri ki a szemantikailag jelentős tartalmat. A jól strukturált, listás vagy táblázatos formájú adatokban gazdag webhelyek profitálhatnak a formálisabb elemzési és kinyerési szabályokból, míg egy másik, elsősorban szabad formátumú felhasználói tartalommal rendelkező webhely lazább szabályrendszert igényelhet. Mivel a web rövid időtávon többnyire statikus, azt tapasztaljuk, hogy egy adott szabály élettartama viszonylag hosszú. Ahogy azonban a webhelyek idővel fejlődnek, és ahogy többet tanulunk az információkinyerés legjobb módjairól, a szabályrendszereink is folyamatos karbantartást igényelnek.

A dinamikus adaptáció elősegítéséhez (természetesen) az MI-hez fordulunk. A Perplexity léptékében a felhasználói lekérdezések millióinak kiszolgálása során hihetetlenül gazdag keresztmetszetét figyeljük meg a webnek. Ez képezi az alapját egy iteratív önfejlesztő huroknak. Megfigyeljük aktuális szabályrendszereink elemzési viselkedését és kinyerési kimeneteit lekérdezési univerzumunkban. Ezután fejlett nyelvi modelleket (LLM) használunk a teljesítmény értékelésére két fő dimenzió mentén:

Teljesség: az indexünknek a lehető legtöbb szemantikailag jelentős tartalmat kell befogadnia, miközben kerülnie kell a tájékoztatásra alkalmatlan vagy értelmetlen elemek téves kinyerését.

Minőség: indexünk olyan tartalomra támaszkodik, amely mind tartalmában, mind formájában magas minőségű. Az információkat úgy kell rögzíteni, hogy megmaradjon az eredeti tartalmi szerkezet és elrendezés.

Megjegyzendő, hogy a teljesség és a minőség újabb belső feszültséget rejt: a minőség kézi optimalizálása lehetséges, de az ebből eredő elemzési szabályok nem feltétlenül ragadják meg a kritikus tartalmakat. Hasonlóképpen, kézzel kódolhatnánk megengedő szabályokat, amelyek minimális szűrést alkalmaznak a nyers tartalomra, ami javíthatja a teljességet, de a minőség rovására. Ezért fordulunk az MI-vezérelt önfejlesztéshez, hogy úgy fejlesszük a szabályrendszerünket, amely tartomány-adaptív módon mindkettőt egyszerre képes optimalizálni.

Konkrétan, az elemzési teljesítmény minden egyes LLM-vezérelt értékelése után a rendszerünk javasolt szabályrendszer-változtatások sorozatát fogalmazza meg a legjelentősebb hibakategóriák kezelésére. Ezek a szabályrendszerek további validáláson esnek át, ami után az új verziót üzembe helyezzük az indexelőnkön. Mivel az elemzési és kinyerési logika fejlesztései csak a jövőbeli indexelési műveletek javára válhatnak, az MI-optimalizált reindexelésbe történő beruházásaink különösen fontosak: a nagy forgalmú dokumentumok folyamatos frissítése e logika legújabb verziójával szoros önfejlesztő hurkot biztosít.

Ezek a szabályok nemcsak az alapelemzési teljesítmény szempontjából fontosak, hanem a dokumentumokon belüli egységekre való szegmentálás szempontjából is. Az élvonalbeli LLM-ek esetében a kontextus minden egyes tokenje értékes. Korábbi munkák széles köre dokumentálta, hogy az LLM-ek teljesítménye hogyan romlik a kontextus méretének növekedésével és a kontextus irreleváns információkkal való szennyezésével. A jól strukturált, átfogó elemzés lehetővé teszi számunkra, hogy a dokumentumokat önálló egységekre bontsuk, amelyek mindegyike lekérdezéskor egyenként visszakereshető és rangsorolható.

Visszakeresési és rangsorolási folyamat

A modern keresés megköveteli a teljesség és a relevancia biztosítását is a szűk késleltetési kereteken belül. A Perplexity visszakeresési és rangsorolási folyamata ezt egy többlépcsős architektúrán keresztül éri el, amely egyre kifinomultabb modulok sorozatával fokozatosan finomítja az eredményeket. A potenciális szűk keresztmetszeteket a lehetséges legnagyobb mértékben történő vízszintes skálázással oldjuk meg.

A folyamat az indexünkből való visszakereséssel kezdődik. Nem kényszerítünk választást a lexikális és a szemantikus visszakeresés között. Ehelyett mindkét modalitáson keresztül lekérdezzük a keresési indexet, és az eredményeket hibrid jelöltcsaládba egyesítjük. Ebben a fázisban a teljesség élvez prioritást a pontossággal szemben – a folyamat későbbi szakaszai optimalizálnak a pontosságra.

A folyamat az előszűrési szakaszokkal folytatódik, amelyek során alapszintű heurisztikákat és első körös szűrőket alkalmazunk, hogy eltávolítsuk a jelöltcsaládos halmazból a nyilvánvalóan nem válaszoló vagy elavult tartalmakat.

Ezt követően a haladó rangsorolás több szakaszát alkalmazzuk. A korábbi szakaszok a sebességre optimalizált lexikális és beágyazásalapú pontozókra támaszkodnak. Ahogy a jelöltek halmaza fokozatosan lecsökken, erősebb kereszt-kódoló (cross-encoder) újrarangsoroló modelleket használunk az eredménysorozat végső kialakításához. A következtetési teljesítménybe fektetett számos beruházásunknak köszönhetően képesek vagyunk a legmodernebb modellarchitektúrákat használni ezekhez a későbbi szakaszokhoz, miközben alacsonyan tartjuk a teljes rangsorolási késleltetést.

A folyamat során dokumentum- és rész-dokumentum szinten egyaránt visszakeressük és pontozzuk az eredményeket. Ahogy fentebb említettük, az MI gondos kontextustervezést igényel. Folyamatunkat úgy terveztük, hogy a lehető legkisebb atomi egységeket hozza a modell elé, hogy a lefelé irányuló fogyasztók beépíthessék ezeket a pontos egységeket anélkül, hogy irreleváns kontextust húznának be a forrásdokumentumok más részeiből.

A folyamat minden egyes szakaszában a magas minőség biztosítása kizárólag a Perplexity termékportfóliójával való közös tervezés révén lehetséges. A rangsorolási réteg minden részletét úgy tervezték, hogy kihasználja a napi óránként kiszolgált felhasználói kérések milliói által előállított gazdag jelet. E jel nagy része automatizált, és minden generált Perplexity-válasz empirikus adatpontot biztosít a keresési minőségről az éles ügynöki munkafolyamatban. Az MI-vezérelt értékeléseket élő emberi visszajelzéssel kombináljuk, hogy nagymértékben gazdagítsuk a beágyazási és rangsorolási modelljeink betanítási adatait túlóra, amit bármilyen kézzel összeállított adatkészlet kínálni tudna.

Ez a szinergia a keresés és a termék között egyedülálló a Perplexitynél. A hagyományos keresőmotorok a kék hivatkozású telemetria által biztosított nyers jelekre korlátozódnak. Az újabb keresési ajánlatok megkísérelték néhány ilyen MI-központú koncepció implementálását, de hiányoznak belőlük a valós környezetek, amelyek érvényesíteni tudnák a keresési minőséget, és biztosítani tudnák a gyors fejlesztési hurkokhoz szükséges jelgazdagságot. Szerencsések vagyunk, hogy rendelkezünk a hiányzó összetevővel: a keresési minőség élő tesztmezőjével, amelyet az élvonalbeli LLM-ek hajtanak, és amelyet világszerte milliomnyi kíváncsi felhasználó tesztel folyamatosan élesben.

A minőség és a teljesítmény új határvonalának megállapítása

Miután megépítettük a Perplexity Search API-t és az SDK-t, hogy keresési infrastruktúránkat elérhetővé tegyük a világ fejlesztői számára, meg akartuk érteni, hogy a különböző kereskedelmi API-ajánlatok hogyan teljesítenek a valós világ MI-használati eseteiben. Vállalattá vált az MI-modellek értékelése önmagában, de szükségünk volt e minta egy csavarására: a keresési API-k minőségének értékelésére, amikor azokat MI-modellek hívják meg.

Először a nyílt forráskódú ökoszisztémához fordultunk, hogy megértsük az előzményeket. A szigorú értékeléshez sok kulcsfontosságú összetevőt találtunk, de egyetlen keretrendszert sem, amely ezeket az összetevőket egy beépülő és azonnal használható teljesítményértékelési megoldásba integrálta volna. Ezért elhatároztuk, hogy olyan értékelési keretrendszert fejlesztünk ki, amelyet nemcsak a Perplexity, hanem bármely kutató vagy fejlesztő használhat, aki keresési API-kat kíván teljesítményértékelni.

Ezt az értékelési keretrendszert használva szigorúan teljesítményértékeltük a Perplexity Search API-t más ajánlatok mellett. A keresési teljesítmény optimalizálása összetett feladat, a minőség és a sebesség közötti számos árnyalt kompromisszummal. A fejlesztők örömére azt találtuk, hogy a Perplexity Search API új csúcsteljesítményt állít fel mind a minőség, mind a késleltetés terén. A fejlesztőknek többé nem kell választaniuk a villámgyors alkalmazások építése és a kiváló minőségű eredmények biztosítása között: a Perplexityvel mindkettőt megkaphatják.

Nagyítás

Megbízható értékelések tervezése ügynöki keresési munkafolyamatokhoz

Az értékelési keretrendszerünk három irányelvének meghatározásával kezdtük:

Összetettségi spektrum: az értékelési keretrendszernek mérnie kell a teljesítményt az egyszerű és az összetett ügynöki MI-használati esetekben egyaránt.

Semlegesség: az értékelési keretrendszernek egyenlő feltételek mellett kell értékelnie az összes API-t.

Egyszerűség: jóllehet bizonyos használati esetek összetettek lehetnek, magának a keretrendszernek a lehető legegyszerűbbnek kell lennie, hogy mások is megérthessék, reprodukálhassák az eredményeket, és minimális fáradsággal kiterjeszthessék a keretrendszert.

Könnyű súlyú értékelési keretrendszerünk, a search_evals, egyszerű moduláris felépítéssel éri el ezeket a célokat. Két MI-ügynök keretrendszert fejlesztettünk ki a klasszikus egyszeri keresési használati esetek és a haladó ügynöki munkafolyamatok (amelyeket a fogyasztói piacon széles körben elérhető különféle „mélyreható kutatás” termékek példáznak) rögzítésére. Mindkét keretrendszert egyszerű módon implementáltuk, ami kevés teret hagy a rejtett előnyöknek.

Értékeléseink vezérléséhez négy teljesítménymutatót (benchmark) fogadtunk el: a SimpleQA-t és a FRAMES-t az egylépéses kereséshez, valamint a BrowseComp-ot és a HLE-t a mélyreható kutatáshoz. Ezek a benchmarkok együtt jól elfogadott mércéket biztosítanak a tudásügynökök számára. A megállapított konvenciót követve az összes benchmarkot az eredeti munkában használt, felhívásalapú osztályozó módszertannal értékeljük. A pontos benchmark implementációk (ideértve az osztályozó logikát is) áttekinthetők a GitHub repónkben.

A keretrendszert a reprodukálhatóság és a bővíthetőség szem előtt tartásával terveztük. Mind a feladatszintű pontszámok, mind a mögöttes ügynöki kimenetek minden futtatáskor tárolásra kerülnek. További keretrendszerek, benchmarkok és keresési API-ajánlatok könnyen integrálhatók. A kutatók és fejlesztők elolvashatják a GitHub dokumentációját a keretrendszer az Ön pontos igényeihez igazított kiterjesztéséről.

Értékelési eredmények

Ezzel az értékelési keretrendszerrel felszerelkezve nekiláttunk felmérni a Search API-nk teljesítményét más API-ajánlatokhoz képest. Az összes tesztelt benchmarkon a Perplexity a leggyorsabb és a legmagasabb minőségű API a piacon.

Nagyítás

Azt találtuk, hogy az indexelésbe, a visszakeresésbe és a rangsorolási hatékonyságba fektetett, fent leírt beruházásaink bőségesen kifizetődtek. A Perplexity medián késleltetése 358 ms, ami több mint 150 ms-mal megelőzi a második leggyorsabb szolgáltatót. A 95. percentilis késleltetés kényelmesen 800 ms alatt marad. A mai élvonalbeli modellek hosszú TTFT (idő az első tokenig) metrikái mellett minden ezredmásodperc számít az élvezetes felhasználói élmény megteremtésében. Az elmúlt két évet a saját felhasználóink késleltetésének optimalizálásával töltöttük, és örömmel tölt el minket, hogy ugyanezek a beruházások most a fejlesztői közösség javát is szolgálják.

Keresési API késleltetése

(az AWS us-east-1 régiójából indított kérések)

A Search API késleltetési percentilisei az AWS us-east-1 régióból indított kérésekre.

* Számos keresési API-szolgáltató SERP leképezést használ az eredményei alapjaként. Az ilyen megközelítések teljesítményének rögzítéséhez a Tavily által kínált reprezentatív Google SERP-alapú API-t használjuk.

Ez a sebességelőny nem a minőség rovására megy. A Perplexity Search API csúcsteljesítményt nyújt mind az egylépéses keresés, mind a mélyreható kutatás beállításaiban. Minden egyes tesztelt benchmarkon a Perplexity vezeti a mezőnyt a kiváló minőségű eredmények biztosításában, amelyek képesek támogatni a különböző összetettségű MI-munkafolyamatokat. A Perplexity és a legjobb alternatíva közötti különbség különösen feltűnő a SimpleQA és a HLE esetében, ami azt jelzi, hogy ezek az eredmények robusztusak a feladatok összetettségi spektrumán.

Nagyítás

A késleltetéshez hasonlóan a keresési minőség terén elért vezető szerepünk is abból fakad, hogy élvezetes, nagy forgalmú MI-termékeket építünk. Felhasználóink milliói használják a Perplexityt, hogy minden elképzelhető témában kielégítsék kíváncsiságukat, és az ebből fakadó minőségi és relevanciajelek lehetővé teszik, hogy keresési modelljeink minden eltelő órával javuljanak.

Keresési API minőségi benchmarkjai

A Search API minőségi pontszámai a SimpleQA, FRAMES, BrowseComp és HLE benchmarkokon.

Az MI-alapú keresőmotorok még a kezdeti szakaszukban járnak, és a mérés művészete és tudománya kétségtelenül fejlődni fog. Arra ösztönözzük a közösséget, hogy járuljon hozzá szigorú és kreatív módszerek fejlesztésével a keresőmotorok értékelésére az MI-ügynökök korában.

Az MI következő fejezetének építőköve

Az ügynöki rendszerek és az intelligens asszisztensek jövője a világ kollektív tudásához való gazdag programozási interfészek elérhetőségén fog múlni. A mai régi típusú keresőmotorok használata elégedetté vált napi körülbelül 10¹⁰ lekérdezésnél, ami valószínűleg elérte a csúcspontját. A keresési és visszakeresési rendszerek következő generációja nagyságrenddel több kérést fog kiszolgálni, mivel az MI-ügynökök folyamatosan növekvő univerzuma támaszkodik rájuk a pontos valós idejű információkért.

Eddigi erőfeszítéseink a leggyorsabb, legteljesítményesebb API-n keresztül elérhető keresőmotor pozíciójába helyeztek minket. Ám még ambiciózusabb innovációra lesz szükség ahhoz, hogy tápláljuk az MI következő fejezetét. Hogyan skálázhatjuk hatékonyan ezeket a rendszereket az egyre növekvő kereslet ellenére? Hogyan optimalizálhatók ezek a keresési rendszerek a kontextustervezés és a betanítás utáni új megközelítések fényében? És hogyan navigálhatunk a teljesség, a frissesség és a késleltetés között fennálló, mindig jelen lévő feszültségben? Ezek olyan nyitott kérdések, amelyeknek a kezelésére a Perplexity a terméklábnyoma, léptéke és műszaki tehetsége kombinációjával egyedülálló módon alkalmas.

Idézet

@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}
}