AI 퍼스트 Search API 설계 및 평가
하이브리드 검색과 AI 모델을 위한 지능형 컨텍스트 선별을 사용하여 하루 2억 건의 쿼리를 처리하는 확장 가능한 Search API 구축
확장 가능하고 AI 지향적인 Search API를 구축하는 것은 정보 검색, AI, 시스템 설계의 교차점에서 독특한 연구 과제를 제시합니다. 제한된 데이터로 운영되는 기존 서비스와 달리, Search API는 수십억 개의 문서를 지속적으로 색인화하고, 언어 및 도메인 전반에 걸쳐 쿼리 의도를 파악하며, 밀리초 단위로 관련 결과를 도출해야 합니다. AI 에이전트의 시대에, Search API는 개발자의 모델이 최적으로 작동하고 최대한 정확한 정보를 통합할 수 있도록 모델에 제공되는 컨텍스트를 신중하게 선별해야 합니다. 효과적인 컨텍스트 엔지니어링을 위해서는 API가 문서 수준의 관련성을 포착할 뿐만 아니라, 문서의 개별 섹션과 스팬(span)을 독립적인 일류 단위로 취급해야 합니다.
본 기사에서는 Perplexity Search API의 설계와 평가 결과를 제시합니다. 우선 매일 2억 건의 쿼리를 처리하는 당사의 프로덕션 검색 인프라를 뒷받침하는 아키텍처와 주요 기술적 결정 사항을 살펴봅니다. 당사의 아키텍처는 하이브리드 검색 메커니즘, 다단계 랭킹 파이프라인, 분산 색인화, 그리고 자가 개선 콘텐츠 이해 모듈을 통한 동적 파싱을 결합한 것입니다.
다음으로, 새롭게 오픈 소스로 공개된 평가 프레임워크를 통해 Search API 성능을 실증적으로 평가하는 접근 방식을 설명합니다. 기존 상용 API와 함께 종합적인 벤치마킹을 수행함으로써, 품질과 지연 시간 측면에서 최첨단 성능을 입증합니다. Perplexity Search API는 오늘부터 전 세계 개발자가 이용할 수 있습니다.
AI 모델에 최적화된 검색 시스템 구축
창립 초기부터 당사는 강력한 검색 기능이 당사가 제공하고자 하는 범주 정의적 AI 제품을 구현하는 데 필수적이라는 점을 이해하고 있었습니다. 당초 우리는 이러한 기능이 이미 공개적으로 이용 가능한 형태로 존재하기를 바랐습니다. 2022년 말 이용 가능한 검색 API 포트폴리오를 실험해 보았으며, Perplexity의 답변 엔진의 첫 번째 버전은 실제로 이러한 제품 일부를 통합했습니다. 구체적으로, 사용자의 쿼리를 분석하여 해당 API에 요청을 보내고, 결과를 수집하여 하위 생성 파이프라인을 위한 컨텍스트로 활용했습니다.
그러나 사용자가 Perplexity로 몰리면서, 이러한 API가 당사의 성장 속도에 맞춰 확장되지 못할 것임을 빠르게 깨달았습니다. 당사가 접한 가격은 터무니없이 높았으며, 한 선도적인 API 제공업체는 쿼리 1,000건당 200달러를 청구했습니다. 하지만 더 치명적인 것은, 이러한 레거시 API들이 프런티어 AI 시스템이 도입한 새로운 검색 패러다임에 맞춰 설계되지 않았다는 점이었습니다.
우선, 이러한 레거시 API의 요청 및 응답 형식은 인간이 검색 결과의 독점적 소비자인 세상을 위해 설계되었습니다. 결과적으로, 이러한 API들은 문서 수준의 결과에 우선순위를 두었고, 하위 문서 단위에서 드러나는 더 세밀한 정보는 제외되었습니다. AI 모델의 성공은 제공된 컨텍스트의 품질과 간결성에 달려 있으며, 검색된 문서 전체가 관련성이 있어 보이더라도 과도하게 광범위한 검색이 AI 모델을 어떻게 저해하는지 직접 확인했습니다. 부정확한 결과에 정밀함을 억지로 맞추려는 시도는 제한적인 성과만을 거두었습니다.
또한 당사는 레거시 API가 너무 진부하거나 너무 느리다는 점을 관찰했습니다. 독립적으로 개발된 검색 API는 불완전하고 업데이트 빈도가 너무 낮은 색인에 의존했습니다. Google 검색을 위한 다양한 비공식 SERP API와 같은 스크래핑 기반 API는 더 포괄적인 색인의 이점을 누렸지만, 타사 검색 엔진을 쿼리하는 데 내재된 비효율성으로 인해 수용할 수 없을 정도로 높은 지연 시간을 보였습니다. 높은 지연 시간은 API를 사용자 대면 애플리케이션에 부적합하게 만들었으며, 데이터의 진부함은 결과 세트를 정확하고 신뢰할 수 있는 AI 시스템에 사용할 수 없게 만들었습니다.
마지막으로, 당사는 AI 생태계가 어휘 검색과 의미론적 검색으로 양분되는 것을 관찰했으며, 한 가지 방식에만 과도하게 최적화된 시스템이 등장하는 것을 목격했습니다. 단순한 불리언 필터조차 제대로 지원하지 못하는 벡터 데이터베이스가 부상했습니다. 기존 검색 백엔드 역시 AI가 열어준 의미론적 랭킹 및 검색 기회에 대한 원시적인 지원만 제공할 뿐이었습니다.
Perplexity를 더욱 개선하려면 자체적인 전용 검색 인프라를 구축해야 함을 깨닫고, 관찰 결과를 세 가지 핵심 기준으로 정리했습니다:
완전성, 신선도, 그리고 속도: 검색 색인은 포괄적이어야 하며, 지속적으로 업데이트되고, 실시간 지연 시간에 맞춰 설계되어야 합니다.
세밀한 콘텐츠 이해: AI 모델의 불안정성과 제한된 컨텍스트 윈도우로 인해 검색 결과는 가능한 가장 세분화된 수준에서 제시되고 랭킹이 매겨져야 합니다.
하이브리드 검색 및 랭킹: 검색 및 랭킹 파이프라인 모두 AI가 활용할 수 있도록 어휘적 신호와 의미론적 신호를 모두 통합해야 합니다.
크롤링 및 색인화 인프라
Perplexity 규모로 운영하려면 웹을 포괄적으로 매핑하고 지속적인 진화에 대응할 수 있는 인프라가 필요합니다. 당사의 검색 색인은 2,000억 개 이상의 고유 URL을 추적하며, 수천억 개를 더 추적할 수 있는 용량을 갖추고 있습니다.
당사의 색인이 인터넷의 충분히 포괄적인 범위를 다루고 각 문서가 최신 상태를 반영하도록 보장하는 것은 어려운 위업입니다. 완전성과 신선도 사이에는 본질적인 긴장이 존재합니다. 고정된 색인화 예산 내에서 기존 페이지에 대한 새로 고침 작업은 방문하지 않은 새로운 페이지에 대한 색인화 작업과 경쟁해야 합니다. 당사는 확장(색인화 예산을 늘려 최적화 제약을 완화)과 ML 기반 우선순위 지정(각 색인화 작업이 전체 색인에 최대한 가치가 있도록 보장)을 결합하여 이러한 긴장의 균형을 맞춥니다.
당사는 규모와 쿼리 볼륨 모두에 수평적으로 확장되는 엑사바이트 규모의 색인 및 크롤링 장치를 구축했습니다. Perplexity의 크롤러 및 색인화 플릿은 총 수만 개의 CPU와 수백 테라바이트의 RAM으로 구성되어 있으며, 추가 확장을 위한 상당한 여유 공간을 확보하고 있습니다. 당사는 이 컴퓨팅 인프라를 콜드 스토리지와 웜 스토리지의 균형과 결합합니다. 학습된 모델과 조정된 휴리스틱을 모두 사용하여 어떤 문서를 핫(hot) 상태로 유지할지 결정하며, 권위 있는 도메인의 문서, 다루어지지 않은 주제 관련 문서, 그리고 당사 색인을 풍부하게 할 가능성이 매우 높은 기타 범주의 문서에 우선순위를 둡니다.
이 인프라를 통해 Perplexity는 초당 수만 개의 색인화 작업을 처리할 수 있습니다. 하지만 이렇게 비교적 넉넉한 예산으로도 인터넷 규모는 너무 방대하여 모든 단일 URL을 빈번하고 반복적으로 색인화하기에는 역부족입니다. 바로 이 지점에서 ML이 필요합니다. 당사는 특정 후보 URL을 색인화해야 할지 예측하는 ML 모델을 학습시킵니다. 학습 목표는 색인화 결정을 해당 URL의 중요성과 예상 업데이트 빈도 모두에 맞게 조정하도록 설계되었습니다. 또한 당사는 ML에 의존하여 색인화 작업 일정을 정확히 언제 잡을지 결정합니다. 일상적인 게시 및 새로 고침 주기를 가진 사이트의 경우, 이를 통해 작업이 가장 유용할 것으로 예상되는 시점까지 작업을 미룰 수 있습니다. 이러한 ML 모델의 지속적인 개선을 통해 완전성과 신선도 측면에서 기준을 충족하는 색인을 유지할 수 있습니다.
당사의 크롤링 인프라는 쉽게 수평적으로 확장되지만, 웹사이트 운영자가 서로 다른 기술적 제약에 직면해 있다는 점을 인지하고 있습니다. 당사는 특정 도메인에 대해 예측 가능하고 관리 가능한 요청 속도를 유지하기 위해 주의를 기울입니다. 당사의 검색 크롤러인 PerplexityBot은 robots.txt 파일에 명시된 제한 사항을 준수하거나, 도메인별 제한 사항이 없는 경우 요청 속도와 관련된 업계 표준 규범을 따릅니다. 또한 사이트 이용 불가 상태를 감지하면 크롤링 동작을 조정합니다. 당사의 분산 시스템은 수만 개의 동시 작업 전반에서도 이러한 제한을 강제하도록 설계되었습니다.
인터넷 규모에서의 자가 개선 콘텐츠 이해
지구상에서 가장 크고 최신인 검색 색인 중 하나를 보유하고 있더라도, 각 쿼리의 결과 품질은 당사 시스템이 각 문서의 콘텐츠를 얼마나 잘 이해하느냐에 달려 있습니다. 여기서 우리는 근본적인 도전에 직면합니다. 웹은 복잡한 공간입니다. 고정된 파싱 규칙 세트로는 인터넷 전체에서 발견되는 무한한 레이아웃, 구조, 스타일의 다양성을 처리할 수 없습니다.
당사는 동적 규칙 세트를 사용하여 웹사이트를 파싱하고 의미 있는 콘텐츠를 추출하는 콘텐츠 이해 모듈을 개발하여 이 문제를 해결했습니다. 목록이나 표 형식으로 구조화된 데이터가 많은 웹사이트는 공식적인 파싱 및 추출 규칙을 통해 이점을 얻을 수 있는 반면, 주로 자유 형식의 사용자 생성 콘텐츠를 특징으로 하는 다른 웹사이트는 더 느슨한 규칙 세트가 필요할 수 있습니다. 웹은 짧은 기간 동안 대부분 정적으로 유지되기 때문에, 특정 규칙의 수명은 비교적 긴 편입니다. 하지만 사이트가 시간이 지남에 따라 진화하고 정보를 추출하는 최선의 방법에 대해 더 많이 배우게 됨에 따라, 당사의 규칙 세트도 지속적인 관리가 필요합니다.
이러한 동적 적응을 촉진하기 위해 당사는 (물론) AI를 활용합니다. Perplexity 규모에서 당사는 매시간 수백만 명의 사용자 쿼리를 처리하는 과정에서 웹의 매우 풍부한 단면을 관찰합니다. 이것이 반복적인 자가 개선 루프의 토대를 형성합니다. 당사는 현재 규칙 세트의 파싱 동작과 추출된 출력을 전체 쿼리 유니버스에서 관찰합니다. 그런 다음 프런티어 LLM을 사용하여 두 가지 주요 차원에서 성능을 평가합니다:
완전성: 당사의 색인은 의미론적으로 의미 있는 콘텐츠를 최대한 많이 수신해야 하며, 정보가 없거나 터무니없는 내용을 잘못 추출하는 것을 피해야 합니다.
품질: 당사의 색인은 내용과 형식 모두에서 고품질인 콘텐츠에 의존합니다. 정보는 원래의 콘텐츠 구조와 레이아웃을 보존하는 방식으로 캡처되어야 합니다.
완전성과 품질은 또 다른 내재적 긴장을 제시한다는 점에 유의하십시오. 품질을 위해 수동으로 최적화하는 것은 가능하지만, 결과적인 파싱 규칙이 중요한 콘텐츠를 포착하지 못할 수 있습니다. 마찬가지로, 원시 콘텐츠에 최소한의 필터링을 적용하는 관대한 규칙을 수동으로 코딩할 수도 있는데, 이는 완전성을 향상시킬 수는 있지만 품질을 희생시킬 수 있습니다. 이것이 바로 당사가 AI 기반 자가 개선을 통해 도메인 적응 방식으로 완전성과 품질을 동시에 최적화할 수 있는 방향으로 규칙 세트를 발전시키는 이유입니다.
구체적으로, LLM 기반 파싱 성능 평가가 끝날 때마다 당사 시스템은 가장 중요한 오류 클래스를 해결하기 위한 제안된 규칙 세트 변경 사항 세트를 공식화합니다. 이러한 규칙 세트는 추가 검증을 거친 후, 새 버전을 인덱서에 배포합니다. 파싱 및 추출 로직의 개선은 향후 색인화 작업에만 이점을 줄 수 있으므로, ML 최적화 재색인화에 대한 당사의 투자는 특히 중요합니다. 최신 버전의 로직을 사용하여 트래픽이 많은 문서를 지속적으로 새로 고침함으로써 긴밀한 자가 개선 루프를 보장합니다.
이러한 규칙은 기본 파싱 성능뿐만 아니라 하위 문서 단위로의 세분화에도 중요합니다. 프런티어 LLM의 경우, 컨텍스트의 각 토큰은 소중합니다. 방대한 양의 선행 연구들이 컨텍스트 크기가 증가하고 관련 없는 정보로 컨텍스트가 오염됨에 따라 LLM 성능이 어떻게 저하되는지 문서화했습니다. 잘 구조화되고 포괄적인 파싱을 통해 문서를 자립적인 스팬(span)으로 분해할 수 있으며, 각 스팬은 쿼리 시점에 개별적으로 검색 및 랭킹이 가능합니다.
검색 및 랭킹 파이프라인
현대적인 검색은 엄격한 지연 시간 예산 내에서 완전성과 관련성을 모두 보장해야 합니다. Perplexity의 검색 및 랭킹 파이프라인은 일련의 점점 더 정교해지는 모듈을 통해 결과를 점진적으로 개선하는 다단계 아키텍처를 통해 이를 달성합니다. 당사는 병목 현상이 발생할 수 있는 부분을 가능한 한 최대한 수평적으로 확장하여 해결합니다.
파이프라인은 색인에서 검색하는 것으로 시작됩니다. 당사는 어휘 검색과 의미론적 검색 중 하나를 선택하도록 강요하지 않습니다. 오히려 당사는 두 방식을 모두 통해 검색 색인을 쿼리하고 결과를 하이브리드 후보 세트로 병합합니다. 이 단계에서는 정밀도보다 포괄성이 우선이며, 파이프라인의 후속 단계에서 정밀도를 최적화할 것입니다.
파이프라인은 사전 필터링 단계로 이어지며, 여기서 기본 휴리스틱과 1차 필터를 적용하여 명백히 응답하지 않거나 진부한 콘텐츠를 후보 세트에서 제거합니다.
그런 다음 당사는 점진적으로 발전하는 랭킹의 여러 단계를 고용합니다. 초기 단계는 속도에 최적화된 어휘 및 임베딩 기반 스코어러에 의존합니다. 후보 세트가 점차 줄어들면, 더 강력한 크로스 인코더 리랭커 모델을 사용하여 결과 세트의 최종 조각(sculpting)을 수행합니다. 추론 성능에 대한 수많은 투자 덕분에, 전체 랭킹 지연 시간을 낮게 유지하면서 이 후반 단계에 최첨단 모델 아키텍처를 활용할 수 있습니다.
이 파이프라인 전반에 걸쳐 당사는 문서 및 하위 문서 수준에서 결과를 검색하고 점수를 매깁니다. 위에서 논의한 바와 같이, AI는 신중한 컨텍스트 엔지니어링이 필요합니다. 당사의 파이프라인은 모델에 가능한 가장 원자적인 단위를 노출하도록 설계되었으며, 이를 통해 후속 소비자는 소스 문서의 다른 곳에서 관련 없는 컨텍스트를 가져오지 않고도 해당 정밀한 단위를 통합할 수 있습니다.
이 파이프라인의 각 단계 전반에서 높은 품질을 보장하는 것은 Perplexity의 제품 포트폴리오와의 공동 설계를 통해서만 가능합니다. 랭킹 스택의 모든 세부 사항은 당사가 매일 매시간 제공하는 수백만 개의 사용자 요청에서 생성된 풍부한 신호를 활용하도록 설계되었습니다. 이 신호의 압도적인 대다수는 자동화되어 있으며, 생성된 각 Perplexity 답변은 실제 에이전트 워크플로우에서 사용되는 검색 품질에 대한 실증적 데이터 포인트를 제공합니다. 당사는 AI 기반 평가를 인간의 생생한 피드백과 결합하여 임베딩 및 랭킹 모델을 위한 학습 데이터를 수동으로 구성된 데이터 세트가 제공할 수 있는 수준 이상으로 풍부하게 만듭니다.
검색과 제품 간의 이러한 시너지는 Perplexity만의 고유한 특징입니다. 레거시 검색 엔진은 파란색 링크 원격 측정(blue-link telemetry)에서 제공하는 거친 신호에 국한됩니다. 새로운 검색 서비스들은 이러한 AI 지향적 개념들 중 일부를 구현하려고 시도했지만, 검색 품질을 검증하고 신속한 개선 루프에 필요한 신호의 풍부함을 제공할 수 있는 실제 환경이 부족합니다. 당사는 빠진 요소인 검색 품질을 위한 실시간 검증 시험장을 보유하고 있으며, 이는 프런티어 LLM에 의해 구동되고 전 세계 수백만 명의 호기심 많은 사용자에 의해 지속적으로 테스트됩니다.
품질과 성능을 위한 새로운 프런티어 구축
당사의 검색 인프라를 전 세계 개발자가 이용할 수 있도록 Perplexity Search API와 SDK를 구축한 후, 다양한 상용 API 제품들이 실제 AI 사용 사례에서 어떤 성능을 보이는지 이해하고자 했습니다. AI 모델 자체를 평가하는 것은 일상이 되었지만, 당사는 이 패턴에 변화가 필요했습니다. AI 모델이 호출했을 때 검색 API의 품질을 평가하는 것입니다.
당사는 먼저 오픈 소스 생태계를 통해 선행 기술을 이해하고자 했습니다. 엄격한 평가를 위한 핵심 요소들은 많이 발견했지만, 이러한 요소들을 플러그 앤 플레이 방식의 벤치마킹 솔루션으로 통합한 프레임워크는 없었습니다. 따라서 당사는 Perplexity뿐만 아니라 검색 API를 벤치마킹하려는 모든 연구자나 개발자가 사용할 수 있는 평가 프레임워크를 개발하기로 했습니다.
이 평가 프레임워크를 사용하여 당사는 Perplexity Search API를 다른 제품들과 함께 엄격하게 벤치마킹했습니다. 검색 성능을 최적화하는 것은 복잡하며, 품질과 속도 사이에는 많은 미묘한 트레이드오프가 존재합니다. 개발자들에게 다행스럽게도, Perplexity Search API는 품질과 지연 시간 모두에서 새로운 최첨단 성능을 설정함을 확인했습니다. 개발자들은 이제 매우 빠른 애플리케이션 구축과 고품질 결과 보장 사이에서 선택할 필요가 없습니다. Perplexity를 사용하면 두 가지 모두를 얻을 수 있습니다.
에이전트 검색 워크플로우를 위한 신뢰할 수 있는 평가 설계
당사는 평가 프레임워크에 대한 세 가지 지침 원칙을 정의하는 것으로 시작했습니다:
복잡성 스펙트럼: 평가 프레임워크는 간단한 에이전트 AI 사용 사례와 복잡한 에이전트 AI 사용 사례 모두에서 성능을 측정해야 합니다.
중립성: 평가 프레임워크는 모든 API를 동등한 입장에서 평가해야 합니다.
단순성: 특정 사용 사례는 복잡할 수 있지만, 프레임워크 자체는 다른 사람들이 이를 이해하고, 결과를 재현하며, 최소한의 번거로움으로 프레임워크를 확장할 수 있도록 가능한 한 단순해야 합니다.
당사의 경량 평가 프레임워크인 search_evals는 단순한 모듈형 설계를 통해 이러한 목표를 달성합니다. 당사는 고전적인 단일 샷(single-shot) 검색 사용 사례와 고급 에이전트 워크플로우(소비자 시장에서 널리 이용 가능한 다양한 “심층 리서치” 제품으로 예시됨)를 모두 포착하기 위해 두 가지 AI 에이전트 하네스를 개발했습니다. 두 하네스 모두 숨겨진 이점을 허용하지 않는 직관적인 방식으로 구현되었습니다.
평가를 추진하기 위해 당사는 네 가지 벤치마크를 채택했습니다. 단일 단계 검색을 위한 SimpleQA와 FRAMES, 그리고 심층 리서치를 위한 BrowseComp와 HLE입니다. 집합적으로, 이러한 벤치마크는 지식 에이전트를 위한 잘 받아들여지는 척도를 제공합니다. 확립된 관례에 따라 당사는 원본 연구에서 사용된 동일한 프롬프트 분류기 방법론을 사용하여 모든 벤치마크를 평가합니다. 정확한 벤치마크 구현(평가자 로직 포함)은 당사의 GitHub 저장소에서 검토할 수 있습니다.
당사는 재현성과 확장성을 염두에 두고 프레임워크를 설계했습니다. 작업 수준의 점수와 기본 에이전트 출력은 모두 각 실행과 함께 저장됩니다. 추가 하네스, 벤치마크 및 검색 API 제품을 쉽게 통합할 수 있습니다. 연구자와 개발자는 당사의 GitHub 문서를 읽고 귀하의 정확한 요구 사항을 해결하기 위해 프레임워크를 확장하는 방법에 대한 자세한 정보를 확인할 수 있습니다.
평가 결과
이 평가 프레임워크를 갖추고, 당사는 다른 API 제품들과 비교하여 당사의 Search API를 평가하기 시작했습니다. 테스트된 모든 벤치마크에서 Perplexity는 시장에서 가장 빠르고 품질이 높은 API로 자리매김했습니다.
당사는 위에서 설명한 색인, 검색 및 랭킹 효율성에 대한 투자가 훌륭한 성과를 거두었음을 확인했습니다. Perplexity의 중앙값 지연 시간은 358ms로, 두 번째로 빠른 제공업체보다 150ms 이상 앞서 있습니다. 95백분위수 지연 시간은 800ms 미만으로 편안하게 유지됩니다. 오늘날 프런티어 모델의 긴 TTFT(time-to-first-token) 지표를 고려할 때, 즐거운 사용자 경험을 만드는 데는 1밀리초가 중요합니다. 당사는 지난 2년 동안 자사 사용자를 위해 지연 시간을 최적화하는 데 힘써 왔으며, 이러한 투자가 이제 개발자 커뮤니티에도 혜택을 줄 것이라는 사실에 기쁘게 생각합니다.
Search API 지연 시간
(AWS us-east-1에서 시작된 요청)
p50 | p75 | p90 | p95 | |
Perplexity | 358ms | 443ms | 604ms | 763ms |
Exa | 1375ms | 1499ms | 1798ms | 2188ms |
Brave | 513ms | 637ms | 728ms | 808ms |
SERP 기반* | 1342ms | 1586ms | 1743ms | 1790ms |
AWS us-east-1에서 시작된 요청에 대한 Search API 지연 시간 백분위수.
* 많은 검색 API 공급업체는 결과의 기반으로 SERP 스크래핑을 사용합니다. 이러한 접근 방식의 성능을 포착하기 위해 당사는 Tavily에서 제공하는 대표적인 Google SERP 기반 API를 사용합니다.
이러한 속도 이점은 품질을 희생하지 않습니다. Perplexity Search API는 단일 단계 검색과 심층 리서치 환경 모두에서 최첨단 성능을 제공합니다. 테스트된 각 벤치마크에서 Perplexity는 다양한 복잡성의 AI 워크플로우를 구동할 수 있는 고품질 결과를 제공하는 데 선두를 달리고 있습니다. Perplexity와 최선의 대안 사이의 격차는 SimpleQA와 HLE에서 특히 두드러지며, 이는 이러한 결과가 작업 복잡성의 스펙트럼 전반에 걸쳐 강력함을 나타냅니다.
지연 시간과 마찬가지로, 당사의 검색 품질 리더십은 즐겁고 트래픽이 많은 AI 제품을 구축하는 데서 얻은 리더십의 연장선에 있습니다. 수백만 명의 사용자가 상상할 수 있는 모든 주제에 대한 호기심을 충족하기 위해 Perplexity를 사용하며, 그 결과로 얻어지는 품질 및 관련성 신호를 통해 당사의 검색 모델은 시간이 지남에 따라 개선됩니다.
Search API 품질 벤치마크
단일 단계 검색 | 심층 리서치 | |||
SimpleQA | FRAMES | BrowseComp | HLE | |
Perplexity | .930 | .453 | .371 | .288 |
Exa | .781 | .399 | .265 | .242 |
Brave | .822 | .320 | .221 | .191 |
SERP 기반* | .890 | .437 | .348 | .248 |
SimpleQA, FRAMES, BrowseComp, HLE에서의 Search API 품질 점수.
AI 네이티브 검색 엔진은 여전히 초기 단계에 있으며, 측정의 기술과 과학은 의심할 여지 없이 발전할 것입니다. 당사는 커뮤니티가 AI 에이전트 시대에 검색 엔진을 평가하기 위한 엄격하고 창의적인 방법을 개발함으로써 기여하기를 바랍니다.
AI의 다음 장을 위한 빌딩 블록
에이전트 시스템과 지능형 어시스턴트의 미래는 전 세계의 집단적 지식에 대한 풍부한 프로그래밍 인터페이스의 가용성에 달려 있을 것입니다. 오늘날의 레거시 검색 엔진은 하루 약 10¹⁰ 쿼리의 사용량으로 포화 상태에 이르렀으며, 이 수치는 정점에 도달했을 가능성이 높습니다. 차세대 검색 및 검색 시스템은 더 많은 요청을 처리하게 될 것이며, 끊임없이 성장하는 AI 에이전트 유니버스가 정확한 실시간 정보를 위해 이들에 의존하게 될 것입니다.
지금까지의 당사의 노력은 당사를 API를 통해 접근 가능한 가장 빠르고 성능이 뛰어난 검색 엔진으로 자리매김하게 했습니다. 그러나 당사가 AI의 다음 장을 활성화하려면 훨씬 더 야심 찬 혁신이 필요할 것입니다. 계속 증가하는 수요에 직면하여 이러한 시스템을 효율적으로 확장하려면 어떻게 해야 할까요? 새로운 컨텍스트 엔지니어링 및 사후 학습 접근 방식을 고려하여 이러한 검색 시스템을 어떻게 최적화할 수 있을까요? 그리고 완전성, 최근성, 지연 시간 사이의 끊임없는 긴장을 어떻게 탐색해야 할까요? 이는 당사의 제품 기반, 규모, 기술 인재 조합을 가진 Perplexity가 독보적으로 해결할 수 있는 열린 질문들입니다.
인용
@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}
}