모든 Agent API effort 수준 개선

Perplexity Agent API effort 수준의 비용이 낮아졌으며, 리서치 품질은 같거나 더 향상되었고, 깊이 있는 리서치를 위한 새로운 ultra 수준도 추가되었습니다.

Ascending glass panels reflecting a landscape and warm light.

Perplexity Agent API의 effort 수준을 사용하면 개발자가 과제마다 비용, 속도, 리서치 깊이 사이의 균형을 선택할 수 있습니다. 이제 모든 effort 수준의 쿼리당 비용이 낮아졌으며, 리서치 품질은 더 높아지거나 동일하게 유지됩니다. 가장 광범위하고 포괄적인 리서치를 위한 새로운 ultra 수준도 제공됩니다. effort="fast", 와 같이 이름으로 수준을 선택하는 모든 요청에는 업데이트된 구성이 자동으로 적용됩니다.

리서치 에이전트를 구축한다는 것은 과제마다 비용, 속도, 깊이 사이의 적절한 균형을 선택하는 것을 의미합니다. Agent API의 effort 수준은 사용자를 대신해 이 결정을 내립니다. 각 수준은 특정 과제 유형에 맞춰 모델, 단계 예산, 검색 설정, 도구를 정의하는 번들 구성입니다. Perplexity는 각 수준을 지속적으로 평가하고 업데이트하여 현재 비용 이하로 최상의 리서치를 제공합니다.

이러한 성과는 두 가지 유형의 변화에서 비롯되었습니다. 예산, 컨텍스트 처리, 추출은 각 실행의 비용을 낮췄고, 스킬, 모델 선택, 병렬 에이전트는 답변 품질을 높이거나 유지했습니다.

medium의 성능은 BrowseComp 및 DSQA에서 55%에서 77%로 향상되었으며, 비용은 거의 90% 감소했습니다. BrowseComp와 DSQA는 공개 리서치 벤치마크이고, WANDR은 여러 엔터티가 관련된 장시간 리서치 과제로 구성된 Perplexity의 벤치마크입니다. xhigh는 샌드박스에서의 코드 실행, 장시간 도구 사용 루프 유지, 여러 소스를 동시에 다루는 작업 등 에이전트형 작업을 수행합니다. xhigh는 2026년 8월 구성 대비 약 25%의 비용으로 실행되면서도 WANDR 점수를 76.5%로 유지했습니다.

리서치의 비용

심층 리서치 요청 하나는 답변하기 전에 수십 건의 검색을 실행하고, 수백 개의 페이지를 읽고, 증거를 확인할 수 있습니다. 이러한 작업 하나하나가 컨텍스트에는 토큰을, 청구서에는 비용을 더합니다. 제한이 없으면 에이전트는 답변을 개선하지 못한 채 비용을 높이고 컨텍스트를 채우는 작업을 계속합니다. 이 비용의 대부분은 다음 다섯 가지 요인에서 비롯됩니다:

  • 예산 할당. 정해진 예산이 있는 에이전트는 단계가 소진되어 과제를 마무리하기 전에 실행을 일찍 종료할 수 있습니다. 반대로, 고정 예산이 없는 에이전트는 최종 답변을 개선하지 못한 채 계속 실행되며 비용을 발생시킬 수 있습니다.
  • 컨텍스트 오버헤드. 검색 결과와 가져온 페이지에는 증거가 담겨 있지만, 관리하지 않으면 컨텍스트 창이 관련 없는 정보로 빠르게 채워질 수 있습니다. 컨텍스트 창의 비용은 단계마다 이어지며, 과부하된 창은 에이전트 성능을 떨어뜨릴 수 있습니다.
  • 워크플로우 선택. 과제마다 필요한 접근 방식이 다릅니다. 단일 사실 조회, 멀티홉 질문, 광범위한 소스 조사는 각각 다른 워크플로우가 필요합니다. 모델에게 선택을 맡기면 비효율적인 워크플로우를 고르는 경우가 많습니다. 사용 가능한 모든 전략을 에이전트의 프롬프트에 자세히 기술해도 이 문제는 해결되지 않습니다. 추가 지시는 매 단계마다 토큰으로 전달되며, 시간이 지날수록 모델이 각 지시를 따르는 신뢰도가 떨어집니다.
  • 모델 선택. 더 큰 모델로 전환해도 추가 비용에 상응하는 성능 향상을 얻지 못할 수 있습니다. 새 모델은 화제가 되는 헤드라인과 공개된 벤치마크 점수와 함께 등장합니다. 그러나 벤치마크 향상은 오염되었거나 모델의 과적합을 반영한 것일 수 있습니다. 실제 과제에서 평가하지 않으면, 모델 변경으로 품질은 높아지지 않고 비용만 늘어날 수 있습니다.
  • 멀티 에이전트 확장. 단일 에이전트가 한 번의 실행에서 검색하고 읽고 추론할 수 있는 소스의 수는 한정되어 있습니다. 여러 에이전트를 병렬로 실행하면 가장 까다로운 과제에서 품질이 향상되지만, 비용도 증가하며 올바르게 처리하지 않으면 복잡성이 생깁니다.

