팀에서는 AI 에이전트용 웹 검색 API로 무엇을 만드나요?

이 네 가지 작업의 공통점은 무엇일까요?

각 작업에는 링크 목록만이 아니라 페이지의 텍스트가 필요합니다. 160자짜리 스니펫에는 모델이 인용해야 할 수치, 날짜, 조건이 거의 담기지 않습니다. 그래서 대부분의 스택은 결국 두 개의 서비스로 구성됩니다. URL을 찾는 검색 API와 그 URL을 가져오는 리더입니다.

LLMWebSearch는 이 두 단계를 하나로 합칩니다. 한 번의 호출로 실시간 웹 검색을 실행하고, 찾은 첫 페이지들을 읽습니다. 각 결과에는 순위, 제목, URL, 호스트, 스니펫이 포함되며, 페이지를 읽은 경우에는 해당 페이지의 본문이 Markdown 또는 일반 텍스트로, 단어 수와 알려진 경우 발행일과 함께 포함됩니다. 에이전트는 같은 왕복 안에서 인용할 수 있는 텍스트를 받고, 여러분은 청구서 하나만 받습니다.

또 다른 공통 요구 사항은 제어입니다. 결과를 몇 개 받을지(max_results), 페이지를 몇 개 읽을지(read), 각 페이지가 얼마나 길 수 있는지(max_chars)를 직접 정합니다. 이 세 숫자가 여러분 모델 쪽의 토큰 비용과 저희 쪽의 크레딧 비용을 모두 결정합니다.

각 사용 사례에는 어떤 설정이 맞나요?

기본값에서 시작해 한 번에 하나씩 바꾸세요.

• 에이전트 도구. max_results=5와 read=3는 그대로 두고, 페이지는 3,000~5,000자로 제한하세요. 에이전트는 도구를 자주 호출하므로 짧은 답변이 컨텍스트를 깔끔하게 유지합니다.
• 심층 리서치. 큰 검색 몇 번보다 작은 검색 여러 번이 더 낫습니다. 검색 쿼리당 read=3를 쓰고 쿼리 수를 늘리세요. read는 하나의 쿼리로 좁은 주제를 깊이 다뤄야 할 때만 올리세요.
• RAG. 더 긴 페이지(max_chars 약 12,000)를 요청하고 직접 청크로 나누세요. 답변이 알려진 출처에서 나와야 한다면 include_domains를 추가하세요.
• 뉴스 모니터링. topic=news와 time_range=day을 설정한 다음 이미 본 URL은 제거하세요. 쿼리당 기사 세 개를 읽고 무엇이 바뀌었는지 요약하세요.

모든 필터는 검색 레퍼런스에 정리되어 있습니다.

첫 팩 크기는 어떻게 정하나요?

일일 작업 수에 작업당 검색 수를 곱한 다음 30을 곱하세요. 하루 100개 질문에 각각 4회 검색으로 답하는 어시스턴트라면 한 달에 약 12,000회 검색이 필요합니다. 이는 검색 25,000회에 두 번째 달까지 여유 있게 들어갑니다.

크레딧은 결제 주기가 끝난다고 소멸하지 않습니다. 검색 크레딧에는 만료일이 없습니다. 이번 달에 사용하지 않은 크레딧은 내년에도 그대로 남아 있습니다. 프로토타입용으로 산 작은 팩은 프로젝트가 커질 때까지 가치를 유지합니다. 비용 가이드에서는 더 큰 세 가지 사례를 짚고 다른 API 및 모델에 내장된 검색 도구와 비교합니다.