Mozilla AI가 묻는다: 에이전트를 위해 웹을 검색하는 것은 누구인가?
Mozilla AI는 팀이 모델과 별개로 검색 서비스를 선택할 수 있게 하는 Otari로, 묶음형 에이전트 검색 방식에 도전하고 있다. 에이전트를 위해 웹을 검색하는 것은 누구인가? 10월 19일 게시물은 이 질문을 구체화한다. AI 모델을 선택했다고 해서 검색 쿼리가 어디로 향하는지까지 정해지는 것은 아니다.
Otari는 작업을 완료하기 위해 도구를 사용하는 소프트웨어인 에이전트와 모델 제공업체 사이에 위치한다. Mozilla AI는 이 위치를 통해 지원되는 클라이언트 인터페이스를 유지하면서 검색을 다른 곳으로 라우팅할 수 있다고 말한다. 제안된 변화는 어떤 모델이 답변을 작성하는가가 아니라, 누가 정보 검색을 통제하는가에 관한 것이다.
경쟁하는 접근법은 간단하다. 모델 서비스에 포함된 검색을 받아들이거나, 검색을 별도의 종속성으로 관리하는 방식이다. Claude Code는 내장 검색이 Anthropic의 백엔드를 사용한다는 점에서 유용한 기준점이 된다. Otari는 검색 라우팅을 독립적인 결정으로 만들며, 그 결정을 내리는 주체에게 추가 책임도 부여함으로써 이러한 구도에 도전한다.
에이전트를 위해 웹을 검색하는 것은 누구인가? Otari는 선택을 명시한다
Mozilla AI는 에이전트 검색 분석에서 세 가지 선택지를 설명한다. Otari가 운영하는 검색, 고객의 검색 계정, 또는 자체 호스팅 엔드포인트다. 회사는 고객이 자신의 자격 증명을 사용해 연결할 수 있는 서비스로 Brave, Exa, Tavily를 언급한다.
Mozilla AI에 따르면 고객은 검색을 처리하는 서비스를 바꾸면서도 Claude, GPT 또는 Gemini를 계속 사용할 수 있다. 검색 자격 증명은 에이전트까지 전달되지 않고 요청을 라우팅하는 중개자인 게이트웨이에 남는다. 회사는 또한 모델 사용과 연계된 워크스페이스 제어 기능과 검색 기록을 설명한다.
중요한 변화는 팀이 모델과 별개로 선택할 수 있는 종속성으로 검색을 만든다는 점이다.
애플리케이션이 하나의 답변 입력창을 제시하면 이러한 구분을 놓치기 쉽다. 사용자는 질문을 하고, 기다린 뒤 인용을 포함한 응답을 받는다. 실제로는 서로 다른 서비스가 수행하더라도, 인터페이스는 검색과 추론을 하나의 작업처럼 보이게 할 수 있다.
이 작업들을 분리하면 구매자가 시스템을 평가하는 방식도 달라진다. 모델 평가는 모델이 지시를 따르고 효과적으로 추론하는지를 살핀다. 검색 평가는 시스템이 적절한 근거를 가져오는지, 쿼리를 수용 가능한 방식으로 처리하는지, 조직의 운영 요건을 충족하는지를 묻는다.
어느 평가도 다른 평가를 대체하지 않는다. 우수한 추론도 근거 집합에 들어오지 않은 문서를 되살릴 수는 없다. 강력한 검색도 근거 없는 결론을 모두 막을 수는 없다. 이들을 분리해 다루면 팀은 모든 문제를 모델 탓으로 돌리지 않고 실패 원인을 더 명확하게 조사할 수 있다.
Mozilla AI의 게시물은 제품 방향성과 문서화된 기능에 대한 설명으로 정확히 읽어야 한다. 게시 날짜만으로 모든 기반 기능이 언제 제공되기 시작했는지는 알 수 없다. 또한 발표만으로 고객이 이미 더 나은 답변이나 더 낮은 운영 비용을 달성했다는 사실이 입증되는 것도 아니다.
따라서 당장의 뉴스는 에이전트 검색 문제가 해결됐다는 주장보다 범위가 좁다. Mozilla AI는 검색 공급업체를 구매와 아키텍처 논의에서 명시적인 요소로 만들고 있다. 이는 선택한 모델에 따라 제공되는 검색 서비스를 그대로 받아들이는 방식에 실질적인 대안을 제시한다.
이미 묶음형 검색에 만족하는 팀에게는 이 대안이 운영 부담을 정당화해야 한다. 수용하기 어려운 검색 방식 때문에 막힌 팀에게는 이 종속성을 분리하는 것이 전혀 다른 문제를 해결한다. 이들에게 필요한 것은 또 하나의 모델 리더보드가 아니라, 평가할 수 있는 선택지다.
쿼리 자체도 면밀히 살펴야 한다
검색 쿼리는 요청된 답변이 공개 정보에 관한 것이더라도 외부로의 정보 공개다.
소프트웨어 장애를 조사하는 가상의 코딩 어시스턴트를 생각해 보자. 유용한 공개 쿼리에는 오류 메시지와 라이브러리 버전이 포함될 수 있다. 지나치게 구체적인 쿼리에는 내부 서비스 이름, 고객 식별자 또는 미공개 프로젝트 이름까지 포함될 수 있다.
이 구분은 공개 문서를 읽어도 안전한지 여부가 아니라, 무엇이 조직 밖으로 나가는지에 관한 것이다. 어시스턴트가 검색할 정당한 이유가 있더라도 부적절한 쿼리를 만들 수 있다. 검색 공급업체를 선택하는 일은 수신자를 다루고, 쿼리 구성을 검토하는 일은 내용을 다룬다.
이 분리는 엔지니어링 관리자와 기업 구매자에게 중요하다. 모델을 승인했다고 해서 그 모델에 연결된 도구에 관한 모든 질문에 답한 것은 아니다. 추가 서비스마다 독립적으로 평가할 가치가 있는 운영 관계가 생기며, 특히 쿼리가 비공개 업무 맥락에서 비롯될 때는 더욱 그렇다.
합리적인 대응은 실제 작업의 흐름을 추적하는 것이다. 어떤 정보가 프롬프트에 들어갔는가? 어떤 텍스트가 검색 쿼리가 되었는가? 어느 서비스가 이를 받았는가? 어떤 결과가 돌아왔고, 그중 어떤 결과가 답변에 영향을 미쳤는가?
이 질문들은 구매 논의를 더 구체적으로 만든다. 또한 주장이 어디에서 멈추는지도 드러낸다. 목적지를 안다고 해서 라우팅에 대한 가시성이 확보되는 것은 맞다. 그러나 모든 쿼리가 필요했고 적절히 작성됐으며 수용 가능한 처리 조건의 적용을 받았다는 점까지 입증되지는 않는다.
같은 논리는 고객 조사에도 적용된다. 잠재 고객 계정에 관한 브리핑을 준비하는 어시스턴트를 상상해 보자. 공개 기업 정보는 조사 과정에 포함될 수 있다. 비공개 영업 메모, 제안된 계약 문구, 내부 평가는 외부 쿼리에 등장하기 전에 별도의 결정이 필요하다.
이는 문서화된 Otari 고객 배포 사례가 아니라 예시 시나리오다. 그 가치는 검색 선택이 개발자 선호를 넘어 중요한 이유를 보여주는 데 있다. 평범해 보이는 검색도 최종 답변에서는 드러나지 않는 경계를 넘을 수 있다.
지식 근로자는 공개 정보 탐색과 자신의 자료 검색도 구분해야 한다. 개인 지식 베이스는 새로운 공개 출처를 찾는 것과는 다른 정보 요구를 다룬다. 효과적인 워크플로는 어디를 검색할지 결정하기 전에 작업에 어떤 종류의 근거가 필요한지 식별해야 한다.
제품 관리자에게 이는 현재의 경쟁사 정보를 요청하기 전에 내부 조사를 참고하는 것을 뜻할 수 있다. 엔지니어에게는 공개 문서를 찾아보기 전에 비공개 설계 결정을 확인하는 것을 뜻할 수 있다. 핵심은 모든 불확실성을 열린 웹으로 보내는 대신 목적에 맞게 정보를 검색하는 데 있다.
이는 에이전트 배포를 승인하는 사람들에게 부담을 준다. 이들은 한계를 포함한 정보 경로를 설명할 수 있을 만큼의 가시성을 확보해야 한다. 검색 목적지를 드러내는 제품은 이러한 설명을 뒷받침할 수 있지만, 어떤 정보가 그 경로에 속하는지는 여전히 조직이 결정해야 한다.
에이전트를 위해 웹을 검색하는 것은 누구인가? 구매자에게 충분한 답변에는 운영 주체, 관련 계약, 전송되는 정보의 범위가 포함된다. 널리 알려진 모델의 이름만 제시해서는 이 답변의 검색 부분이 완성되지 않는다.
묶음형 검색은 편의성을 제공하지만, 분리된 검색은 책임성을 더한다
묶음형 검색의 가장 강력한 장점은 편의성이다. 개발자는 검색의 모든 부분을 조립하지 않아도 지원되는 도구 인터페이스를 얻는다. 조직은 요구사항이 제공업체의 서비스 및 문서화된 동작과 부합할 경우 이 방식을 선호할 수 있다.
Anthropic의 웹 검색 도구는 통합 방식의 사례를 보여준다. Claude가 검색 시점을 결정하고, 서비스가 검색을 실행하며, 최종 응답에는 인용이 포함된다. 문서에는 도메인 제어와 서로 다른 도구 버전도 설명되어 있다.
이러한 기능이 중요한 이유는 구성 가능한 검색이 독립형 게이트웨이만의 특징은 아니기 때문이다. 고객은 검색 동작에 대한 제어와 검색 공급업체에 대한 제어를 구분해야 한다. 제공업체는 기반 서비스를 운영하는 책임을 유지하면서도 유용한 제한 기능을 제공할 수 있다.
핵심 선택은 누가 검색 결정을 소유하고, 이를 유지하는 데 필요한 업무를 맡는가다.
Otari의 제안은 그러한 소유권을 원하는 팀에 매력적이다. 그러나 독립성은 묶음형 서비스가 흡수하거나 단순화하는 책임을 수반한다. 누군가는 자격 증명을 관리하고, 서비스 동작을 평가하며, 장애를 조사하고, 에이전트와 검색 도구 사이의 작동 관계를 유지해야 한다.
Ollama는 또 다른 유용한 비교 대상이다. 호스팅 웹 검색 문서는 ollama.com/api/web_search로 이루어지는 인증된 요청을 명시한다. 응답에는 페이지 제목, 주소, 콘텐츠 스니펫을 포함한 결과가 들어간다.
이 사례는 제한적이지만 중요한 점을 보여준다. 로컬 모델을 사용한다고 해서 그 웹 검색까지 로컬에 머무르는 것은 아니다. 문서화된 검색 요청은 호스팅 서비스에 도달한다. 고객은 처리 위치를 평가할 때 추론, 검색, 페이지 검색을 각각 살펴야 한다.
이는 호스팅 검색이 본질적으로 부적합하다는 증거가 아니다. 서비스 약관, 동작, 신뢰성이 조직의 요구를 충족한다면 호스팅 서비스는 수용 가능한 선택이 될 수 있다. 문제는 하나의 아키텍처 선택이 다른 모든 구성 요소까지 자동으로 결정한다고 가정하는 데 있다.
같은 원칙은 답변 품질에도 적용된다. 검색 서비스를 바꾸면 모델이 이용할 수 있는 근거가 바뀐다. 모델과 검색을 동시에 바꾸는 평가는 어떤 변화가 결과를 개선하거나 악화했는지 쉽게 설명할 수 없다.
이 변수들을 분리하면 더 유익한 비교가 가능하다. 팀은 검색을 살피는 동안 모델을 고정하고, 종합 과정을 살피는 동안 근거를 고정할 수 있다. 이런 평가에도 신중한 설계가 필요하지만, 전체 애플리케이션을 분리할 수 없는 블랙박스로 취급하는 일은 피할 수 있다.
따라서 Otari 웹 검색 평가는 팀 자체의 작업에서 시작해야 한다. 공개 문서 조회, 최근 기업 조사, 전문 기술 탐색에는 서로 다른 근거가 필요할 수 있다. 하나의 검색 서비스가 최고라는 보편적 주장은 개별 워크로드를 넘어서는 증거를 필요로 한다.
Mozilla AI의 발표에는 그러한 승자를 입증하는 독립적인 비교 연구가 없다. 더 타당한 해석은 고객이 이 종속성을 선택하고 시험할 수 있어야 한다는 것이다. 이는 검색 엔진의 입증된 순위가 아니라 제어와 평가를 위한 주장이다.
부담은 두 접근법 모두에 있다. 묶음형 제공업체는 구매자가 평가할 수 있을 만큼 검색 방식을 명확히 설명해야 한다. 독립형 인프라는 클라이언트, 모델, 도구 인터페이스가 변해도 추가 제어가 계속 사용 가능한지 보여줘야 한다.
Otari 웹 검색은 클라이언트의 기대를 유지하는 데 달려 있다
구성 가능한 검색 서비스는 에이전트가 이를 올바르게 사용할 수 있을 때만 도움이 된다. 애플리케이션은 링크 목록 이상을 기대한다. 이들은 인식 가능한 도구 응답, 오류 동작, 작업을 계속할 수 있을 만큼 충분한 출처 정보에 의존한다.
Otari의 검색 가로채기 문서는 가로채기가 활성화된 경우 지원되는 제공업체 명칭의 검색 선언을 인계받는 방식을 설명한다. 가로채기란 그렇지 않으면 제공업체의 도구로 전달될 요청을 처리하는 것을 뜻한다. 문서는 이 동작을 제공업체 고유 요청을 전달하는 방식과 구분한다.
또한 검색 비활성화, 결과 제한, 도메인 범위 축소를 포함한 워크스페이스 제한 사항도 설명합니다. 문서는 번들로 제공되는 SearXNG 설정이 지속적인 사용 시 속도 제한이 적용된다고 경고합니다. 이 경고는 짧은 데모가 아니라 프로덕션 준비 상태를 평가할 때 중요합니다.
인터페이스를 유지하면 통합 작업은 줄어들지만, 동일한 동작이 보장되는 것은 아닙니다.
클라이언트는 서로 다른 근거를 받으면서도 응답을 수용할 수 있습니다. 또한 성공적인 조회는 올바르게 처리하면서도 서비스를 사용할 수 없을 때는 부적절하게 반응할 수 있습니다. 따라서 호환성은 일반적인 작동뿐 아니라 이를 중단시키는 상황까지 포괄해야 합니다.
가상의 코딩 작업은 그 차이를 분명히 보여 줍니다. 한 어시스턴트가 마이그레이션 가이드를 검색하고, 결과를 읽은 뒤 코드 변경을 제안합니다. 유용한 평가는 검색된 가이드가 관련 소프트웨어 버전과 일치하고 제안된 변경을 뒷받침하는지 묻습니다.
검색 결과가 없을 때도 동일한 작업은 이해 가능해야 합니다. 누락된 근거를 명확히 보고하는 에이전트는 답을 즉흥적으로 만들어내는 에이전트와 다르게 행동합니다. 게이트웨이의 응답 형식도 중요하지만, 실패를 해석하는 클라이언트의 방식도 중요합니다.
바로 이 지점에서 답변의 유창성만을 기준으로 한 비교는 오해를 부를 수 있습니다. 매끄러운 설명은 빈약한 근거를 감출 수 있습니다. 한계를 식별하는 다소 덜 매끄러운 응답이 중요한 기술적 의사결정에는 더 유용할 수 있습니다.
Otari의 검색 구성은 이름이 지정된 검색 인스턴스와 기본 선택 항목을 문서화합니다. 또한 공급자별 설정과 자격 증명 요구 사항도 설명합니다. 이러한 세부 사항은 검색 독립성이 프롬프트에 표현된 선호에 그치는 것이 아니라 운영 구성임을 보여 줍니다.
플랫폼 팀에게 구성은 익숙한 유지보수 질문을 가져옵니다. 누가 기본값을 변경할 수 있는가? 변경 사항은 서로 다른 워크스페이스에 어떻게 반영되는가? 요청이 의도한 서비스를 사용했다는 것은 어떤 근거로 입증되는가? 이 답은 일반적인 조직 활동 속에서도 통제권이 유지되는지를 결정합니다.
설정이 존재한다고 해서 그것이 효과적인 정책이 되는 것은 아닙니다. 평가는 허용된 예외를 포함해 실제 배포 구성에서 어떤 일이 일어나는지 확인해야 합니다. 그렇지 않으면 선택 가능한 검색에 대한 데모가 모든 프로덕션 요청에 대한 보증으로 오인될 위험이 있습니다.
애플리케이션에 외부 정보에 도달하는 방식이 여러 개 있는 경우, 이 구분은 특히 중요해집니다. 검색 도구, 페이지 가져오기 도구, 브라우저는 서로 다른 경로를 나타낼 수 있습니다. 하나의 경로를 통제한다고 해서 모든 경로를 통제하는 것은 아닙니다.
이 관찰은 Otari에 특정 우회 경로가 있다는 결론이 아니라 아키텍처상 고려 사항입니다. 구매자는 자신들의 클라이언트 및 활성화된 도구와 일치하는 범위의 근거를 요청해야 합니다. “모든 에이전트 트래픽”과 같은 포괄적 표현에는 검색 가로채기 성공 사례보다 더 폭넓은 검증이 필요합니다.
이 메커니즘은 라우팅 결정을 모델의 판단 밖에 둔다는 점에서 유망합니다. 실질적 가치는 주변 애플리케이션이 그 통제된 경로를 일관되게 사용하는지에 달려 있습니다. 평가는 예상 경로가 실패하는 순간을 포함해 전체 작업 과정을 따라가야 합니다.
자체 호스팅은 의존성을 없애지 않고 책임만 바꾼다
검색 중개자를 직접 운영한다고 해서 독립적인 웹 인덱스를 운영하는 것은 아닙니다.
SearXNG의 메타검색 아키텍처는 다른 검색 엔진의 결과를 집계합니다. 이는 자체 호스팅의 의미를 명확히 합니다. 조직은 집계 서비스를 운영할 수 있지만, 결과에 대해서는 여전히 업스트림 검색 엔진에 의존합니다.
SearXNG를 사용하는 Otari 배포에서는 이 구분이 과장된 개인정보 보호 주장을 막아 줍니다. 운영자는 자신의 인스턴스를 통제하지만, 해당 인스턴스에 구성된 업스트림 관계 역시 중요합니다. 완전한 평가는 조직의 첫 번째 서버를 넘어 쿼리를 추적합니다.
이는 더 넓은 메시지를 검증하는 데 유용한 회의적 기준입니다. 자체 호스팅이 완전한 독립성으로 제시된다면 메타검색은 그 약속을 복잡하게 만듭니다. 정의된 구성 요소에 대한 통제로 제시된다면 주장은 더 제한적이지만 평가하기 쉬워집니다.
동일한 원칙은 비용 비교에도 적용되어야 합니다. 번들 검색 비용을 없앤다고 검색 운영에 필요한 작업까지 사라지는 것은 아닙니다. 쿼리당 청구서에 드러나지 않더라도 인프라, 유지보수, 장애 대응, 인력의 관심은 평가에 포함되어야 합니다.
여기에는 자체 호스팅이 항상 더 저렴하다고 단정할 근거가 없습니다. 관련 비교는 워크로드, 서비스 요구 사항, 조직의 기존 역량에 따라 달라집니다. 이미 관련 인프라를 운영하는 팀은 그러한 전문성이 없는 팀과 다른 결정을 내리게 됩니다.
자격 증명 통제 역시 정확하게 해석해야 합니다. 자격 증명을 에이전트로부터 분리하면 하나의 노출 경로는 줄어듭니다. 그러나 해당 자격 증명을 보유한 서비스는 여전히 적절한 관리와 접근 통제가 필요한 민감한 시스템입니다.
검색 기록은 에이전트가 특정 답변을 내놓은 이유를 설명하는 데 도움이 될 수 있지만, 민감한 쿼리 텍스트를 보존할 수도 있습니다. 책임성을 추구하는 조직은 누가 해당 기록을 열람할 수 있는지, 그리고 얼마나 오래 유용한지를 결정해야 합니다.
따라서 더 큰 가시성은 그 자체로 거버넌스 과제를 만듭니다. 상세한 기록이 모든 맥락에서 자동으로 더 나은 것은 아닙니다. 목표는 조사를 위한 충분한 근거를 확보하되, 기록에 담긴 정보에 적합한 처리 규칙을 적용하는 것입니다.
도메인 제한 역시 가치가 제한적입니다. 이는 적격 출처의 범위를 제한할 수 있습니다. 하지만 허용된 도메인의 모든 페이지가 특정 작업에 대해 정확하고 최신이며 적절하다는 것을 보장하지는 않습니다.
검색 공급자를 선택한다고 해서 어시스턴트의 동작을 전환하도록 설계된 악성 콘텐츠인 프롬프트 인젝션 문제가 해결되는 것도 아닙니다. 검색된 페이지는 여전히 외부 입력입니다. 에이전트는 이를 자신의 작업에 대한 권한 있는 지시가 아니라 평가해야 할 근거로 다뤄야 합니다.
이러한 한계가 독립적 검색의 필요성을 무효화하는 것은 아닙니다. 다만 그 근거가 뒷받침할 수 있는 범위를 규정합니다. 의존성을 선택하면 조직은 판단을 행사할 자리를 얻게 되지만, 그 판단이 옳을 것까지 보장되지는 않습니다.
신뢰할 수 있는 결과는 식별 가능한 선택에 대한 더 큰 책임성입니다. 구매자는 왜 특정 서비스가 선택되었는지, 어떤 가정이 이를 뒷받침하는지, 무엇이 변경을 촉발할지를 물을 수 있습니다. 선택한 답이 관리형 공급자인 경우에도 이러한 질문은 여전히 가치가 있습니다.
Otari 웹 검색 배포는 이러한 구체적 책임을 기준으로 판단해야 합니다. 발표만으로는 더 뛰어난 검색, 보편적 호환성, 또는 완전한 개인정보 보호 결과가 입증되지 않습니다. 팀의 실제 환경에서 나온 근거가 그러한 결론을 뒷받침해야 합니다.
호환성, 비교 근거, 공급자 공개를 지켜봐야 한다
다음 보도 기간은 더 개방적인 AI 스택에 대한 약속이 아니라 관찰 가능한 변화에 초점을 맞춰야 합니다. 2026년 말과 2027년 초까지 유용한 신호는 독립적 검색이 운영하기 쉽고 평가하기도 쉬워지는지에 관한 것입니다.
가장 강력한 근거는 실패와 변경을 포함한 실제 작업 중에도 신뢰할 수 있는 통제를 보여 줄 것입니다.
첫 번째 신호는 팀이 실제로 사용하는 클라이언트 및 도구 인터페이스에 대한 공개된 호환성 근거입니다. 유용한 릴리스는 테스트된 동작, 지원 버전, 알려진 제한 사항을 식별할 것입니다. 재현 가능한 예시는 고객이 검색을 변경하면서도 애플리케이션을 유지할 수 있다는 근거를 강화합니다.
반대로 클라이언트별 우회책이 반복된다면 독립성에 대한 실질적 주장은 약화됩니다. 이론적으로 교체 가능한 서비스라도 각각의 교체에 상당한 애플리케이션 수리가 필요하다면 제공하는 자유는 제한적입니다. 주변 소프트웨어가 발전하는 과정에서도 호환성은 이해 가능한 상태로 유지되어야 합니다.
두 번째 신호는 통제된 워크로드를 활용한 비교 평가입니다. 모델과 작업을 일정하게 유지한 뒤 검색 관련성, 최신성, 응답 시간, 실패, 총 운영 노력을 살펴봐야 합니다. 결과는 번들 검색이 여전히 더 적합한 경우를 포함해 각 구성이 효과적인 지점을 식별해야 합니다.
설득력 있는 평가는 독자가 그 범위를 이해할 수 있도록 충분한 세부 정보를 공개할 것입니다. 문서 조회 결과가 모든 조사 작업에 대한 주장으로 확대되어서는 안 됩니다. 선택적인 이점에 대한 근거가 설명 없는 전반적 우월성 선언보다 더 신뢰할 수 있습니다.
세 번째 신호는 번들 공급자의 더 명확한 공개 또는 추가적인 공급자 선택권입니다. 더 명시적인 문서는 고객이 다른 중개자를 도입하지 않고도 기존 서비스를 평가하는 데 도움이 됩니다. 공급자가 지원하는 선택권은 고객이 주로 독립성을 원하는지, 아니면 단지 더 명확한 통제를 원하는지도 검증할 수 있습니다.
이러한 발전은 Otari의 경쟁적 위치를 바꾸면서 Mozilla AI의 근본적 주장을 강화할 것입니다. 구매자가 다른 곳에서 그 선택권을 행사하더라도 검색은 더 눈에 띄는 구매 결정이 될 것입니다. 지속되는 쟁점은 누가 그 결정을 내리고 설명할 수 있는가입니다.
누가 당신의 에이전트를 위해 웹을 검색하는가? 이러한 신호가 발전함에 따라 그 답은 더 구체적이어야 합니다. 모델 이름에서 도출한 가정에 의존하기보다 실제 정보 경로와 그 사용을 뒷받침하는 근거를 식별해야 합니다.
에이전트 워크플로를 확장하기 전에 프롬프트에서 최종 답변까지 대표적인 작업 하나를 검토하십시오. 외부로 나가는 쿼리, 수신자, 반환된 출처, 결론을 뒷받침하는 근거를 식별하십시오. 그런 다음 이 구성이 작업의 민감도와 목적에 부합하는지 물어보십시오. 문서화된 동작이 이러한 요구를 충족한다면 번들 검색을 유지하십시오. 공급자 선택권, 운영 통제 또는 더 명확한 기록이 구체적 요구 사항을 해결한다면 별도의 검색 서비스를 평가하십시오. 비공개 지식과 공개 조사를 결합하는 작업에서는 모든 조회를 동일하게 취급하지 말고 그 경계를 명시적으로 검토하십시오. 유용한 다음 단계는 팀이 설명할 수 있는 결정입니다. 이 에이전트는 어떤 검색 서비스를 사용해야 하며, 그 선택을 정당화하는 근거는 무엇인가?
