Search API: Jobb kinyerés, dinamikus benchmarkok

A Search API kivonatainak minőségét két dimenzió mentén optimalizáltuk: a relevanciák és a méret.

Septemberben technikai áttekintést tettünk közzé a Perplexity Search API architektúrájáról, és kiadtuk a search_evals nevű, nyílt forráskódú értékelési keretrendszerünket a keresési API-k ügynökalapú munkafolyamatokban történő teljesítményméréséhez. Azóta a legjelentősebb befektetést a kivonatok minőségébe fektettük, amelyeket két dimenzió mentén optimalizáltunk: a relevanciák és a méret. A megfelelő mennyiségű és tartalmú adatok visszaadása közvetlenül meghatározza a lefelé irányuló válaszok pontosságát és a tokenek hatékonyságát. Ehhez új rendszereket kellett építenünk a kinyeréshez, a szakaszszintű címkézéshez és az értékeléshez, legfontosabbként pedig egy olyan szakaszcímkézési folyamatot, amely azonosítja a forrásdokumentum azon részeit, amelyek relevánsak egy adott lekérdezés szempontjából.

Kivonatok értékelése szakaszszinten

A kivonatok szisztematikus javítása érdekében új értékelési rendszert fejlesztettünk ki. Egy adott lekérdezés és dokumentum esetén a rendszer azonosítja és címkézi a dokumentumon belüli szakaszokat a lekérdezéshez való viszonyuk alapján: „létfontosságú” szakaszok, amelyeket szerepeltetni kell a kivonatban, a „lényegtelen” szakaszok különböző kategóriái, amelyeket ki kell zárni, duplikátumok és egyéb kategóriák. Ez a szakaszszintű címkézés lehetővé olyan szintű pontossággal teszi a kivonatok minőségének értékelését, amely korábban nem volt lehetséges, és méri mindazt, ami helyesen bekerült, mind pedig azt, ami helyesen lett kihagyva.

A gyakorlatban ezek a fejlesztések lehetővé teszik számunkra, hogy kisebb, a lekérdezéshez jobban illeszkedő kivonatokat hozzunk létre. Önfejlesztő tartalomértelmezési folyamatunk mostantól a strukturált adatformátumok szélesebb körét támogatja, beleértve a táblázatokat, egymásba ágyazott listákat és a dinamikusan megjelenített tartalmakat is, amelyeket a korábbi szabálykészletek nem tudtak megbízhatóan elemezni.

Ezek a fejlesztések a saját éles rendszereinkből származnak. Ahogy a belső kutatásunk előmozdította a kivonatok relevanciáját és méretezését, a belső értékelések azt mutatták, hogy a kisebb tartalomkeretek valójában pontosabb eredményeket hoztak egy sor minőségjavítás után. Néhány módosítást hajtottunk végre az alapértelmezett beállításainkon, hogy tükrözzék megállapításainkat, csökkentve a válasz hasznos adatainak méretét és a késleltetést, miközben eredményenként több hasznos tartalmat biztosítunk. A fejlesztők számára a kisebb, relevánsabb kivonatok közvetlenül alacsonyabb tokenköltségeket és jobb kontextuskezelést jelentenek a lefelé irányuló nagy nyelvi modellek (LLM-ek) számára.

SEAL: időérzékeny lekérdezés teljesítménymérése

A SEAL benchmark azt vizsgálja, hogy egy lekérdezési rendszer képes-e megválaszolni olyan kérdéseket, amelyek helyes válasza idővel változik. A megbízható válaszadáshoz valós idejű indexfrissességre, okosabb kivonatkinyerésre van szükség a folyamatosan frissülő adatforrásokból, valamint olyan elemzésre, amely az aktuális értéket tudja azonosítani a történelmi érték helyett.

Amikor a search_evals keretrendszert futtattuk a február 22-i SEAL kiadáson a Claude Sonnet 4.5 használatával, a Perplexity pontszámai növekedtek, míg más szolgáltatóké csökkentek a SEAL-Hard teszten:

Kiterjesztettük a search_evals keretrendszerünket, hogy a szeptemberi bejegyzésünkben szereplő benchmarkok mellett a SEAL-t is tartalmazza. A frissített eredmények és a módszertan a GitHubon található frissített tárolóban érhetők el.

Többszörös lekérdezés támogatása

Az API mostantól legfeljebb 5 lekérdezést támogat egyetlen kérésben. Az eredmények lekérdezésenként csoportosítva, a beküldésük sorrendjében érkeznek vissza. Ez csökkenti a hálózati fordulók számát azon alkalmazások esetében, amelyeknek párhuzamosan kell kapcsolódó kereséseket indítaniuk, mint például azoknak az ügynököknek, amelyek egy összetett kérdést több lekérdezési részfeladatra bontanak.

Bővített szűrés

A tartományszűrésen (engedélyezési és letiltási lista, legfeljebb 20 tartomány) és az időszerűségi szűrésen túl az API mostantól támogatja az ISO 639-1 kód szerinti nyelvi szűrést és az ISO országkód szerinti regionális keresést is. Ezek kombinálhatók az eredmények pontos korlátozására, például a németországi tartományokból származó, angol nyelvű eredményekre való szűkítéshez.

SDK és elérhetőség

A Python SDK (pip install perplexityai) mostantól natív támogatást nyújt a Keresési API-hoz (Search API) az Ügynök API (Agent API) és a Sonar API mellett.

A teljes dokumentáció a docs.perplexity.ai címen érhető el