Search API: Bättre extrahering, dynamiska jämförelsetester

Kvaliteten på utdragen i vår Search API har optimerats utifrån två dimensioner: relevans och storlek.

I september publicerade vi en teknisk översikt av arkitekturen för Perplexity Search API och släppte search_evals, vårt utvärderingsramverk med öppen källkod för att jämföra sök-API:er i agentiska arbetsflöden. Sedan dess har den största satsningen legat på utdragskvalitet, optimerad längs två dimensioner: relevans och storlek. Att returnera rätt innehåll i rätt mängd avgör direkt svarsnoggrannheten och tokeneffektiviteten längre fram. Arbetet för att nå dit innebar att bygga nya system för extrahering, märkning på spannnivå och utvärdering, framför allt en pipeline för spannmärkning som identifierar vilka segment i ett källdokument som svarar mot en viss sökfråga.

Utvärdering av utdrag på spannnivå

För att förbättra utdragen systematiskt har vi utvecklat ett nytt utvärderingssystem. För en given sökfråga och ett givet dokument identifierar och märker systemet ut spann i dokumentet utifrån deras relation till sökfrågan: "vitala" spann som måste ingå i utdraget, olika klasser av "irrelevanta" spann som bör uteslutas, dubbletter och andra kategorier. Denna märkning på spannnivå gör att vi kan utvärdera utdragskvaliteten med en precision som tidigare inte var möjlig, och mäta både det som togs med på rätt grunder och det som uteslöts på rätt grunder.

I praktiken gör dessa förbättringar att vi kan generera mindre utdrag som är mer relevanta för sökfrågan. Vår självförbättrande pipeline för innehållsförståelse hanterar nu ett bredare spektrum av strukturerade dataformat, inklusive tabeller, kapslade listor och dynamiskt renderade innehåll som tidigare regelverk misslyckades med att tolka tillförlitligt.

Dessa förbättringar växte fram ur våra egna produktionssystem. När vår interna forskning drev på relevansen och storleken på utdragen visade interna utvärderingar att mindre innehållsbudgetar faktiskt gav mer exakta resultat efter en rad kvalitetsförbättringar. Vi gjorde vissa ändringar i våra standardkonfigurationer för att återspegla våra slutsatser, vilket minskar svarsnyttolastens storlek och latens samtidigt som det levererar mer användbart innehåll per resultat. För utvecklare innebär mindre och mer relevanta utdrag direkt lägre tokenkostnader och bättre kontexthantering för underliggande språkmodeller (LLM:er).

SEAL: jämförelsetest av tidsberoende sökning

SEAL-riktmärket testar om ett söksystem kan besvara frågor vars korrekta svar förändras över tid. För att svara tillförlitligt krävs färskhet i realtidsindexet, smartare utdragsgenerering från olika kontinuerligt uppdaterade datakällor samt tolkningsmetoder som kan identifiera det aktuella värdet i stället för ett historiskt.

När vi körde search_evals mot SEAL-releasen den 22 februari med Claude Sonnet 4.5 ökade Perplexity-poängen medan andra leverantörer sjönk på SEAL-Hard:

Vi har utökat vårt search_evals-ramverk till att omfatta SEAL vid sidan av de jämförelsetester som presenterades i vårt inlägg från september. Uppdaterade resultat och metoder finns tillgängliga i det uppdaterade arkivet på GitHub.

Stöd för flera sökfrågor

API:et stöder nu upp till 5 sökfrågor i en enda begäran. Resultaten returneras grupperade per sökfråga i samma ordning som de skickades in. Detta minskar antalet anrop för applikationer som behöver göra relaterade sökningar parallellt, till exempel agenter som bryter ned en komplex fråga i flera underordnade sökande uppgifter.

Utökad filtrering

Utöver domänfiltrering (tillåten- och nekat-lista, upp till 20 domäner) och tidsbaserad filtrering stöder API:et nu språkfiltrering med ISO 639-1-kod och regional sökning med ISO-landskod. Dessa kan kombineras för att avgränsa resultat exakt, till exempel genom att begränsa till engelskspråkiga resultat från tyska domäner.

SDK och tillgänglighet

The Python SDK (pip install perplexityai) erbjuder nu inbyggt stöd för Search API vid sidan av Agent API och Sonar API.

Fullständig dokumentation finns på docs.perplexity.ai