이러한 문제를 각각 해결한 결과, 성능 저하 없이 각 effort 수준의 비용을 줄일 수 있었습니다.

리서치 예산 제어

각 effort 수준에는 세 가지 요소로 구성된 고정 리서치 예산이 있습니다:

  • 단계 한도: 에이전트가 수행할 수 있는 턴 수
  • 도구 호출: 하나의 요청에서 수행할 수 있는 총 도구 호출 수의 상한입니다. 단일 단계에서 여러 도구에 걸쳐 여러 호출을 동시에 실행할 수 있으므로, 단계 한도만으로는 한 단계 내에서 발생하는 작업 수를 제어할 수 없습니다.
  • 예산 리마인더: 남은 단계 수를 주기적으로 알려 주는 안내로, 에이전트가 우선순위를 정하고 과제 도중에 예산이 소진되는 대신 답변을 작성할 여유를 남길 수 있도록 합니다.

예산은 핵심적인 트레이드오프입니다. 단계가 많을수록 더 나은 답변을 얻지만, 모든 단계에는 비용이 발생합니다. openai/gpt-6-luna에서 단계 한도를 1에서 15로 늘리면 BrowseComp + DSQA 정확도가 41%에서 80%로 향상되는 반면, 쿼리당 비용은 $0.0017에서 $0.0152로 증가합니다. 즉, 약 2배의 점수를 위해 약 9배의 비용이 드는 셈입니다.

단계 한도만으로는 리서치 비용을 제어할 수 없습니다. 동일한 5단계 예산에서 openai/gpt-6.1-terra는 openai/gpt-6-luna보다 더 많은 도구 호출을 수행하는데, 이는 성능이 더 뛰어난 모델일수록 한 단계에서 여러 호출을 실행하는 경향이 있기 때문입니다. effort 수준은 도구 호출과 단계 모두에 상한을 둡니다. 이러한 모델에서는 도구 호출 상한이 단계 한도만큼 중요합니다.

각 effort 수준은 이러한 한도를 조정하지만, 에이전트도 요청을 처리하는 데 남은 단계와 작업이 얼마나 되는지 알아야 합니다. 이 정보가 없으면 단계나 작업이 소진되어 리서치가 완료되기 전에 답변을 내놓아야 할 수 있습니다. 예산은 실행 시작 시 명시되고, 에이전트가 한도에 가까워지면 리마인더가 전달되므로 결과를 검증하고 전달할 여유가 생깁니다. high 수준에서는 리마인더가 단계 예산과 도구 호출 예산을 모두 다룹니다.

예산 리마인더가 있는 에이전트와 없는 에이전트를 대상으로, 출연진 세 명의 약력을 보고 1990년대 TV 시리즈를 알아내는 BrowseComp 과제를 테스트했습니다. 리마인더가 있는 에이전트는 예산 40단계 중 13단계만 사용해 정답을 찾았습니다. 예산 리마인더가 없는 에이전트는 40단계를 모두 사용하고도 정답을 찾지 못했습니다. 이 에이전트의 루프는 예기치 않게 종료되었고, 모델은 남은 리서치 예산을 인지하지 못했습니다. 리마인더는 에이전트가 집중력을 유지하고 남은 리소스의 우선순위를 효과적으로 정하도록 돕습니다.

컨텍스트 관리

압축

장시간 실행되는 리서치 과제는 모델의 컨텍스트 창을 검색 결과, 가져온 페이지, 중간 메모로 채웁니다. 컨텍스트 창이 가득 차면 에이전트는 작업을 중단해야 합니다.

압축은 컨텍스트 창을 가득 채우지 않고도 장시간 실행이 계속되도록 합니다. 컨텍스트가 임계값을 초과하면 에이전트는 지금까지의 작업 내용을 발견한 사항과 남은 작업을 정리한 더 짧은 요약으로 대체한 뒤 작업을 이어갑니다.

