Introducing our most accurate search yet
Quick Summary
Firecrawl은 검색 결과의 문단·목록·표를 쿼리별로 평가해 핵심 발췌문만 반환하도록 /search를 개선했으며, 자체 평가에서 SimpleQA 정확도 94.7%와 전체 페이지 처리 대비 10배 적은 토큰 사용을 기록했다고 발표했다.
🖼️ 인포그래픽
🖼️ 4컷 인포그래픽
💡 한 줄 요약
Firecrawl은 검색 결과의 문단·목록·표를 쿼리별로 평가해 핵심 발췌문만 반환하도록 /search를 개선했으며, 자체 평가에서 SimpleQA 정확도 94.7%와 전체 페이지 처리 대비 10배 적은 토큰 사용을 기록했다고 발표했다.
📌 핵심 요약
- Firecrawl의 개선된 /search는 각 검색 결과를 자체 관련성 모델로 처리해 사용자의 정확한 질의에 답하는 발췌문만 반환한다.
- 관련성 모델은 페이지의 모든 문단·목록·표를 질의와 대조해 점수를 매기고, 위치와 관계없이 관련도가 높은 내용을 구조화해 제공한다.
- Firecrawl은 4,326개 문항으로 구성된 SimpleQA 전체 평가에서 /search를 사용하는 에이전트가 94.7%를 기록해 자사가 시험한 다른 제공자보다 높은 점수를 얻었다고 밝혔다.
- 평가는 높은 추론 강도의 GPT-5.4 에이전트와 최대 20회의 검색·추출 도구 호출을 사용했으며, 동일 판정 기준에서 검색 도구가 없는 GPT-5.4의 기준 점수는 43.8%였다.
- 기존 /search 호출과 API 형식은 바뀌지 않았고, 개선 기능은 API·SDK·CLI·MCP 전체에 적용됐으며 필요하면 동일한 호출에서 전체 페이지 마크다운도 받을 수 있다.
🧩 주요 포인트
- 페이지 전체 대신 질의 관련 발췌문을 선별해 반환한다 → 에이전트가 탐색 메뉴, 상용 문구, 주제에서 벗어난 내용을 처리하는 부담을 줄인다.
- SimpleQA 자체 평가에서 94.7%를 기록했다 → Firecrawl은 검색 결과의 양보다 답과 직접 연결되는 문맥의 품질이 사실형 질의 성능에 중요하다는 근거로 제시한다.
- API 형식을 유지한 채 기본 반환 문맥만 개선했다 → 기존 이용자는 코드를 수정하지 않고 관련성 향상과 토큰 절감 효과를 적용받을 수 있다.
🧠 상세 정리
1. 검색 결과의 잡음을 줄이기 위한 업그레이드
Firecrawl이 제시한 기존 검색 도구의 문제는 필요한 답이 웹페이지의 잡음 속에 묻힌다는 점이다. 탐색 메뉴, 반복적인 상용 문구, 본론과 무관한 내용이 핵심 발췌문을 둘러싸기 때문에 에이전트는 실제 답변에 필요한 범위보다 훨씬 많은 콘텐츠를 처리하게 된다. 이 과정은 검색과 후속 모델 호출을 느리고 비싸게 만들며, 잘못된 답에 도달할 가능성도 높인다고 설명한다. 이에 Firecrawl은 /search의 모든 결과를 새로운 자체 관련성 모델로 처리하도록 변경했다. 개선된 엔드포인트는 페이지 전체를 그대로 넘기는 대신 사용자의 정확한 질의에 답하는 부분만 골라 반환하는 데 초점을 맞춘다.
2. 자체 관련성 모델의 작동 방식
새 관련성 모델은 검색 결과 페이지에 포함된 모든 문단과 목록, 표를 사용자의 질의와 대조해 각각 점수화한다. 핵심 정보가 페이지 상단이나 정해진 본문 영역에 있어야 한다고 가정하지 않고, 페이지 어디에 나타나든 관련도가 높은 발췌문을 찾아낸다. 선택된 내용은 에이전트가 바로 사용할 수 있도록 구조화된 형태로 반환된다. 각 결과에는 기존과 마찬가지로 제목, 주소, 설명이 포함되며, 기본 콘텐츠로는 질의와 관련된 마크다운 발췌문이 제공된다. 따라서 별도의 콘텐츠 분할이나 재정렬 단계를 두지 않고도 검색 결과에서 선별된 근거를 후속 프롬프트에 전달할 수 있다는 것이 Firecrawl의 설명이다.
3. SimpleQA에서 발표한 정확도
Firecrawl은 개선된 /search의 사실형 검색 성능을 OpenAI의 SimpleQA 벤치마크로 평가했다. SimpleQA는 짧고 사실을 묻는 질문에 모델이 올바르게 답하는지를 측정하는 평가로 소개된다. Firecrawl에 따르면 자사 /search를 이용한 에이전트는 이 평가에서 94.7%를 기록했다. 이는 Firecrawl이 동일 평가에서 시험한 다른 제공자보다 높은 점수라고 회사는 밝혔다. 또한 동일한 판정 모델과 기준을 적용했을 때 검색 도구 없이 답한 GPT-5.4는 43.8%를 기록해 비교 기준으로 제시됐다. 다만 94.7%는 외부 독립 평가가 아니라 Firecrawl이 수행한 평가에서 보고된 결과다.
4. 평가 구성과 결과 해석 조건
일반 제공자 평가는 높은 추론 강도로 설정된 GPT-5.4 에이전트가 최대 20회의 도구 호출을 수행하는 방식으로 진행됐다. 도구 구성에는 시험 대상 제공자가 지원하는 웹 검색과 각 제공자의 추출 API를 이용한 웹 가져오기가 포함됐다. Firecrawl Scrape, Parallel Extract, Exa Contents가 해당 추출 경로로 사용됐으며, Claude의 경우에는 Sonnet 4.6과 Anthropic의 서버 측 웹 검색을 결합한 완성된 시스템 단위로 평가했다. 답변 채점에는 GPT-5.4 기반 판정 모델과 공식 SimpleQA 채점 프롬프트가 사용됐다. 전체 4,326개 질문을 제공자별로 두 차례 실행한 뒤 관측된 점수 중 더 높은 값을 최종 점수로 선택했으므로, 수치를 비교할 때 이 선택 방식도 함께 고려해야 한다.
5. 토큰 절감과 주요 활용 사례
개선된 /search는 전체 페이지 콘텐츠 대신 핵심 발췌문을 반환해 전체 페이지를 처리할 때보다 토큰을 10배 적게 사용한다고 Firecrawl은 설명한다. 입력 토큰이 줄면 에이전트의 문맥 창에서 추론에 사용할 수 있는 공간이 더 많이 남고, 후속 모델 호출의 비용과 처리 시간도 감소한다. 장기간 여러 번 검색하는 다단계 에이전트에서는 각 질의에 답하는 내용만 축적해 문맥을 간결하게 유지할 수 있다. 검색 증강 생성과 언어 모델 근거 제공에서는 별도의 분할이나 재정렬 없이 관련 발췌문을 프롬프트에 넣을 수 있다. 이 밖에도 인물·기업의 직책이나 매출·채용 신호를 찾는 리드 보강, 특정 주장·수치·인용문을 추출하는 조사 및 시장정보 업무가 활용 사례로 제시됐다.
6. 기존 코드 호환성과 제공 범위
이번 업그레이드는 기존 /search 이용자가 호출 코드를 변경하지 않아도 자동으로 적용된다. API의 요청·응답 형식은 유지되며, 각 결과는 제목과 주소, 설명에 더해 질의와 관련된 마크다운 발췌문을 기본으로 반환한다. 발췌문만으로 부족한 경우에는 검색 호출의 스크레이프 옵션에서 마크다운 형식을 지정해 전체 페이지 콘텐츠를 함께 가져올 수 있다. Firecrawl이 제시한 예시는 유럽연합 인공지능법의 집행 일정 변경을 검색하고, 다섯 개 결과의 제목·주소·마크다운을 출력하는 방식이다. 개선된 기능은 모든 Firecrawl 사용자에게 공개됐으며 API뿐 아니라 SDK, CLI, MCP에서도 사용할 수 있다고 발표됐다.
🧾 핵심 주장 / 시사점
- 이번 개선의 핵심은 검색 결과 수를 늘리는 것이 아니라 각 결과 안에서 질의에 직접 답하는 근거를 선별하는 것으로, 검색과 후속 추론 사이의 문맥 정제 단계를 /search 내부로 옮긴 데 있다.
- 94.7%라는 수치는 SimpleQA 전체 문항, 지정된 에이전트·도구 구성, LLM 판정 방식에서 나온 Firecrawl 자체 평가 결과이며, 제공자별 두 번의 실행 중 최고 점수를 택했다는 조건과 함께 해석해야 한다.
- 기본 응답은 관련 발췌문으로 간소화하면서 전체 페이지 마크다운 선택권은 유지했기 때문에, 토큰 효율이 필요한 에이전트 검색과 원문 전체가 필요한 작업을 동일한 API에서 구분해 처리할 수 있다.
✅ 액션 아이템
- Firecrawl 개선 /search의 질의 관련 발췌문 반환이 에이전트의 탐색 메뉴·상용 문구 처리 부담을 실제로 줄이는지 점검한다.
- SimpleQA 4,326문항 자체 평가의 94.7%와 검색 도구 없는 GPT-5.4 기준 43.8% 격차가 사실형 질의에 미치는 의미를 비교한다.
- API 형식 유지와 전체 페이지 마크다운 선택 반환을 기준으로, 기본 발췌문 모드와 전체 문맥 모드의 토큰 사용 차이를 정의한다.
❓ 열린 질문
- 관련성 모델이 문단·목록·표를 질의와 대조해 점수를 매길 때, 높은 관련도의 판단 기준은 무엇인가?
- 전체 페이지 처리 대비 10배 적은 토큰 사용이 어떤 호출 조건과 발췌 길이에서 성립하는가?
- API·SDK·CLI·MCP에 동일 적용된 개선이 기존 /search 호출만으로도 94.7%에 가까운 성능을 재현 가능한가?