퍼플렉시티, 검색 API Fast Search 공개

퍼플렉시티가 AI 에이전트를 위한 검색 API 프리셋 Fast Search를 내놨어요. 검색 한 번에 걸리는 시간이 중앙값 기준 160밀리초, 상위 5%를 뺀 95번째 백분위 기준 230밀리초예요. 같은 날 누스리서치는 자사 오픈소스 에이전트 헤르메스 에이전트(Hermes Agent)의 기본 검색을 Fast Search로 바꾸고, 누스 포털 모든 요금제에서 무료로 쓰게 했어요. 누스리서치는 X에 "헤르메스 에이전트의 웹 검색이 이제 빠르고 무료"라고 적었고, 이 글은 하루도 안 돼 조회수 15만 회를 넘겼어요.

Fast Search 뒤에는 퍼플렉시티가 새로 만든 검색 엔진 Photon이 있어요. 퍼플렉시티 API 포럼 공지에 따르면 Photon은 러스트(Rust)로 짠 검색·순위 서비스이고, 소수의 엔지니어와 수백 개의 에이전트가 함께 만들었어요. 엔지니어링 블로그는 이를 두고 작은 엔지니어링 팀이 끊임없이 돌아가는 코딩 에이전트 무리와 나란히 일했다고 설명했어요. 공지는 검색 결과의 95%를 230밀리초 안에 돌려준다고 밝혔어요.

에이전트용 검색에서 속도가 중요한 이유는 호출 횟수에 있어요. 사람은 질문 하나에 검색을 한두 번 하지만, 리서치 에이전트는 과제 하나를 풀려고 검색을 수십 번 이어서 불러요. 한 번에 수백 밀리초씩 늦어지면 그 지연이 과제 전체로 쌓여요. 퍼플렉시티가 공개한 자체 측정 도표에서 Fast Search는 중앙값 160밀리초로, 경쟁 검색 API가 각자 공개한 수치인 Exa Instant 178밀리초, Parallel Turbo 200밀리초, Exa Fast 423밀리초, Parallel Fast 700밀리초보다 앞섰어요. 다만 회사는 백분위 기준과 측정 환경이 서로 달라 같은 조건의 비교는 아니라고 도표 설명에 적었어요.

비용 쪽 숫자는 더 커요. 퍼플렉시티는 WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0, SEAL-Hard 등 에이전트 벤치마크 6개에서 고른 과제 3,554개로 Fast Search를 시험했어요. 과제 수로 가중한 점수는 Fast Search가 64.3%, 기본 프리셋이 64.0%로 거의 같았는데, 모델 사용료와 검색 비용을 더한 추정 총비용은 Fast Search가 약 68% 낮았어요. 시험한 구성 가운데 점수가 가장 높고 비용이 가장 낮았다는 게 회사 설명이에요.

속도는 엔진을 통째로 갈아 끼워서 얻었어요. 퍼플렉시티는 원래 오픈소스 검색 엔진을 가져와 자체 포크로 고쳐 쓰고 있었어요. 색인과 작업량이 커지자 비용과 꼬리 지연, 장애 복구 시간에서 벽에 부딪혔다고 블로그는 밝혔어요. 옛 시스템의 응답 시간은 상위 1%를 뺀 99번째 백분위 기준 약 800밀리초였고, 디스크 색인을 합치는 동안에는 10~15분씩 1.2초까지 치솟았어요. 새 클러스터를 띄워 데이터를 맞추는 데는 일주일이 넘게 걸리기도 했어요.

Photon으로 옮긴 뒤 운영 환경의 99번째 백분위 응답 시간은 약 65밀리초로 떨어졌어요. 서빙 장비는 옛 시스템보다 약 20% 적게 쓰면서 문서 한 건당 담는 데이터는 약 2.5배로 늘었어요. 같은 데이터를 전부 메모리에 고정해 두려면 지금보다 약 4.6배 많은 메모리가 필요하다고 회사는 추산했어요. 전체 웹 색인을 새로 만드는 일도 한 자릿수 시간 안에 끝나요. 신선도가 중요한 검색 분야에서는 문서가 몇 분 안에 색인에 들어가요.

설계의 뼈대는 필요한 만큼만 읽는 거예요. 단어마다 그 단어가 들어간 문서 목록을 두되, 목록 길이와 밀도에 따라 저장 형식을 바꿔요. 순위를 매길 때는 문서마다 docblob이라는 압축 기록 하나만 열고, 질의어와 맞는 부분만 풀어요. 디스크에서 읽어야 할 기록은 리눅스의 io_uring으로 한꺼번에 요청해 대기 시간을 겹치게 했어요. 색인 생성은 검색을 처리하는 장비와 떼어 내, 새 색인을 만들어도 실시간 질의와 CPU를 다투지 않아요.

도입은 단계를 밟았어요. 검색 기록을 다시 재생하는 부하 시험과 오프라인 품질 평가를 거친 뒤, 실제 질의를 두 엔진에 동시에 보내는 섀도 트래픽으로 결과를 비교했어요. 이어 일부 사용자에게만 Photon을 켜고 범위를 넓혀 지금은 운영 트래픽 전부를 처리해요. 첫 버전이 품질 저하 없이 인수 시험을 통과했다고 회사는 밝혔어요.

Fast Search는 순위 계산에 기본 프리셋보다 연산을 덜 써요. 그래서 드문 질의와 넓은 범위, 결과 다양성을 보는 내부 평가에서는 관련도 점수가 2.45에서 2.21로 0.24점, 답을 찾을 수 있는 비율이 약 3%포인트 낮아요. 퍼플렉시티는 "모델 자신의 추론과 지식이 그 차이를 메울 수 있어 에이전트 작업에는 합리적인 절충이라고 본다"고 주장했어요. 그러면서 "시간이 덜 급한 어렵고 모호한 질문에는 기본 프리셋이 더 견고한 품질을 준다"며 일상적인 에이전트 작업에만 Fast Search를 권했어요.

메탈이 확인한 퍼플렉시티 개발자 계정 공지는 Fast Search가 누스 포털 구독자의 헤르메스 에이전트 기본 검색이 됐다고 적었어요. 메탈은 누스리서치가 헤르메스 플러그인 카탈로그를 공개한 소식과 헤르메스 비즈니스·엔터프라이즈 요금제를 내놓은 소식을 보도한 바 있어요. 오픈소스 에이전트가 기업용으로 몸집을 키우는 흐름에서, 이번에는 검색이라는 기본기를 외부 인프라로 채운 셈이에요.

에이전트 시대의 검색 경쟁은 누가 더 많이 찾느냐보다 누가 더 싸고 빠르게 찾느냐로 옮겨 가고 있어요. 퍼플렉시티는 CobbleDB와 검색 API에 이어 Photon까지 검색 인프라를 자체 러스트 기반으로 옮기고 있다고 밝혔어요. 이번 발표에서 눈여겨볼 대목은 숫자 자체보다 그 숫자를 만든 방식이에요. 소수의 엔지니어가 에이전트 수백 개와 함께 핵심 엔진을 처음부터 다시 짰고, 그 엔진이 다시 다른 회사의 에이전트를 떠받치고 있어요.