압축 시에도 컨텍스트에는 항상 세 가지가 유지됩니다. 시스템 프롬프트, 원래 요청, 그리고 에이전트가 이미 로드한 모든 스킬입니다. 압축이 끝날 때마다 에이전트는 두 가지 짧은 지시를 받습니다. 첫 번째 지시는 ‘작업이 완료될 때까지 계속 진행하세요.’입니다. 이 지시는 에이전트가 요약을 중단 지점으로 간주하지 않도록 합니다. 두 번째 지시는 지금까지 압축이 몇 번 이루어졌는지 알려 주어, 에이전트가 남은 리서치 과제를 계획할 수 있게 합니다. 장시간 실행에서도 원래 목표와 계획이 유지되며, 품질 저하 없이 긴 루프의 비용이 줄어듭니다.

필요한 것만 가져오기

에이전트가 읽는 모든 페이지는 컨텍스트에 추가되며, 에이전트는 이후 모든 단계에서 이를 계속 가지고 갑니다. 웹 페이지에는 내비게이션, 상용구 및 기타 콘텐츠 등 질문과 관련 없는 정보가 포함되어 있습니다.

fetch_url 은 에이전트에게 페이지 전체를 넘기는 대신 먼저 추출 과정을 실행합니다. 페이지 텍스트는 에이전트의 현재 과제와 함께 더 작은 모델로 전송됩니다. 이 모델은 관련된 구절만 반환하며, 에이전트가 인용할 수 있도록 원문 그대로 가져옵니다. 한 평가에서는 5,561토큰 분량의 페이지가 293토큰으로 줄어들어, 추가적인 관련 컨텍스트를 위한 공간이 확보되었습니다.

fetch_url 의 추출 기능을 high effort 수준에서 사용한 결과, 쿼리당 입력 토큰이 약 50% 감소했습니다. 추출 기능은 벤치마크 성능도 향상시켜, 추출을 사용하지 않았을 때 쿼리당 $0.094에 83.5%였던 결과를 쿼리당 $0.073에 88.0%로 끌어올렸습니다.

집중된 웹 검색

웹 검색은 모든 에이전트 리서치 요청의 핵심입니다. 에이전트의 검색 방식에 다음 세 가지 변경 사항이 적용되었습니다:

  • 검색당 더 많은 컨텍스트: 이제 각 검색은 2K 대신 최대 4K 토큰 분량의 결과를 반환합니다. 에이전트가 필요한 정보를 더 빨리 찾으므로 검색 횟수가 줄고 비용이 낮아집니다.
  • 새로운 스니펫 엔진: 검색 결과에 쿼리와 더 잘 맞는 스니펫이 제공되므로 에이전트가 관련 없는 텍스트로 과부하되지 않습니다.
  • Fast Search: 요청 1,000건당 $1.00인 Fast Search는 각 검색 호출의 비용과 지연 시간을 모두 줄여 줍니다.

Perplexity Search 팀은 다양한 과제에서 검색 품질을 지속적으로 개선하고 있습니다. 최근 업데이트로 코드, 개발자 문서, 참조 페이지, 법률 및 규제 콘텐츠 전반에서 성능이 향상되었습니다.

올바른 워크플로우 선택

어떤 과제는 많은 검색을 병렬로 실행해야 하고, 어떤 과제는 몇 개의 긴 문서를 꼼꼼히 읽어야 합니다.

그러나 모든 워크플로우를 에이전트의 시스템 프롬프트에 로드하면 컨텍스트 오버헤드가 늘어나고, 단순한 과제에서 모델 성능이 떨어질 수 있습니다. 그래서 스킬은 점진적 공개 방식의 트리 구조로 구성됩니다. 모델은 작업하면서 관련 스킬과 지시를 로드하고, 관련 없는 정보는 컨텍스트에서 제외합니다. 각 스킬은 모델이 과제에 적합하다고 판단해 로드하기 전까지는 이름과 설명만큼의 비용만 차지합니다. 로드되는 시점에 전체 지시가 컨텍스트에 추가되고, 모델은 정해진 워크플로우를 따릅니다.

개별 스킬의 기여도를 측정하기 위해, 기준 에이전트가 해당 스킬을 로드한 과제에서 스킬을 하나씩 제거하며 품질과 비용을 비교합니다. 이러한 어블레이션 실험을 통해 어떤 워크플로우가 에이전트에 도움이 되는지, 그리고 리서치 효율성에 어떤 영향을 미치는지 알 수 있습니다.

아래 WANDR 벤치마크 실행 결과는 에이전트가 특정 과제에 맞는 올바른 워크플로우를 선택하는 모습을 보여 줍니다. 여러 엔터티를 조사해야 하는 특성을 반영해, 광범위 검색 및 팬아웃 가이드는 모든 과제에서 로드되었습니다. 인물 검색은 과제의 6%에서만, 그리고 질문에 사람이 관련된 경우에만 로드되었습니다.

또 다른 WANDR 과제를 테스트할 때, 에이전트는 런던의 추론 엔지니어를 찾기 위해 팬아웃 패턴이 포함된 인물 검색 스킬을 로드했습니다. 에이전트는 39개의 직무 용어를 117개의 쿼리로 확장한 다음, 1차 결과를 병합해 추가 심사 대상인 고유 프로필 43개로 정리했습니다. 인물 검색 스킬은 관련 없는 컨텍스트를 추가하지 않고 에이전트가 이 확장 과정을 수행하도록 안내했습니다. 아래 발췌문은 에이전트의 스크립트를 바탕으로 수정한 것이며, 헬퍼 이름은 예시입니다.

code1
text
Python # roles contains the 39 role variants selected by the agent. queries = [] for role in roles: queries.extend([ {"query": f"Google DeepMind {role} London"}, {"query": f"Google {role} London"}, {"query": role, "company": "Google", "location": "London"}, ]) results = pplx_sdk.search.people_many( queries, limit_per_query=50, concurrency=8 ) profiles = {} for result in results: if not result.ok: continue for profile in result.result: if "linkedin.com/in/" not in profile.url: continue url = profile.url.split("?")[0].rstrip("/") previous = profiles.get(url, {}) if url not in profiles or len(profile.summary or "") > len( previous.get("summary") or "" ): profiles[url] = { "url": url, "title": profile.title, "summary": profile.summary, }

체크포인팅은 장시간 실행되는 과제에서 에이전트에 도움이 되는 또 다른 워크플로우입니다. 체크포인팅 패턴은 배치 프로그래밍에서 유래했습니다. 스크립트가 긴 목록을 처리할 때 모든 결과를 끝까지 메모리에 보관하는 대신, 결과가 나오는 즉시 디스크에 기록합니다. 스크립트가 도중에 중단되거나 오류가 발생해도 손실되는 것은 없습니다. 다음 실행에서 이미 저장된 내용을 읽고 중단된 지점부터 이어서 진행하며, 실패한 항목만 다시 시도합니다.

또 다른 WANDR 과제에서 에이전트는 엔지니어 188명의 프로필을 심사해야 했습니다. 에이전트는 작업하면서 각 결과를 기록하기 위해 체크포인트 패턴을 로드했습니다. 첫 번째 실행에서 160개의 프로필을 추출했지만 28개는 실패했습니다. 에이전트가 스크립트를 다시 실행했을 때, 이미 기록된 프로필은 건너뛰고 남은 28개만 다시 시도했습니다. 체크포인트가 없었다면 잘못된 레코드 하나 때문에 188개를 모두 다시 가져와야 했을 것입니다.수정된 Python 발췌문입니다. 입력 페이지, 심사 지시, 스키마, import 문은 생략했으며 헬퍼 이름은 예시입니다.

code 2
text
Python checkpoint = Checkpoint("research/profile-screening") config = instruction + json.dumps(schema) config_id = hashlib.md5(config.encode()).hexdigest()[:6] def checkpoint_key(page): url_id = hashlib.md5(page["url_in"].encode()).hexdigest()[:10] return config_id + url_id pending = [ page for page in pages if not checkpoint.has(checkpoint_key(page)) ] for offset in range(0, len(pending), 20): batch = pending[offset : offset + 20] inputs = [ json.dumps({ "url": page["url_in"], "content": page["content"][:30_000] }) for page in batch ] results = pplx_sdk.llm.extract_many( inputs, instruction=instruction, output_schema=schema, chunk_size=5, concurrency=4, ) for page, result in zip(batch, results): if not result.ok or result.result.error: continue checkpoint.record( checkpoint_key(page), [{"url": page["url_in"], **result.result.result}], )

체크포인트는 성공한 결과를 기록할 뿐, 재시도를 시작하지는 않습니다. 키에 지시와 스키마를 포함하면 심사 기준이 변경될 때 재처리가 실행됩니다.

모든 테스트가 품질과 효율성 향상으로 이어진 것은 아닙니다. 에이전트가 과제를 시작하기 전에 모든 스킬을 미리 로드하는 방식도 평가했습니다. BrowseComp와 DSQA에서는 사전 로드로 비용이 13% 증가했습니다. 리서치 궤적이 길어 검색된 콘텐츠가 입력 토큰에서 더 큰 비중을 차지하는 WANDR에서는 사전 로드가 점수도 떨어뜨립니다. 이 결과는 점진적 공개 방식을 계속 사용하는 근거가 되었습니다.

모델 선택

모델 성능이 발전함에 따라 각 effort 수준에 가장 적합한 모델도 달라집니다. Perplexity는 새 모델 발표와 출시 여부를 모니터링하는 자동화된 리서치 루프를 운영합니다. 모델을 사용할 수 있게 되는 즉시 평가가 시작됩니다.

새 모델이 출시되면 자동화된 에이전트가 해당 모델을 평가 하네스에 투입합니다. 에이전트는 추론 강도, 단계 및 도구 호출 예산, 도구 구성을 폭넓게 탐색하고, 모든 실행을 현재 effort 수준과 비교해 품질과 비용 측면에서 평가합니다. 성능이 저하된 실행이 있으면 에이전트는 원인을 조사하고 설정을 조정한 뒤 평가를 다시 실행합니다. 후보 모델은 동일하거나 더 낮은 비용으로 품질에서 앞설 때만 현재 모델을 대체합니다.

공개 벤치마크는 유용하지만, 그 점수가 항상 실제 과제의 성과로 이어지는 것은 아닙니다. 예를 들어, 아래 차트는 BrowseComp에서 기준선보다 13.3점 높은 점수를 받았지만 내부 엔터프라이즈, 법률, 금융 리서치 과제에서는 해당 기준선에 크게 못 미친 후보 모델을 보여 줍니다.

멀티 에이전트 확장

단일 에이전트가 하나의 루프에서 다룰 수 있는 소스에는 한계가 있습니다. 복잡한 과제에서는 여러 에이전트가 병렬로 작업하며, 각 에이전트가 문제의 서로 다른 부분을 맡아 협력합니다.

기본 에이전트는 오케스트레이터 역할을 합니다. 오케스트레이터는 spawn_agent를 호출해 하위 에이전트를 생성하고, 각 에이전트에 구체적이고 집중된 과제를 할당합니다. 각 하위 에이전트는 별도의 컨텍스트에서 자체 모델, 도구, 단계 예산을 사용해 고유한 리서치 루프를 실행합니다. 하위 에이전트는 결과를 상위 에이전트에 보고하며, 상위 에이전트는 하위 에이전트에 후속 과제를 보내거나 진행 상황을 확인할 수 있습니다. 오케스트레이터와 하위 에이전트는 메시지를 주고받으며 증거를 공유하고, 차단 요인을 알리고, 다음 단계를 조정합니다. 새로운 정보가 들어오면 오케스트레이터는 과제를 구체화하고, 작업이 완료되면 결과를 하나의 답변으로 통합합니다.

Agent API는 사전 정의된 에이전트 역할을 지원하며, 오케스트레이터는 사용자 지정 지시가 포함된 하위 에이전트를 생성할 수 있습니다.

ultra effort 수준은 하나의 과제에 세 개의 에이전트를 병렬로 실행합니다. 각 에이전트는 전체 과제를 독립적으로 조사하므로 서로 다른 증거를 확보하게 됩니다. 네 번째 에이전트가 이들의 결과를 병합하고 중복을 제거한 뒤 최종 답변을 작성합니다.

WANDR에서 ultra는 과제당 $21.71의 비용으로 85.9%를 기록했습니다. 이는 테스트한 구성 중 가장 높은 점수입니다.

다음 단계

effort 수준은 지속적으로 평가되고 개선됩니다. 사용자가 선택한 수준에 따라 과제에 투입되는 리서치의 양과 비용이 결정됩니다. 단계 및 도구 호출 예산과, 예산이 줄어들 때 제공되는 리마인더가 요청을 예산 범위 내로 유지합니다. 압축, 추출, 개선된 스니펫은 컨텍스트가 증거에 집중되도록 합니다. 스킬은 과제에 맞는 워크플로우를 연결하고, 병렬 에이전트는 하나의 루프가 다룰 수 있는 범위를 넓힙니다. 자동화된 평가 루프는 동일한 비용에서 리서치 품질을 개선하는 경우에만 새 모델을 채택합니다.

새로운 모델과 구성이 평가에서 효과를 입증함에 따라 각 effort 수준은 계속 발전할 것입니다. 수준을 이름으로 호출하면 이러한 개선 사항이 자동으로 적용되며, 버전을 고정하면 구성이 그대로 유지됩니다.

Agent API를 사용해 보고 직접 운영하는 워크로드에서 effort 수준을 비교해 보세요. effort 수준에 대한 자세한 내용은 Agent API effort 문서에서 확인할 수 있습니다.