Azure AI 검색 에이전트 기반 검색

참고

일부 에이전트 검색 기능은 프로그래밍 방식 액세스를 통해 2026-04-01 REST API 버전에서 일반적으로 사용할 수 있습니다. Azure 포털 및 Microsoft Foundry 포털은 모든 에이전트 검색 기능에 대한 미리 보기 전용 액세스를 계속 제공합니다. 일반적으로 사용할 수 있는 항목과 미리 보기로 남아 있는 항목에 대한 분석을 비롯한 마이그레이션 지침은 에이전트 검색 코드를 최신 버전으로 마이그레이션을 참조하세요.

Azure AI 검색에서 에이전트 검색 은 챗봇 및 Copilot 앱의 사용자나 에이전트가 제기하는 복잡한 질문을 처리하기 위해 설계된 멀티 쿼리 파이프라인입니다. RAG( 검색 보강 생성 ) 패턴 및 에이전트 간 워크플로를 위한 것입니다.

다음과 같은 작업을 수행합니다.

  • LLM(큰 언어 모델)을 사용하여 복잡한 쿼리를 더 작고 집중된 하위 쿼리로 분할하여 인덱싱된 콘텐츠에 대한 더 나은 범위를 제공합니다. 하위 쿼리에는 추가 컨텍스트에 대한 채팅 기록이 포함될 수 있습니다.

  • 하위 쿼리를 병렬로 실행합니다. 각 하위 쿼리는 의미적으로 재정렬되어 가장 관련성이 높은 일치 항목을 우선시합니다.

  • 최상의 결과를 LLM이 독점 콘텐츠로 답변을 생성하는 데 사용할 수 있는 통합 응답으로 결합합니다.

  • 응답은 모듈식이지만 쿼리 계획 및 원본 문서도 포함하는 방법에 대해 포괄적입니다. 검색 결과만 접지 데이터로 사용하거나 LLM을 호출하여 답변을 작성하도록 선택할 수 있습니다.

이 고성능 파이프라인을 사용하면 복잡한 질문에 신속하게 답변할 수 있는 기능을 통해 채팅 애플리케이션에 대한 고품질 접지 데이터(또는 답변)를 생성할 수 있습니다.

프로그램 방식으로는 최신 안정 버전(2026-04-01)과 미리 보기 버전(2025-11-01-preview) REST API에서 지식 기반 개체 및 이에 상응하는 기능이 Azure SDK 패키지를 통해 지원됩니다. 지식 베이스의 검색 응답은 다른 에이전트와 채팅 앱에서 다운스트림으로 활용할 수 있도록 설계되었습니다.

에이전트 검색을 사용하는 이유

에이전트 검색에는 두 가지 사용 사례가 있습니다. 첫째, Microsoft Foundry(신규) 포털에서 Foundry IQ 환경의 기반이 됩니다. Microsoft Foundry의 에이전트 솔루션에 대한 기술 계층을 제공합니다. 둘째, Azure AI 검색 API를 사용하여 만드는 사용자 지정 에이전트 솔루션의 기초입니다.

에이전트 및 앱에 더 어려운 질문에 답변하고 채팅 컨텍스트 및 독점 콘텐츠를 활용하기 위해 가장 관련성이 큰 콘텐츠를 제공하려는 경우 에이전트 검색을 사용해야 합니다.

에이전틱 측면은 사용자가 제공하는 지원되는 대규모 언어 모델(LLM)이 쿼리 계획 처리 과정에서 수행하는 추론 단계입니다. LLM은 전체 채팅 스레드를 분석하여 기본 정보 필요를 식별합니다. LLM은 단일 catch-all 쿼리 대신 사용자 질문, 채팅 기록 및 요청에 대한 매개 변수를 기반으로 복합 질문을 집중 하위 쿼리로 나눕니다. 하위 쿼리는 Azure AI 검색 인덱싱된 문서(일반 텍스트 및 벡터)를 대상으로 합니다. 이 하이브리드 접근 방식을 사용하면 키워드 일치와 의미 체계 유사성을 한 번에 모두 표시하여 회수가 크게 향상됩니다.

검색 구성 요소는 하위 쿼리를 동시에 실행하고, 결과를 병합하고, 결과를 의미상 순위 지정하고, 다음 대화 턴에 대한 접지 데이터, 원본 콘텐츠를 검사할 수 있도록 데이터를 참조하고, 쿼리 실행 단계를 보여 주는 활동 계획을 포함하는 세 부분으로 구성된 응답을 반환하는 기능입니다.

쿼리 확장 및 병렬 실행과 검색 응답은 RAG(생성 AI) 애플리케이션에 가장 적합한 에이전트 검색의 주요 기능입니다.

에이전트 검색이 암시적 컨텍스트 및 의도적인 오타를 처리하는 방법을 보여 주는 복잡한 쿼리의 다이어그램입니다.

에이전트 검색은 쿼리 처리에 대기 시간을 추가하지만 다음 기능을 추가하여 이를 만회합니다.

  • 채팅 기록을 검색 파이프라인에 대한 입력으로 읽습니다.
  • 여러 "asks"가 포함된 복잡한 쿼리를 구성 요소 부분으로 분해합니다. 예를 들어 " 공항 교통편이 있는 해변 근처의 호텔을 찾으시면 채식 레스토랑까지 도보 거리에 있습니다."
  • 동의어 맵(선택 사항) 및 LLM이 생성한 의역을 사용하여 원래 쿼리를 여러 하위 쿼리로 다시 작성합니다.
  • 맞춤법 오류를 수정합니다.
  • 모든 하위 쿼리를 동시에 실행합니다.
  • 단일 문자열로 통합된 결과를 출력합니다. 또는 솔루션에 대한 응답의 일부를 추출할 수 있습니다. 쿼리 실행 및 참조 데이터에 대한 메타데이터가 응답에 포함됩니다.

에이전트 검색은 각 하위 쿼리에 대해 전체 쿼리 처리 파이프라인을 여러 번 호출하지만, 이를 병렬로 수행하여 합리적인 사용자 환경에 필요한 효율성과 성능을 유지합니다.

참고

쿼리 계획에 LLM을 포함하면 쿼리 파이프라인에 대기 시간이 추가됩니다. gpt-4o-mini와 같은 더 빠른 모델을 사용하고 메시지 스레드를 요약하여 효과를 완화할 수 있습니다. LLM 처리를 제한하는 속성을 설정하여 대기 시간 및 비용을 최소화할 수 있습니다. 텍스트 및 하이브리드 검색 및 사용자 고유의 쿼리 계획 논리에 대한 LLM 처리를 모두 제외할 수도 있습니다.

아키텍처 및 워크플로

에이전트 검색은 LLM을 사용하여 복잡한 쿼리를 지능적으로 분석하는 대화형 검색 환경을 위해 설계되었습니다. 시스템은 여러 Azure 서비스를 조정하여 포괄적인 검색 결과를 제공합니다.

예제 쿼리를 사용하는 에이전트 검색 워크플로의 다이어그램입니다.

작동 방식

에이전트 검색 프로세스는 다음과 같이 작동합니다.

  1. 워크플로 시작: 애플리케이션은 쿼리 및 대화 기록을 제공하는 검색 작업을 사용하여 기술 자료를 호출합니다.

  2. 쿼리 계획: 기술 자료는 쿼리 및 대화 기록을 LLM으로 보내 컨텍스트를 분석하고 복잡한 질문을 포커스가 있는 하위 쿼리로 나눕니다. 이 단계는 자동화되며 사용자 지정할 수 없습니다.

  3. 쿼리 실행: 기술 자료는 하위 쿼리를 기술 원본으로 보냅니다. 모든 하위 쿼리는 동시에 실행되며 키워드, 벡터 및 하이브리드 검색일 수 있습니다. 각 하위 쿼리는 의미 체계 재전송을 거쳐 가장 관련성이 큰 일치 항목을 찾습니다. 참조는 인용을 위해 추출 및 보존됩니다.

  4. 결과 합성: 시스템은 병합된 콘텐츠, 원본 참조 및 실행 세부 정보의 세 부분으로 모든 결과를 통합 응답으로 결합합니다.

검색 인덱스는 쿼리 실행 및 쿼리 실행 중에 발생하는 모든 최적화를 결정합니다. 특히 인덱스에 검색 가능한 텍스트 및 벡터 필드가 포함된 경우 하이브리드 쿼리가 실행됩니다. 검색 가능한 필드만 벡터 필드인 경우 순수 벡터 검색만 사용됩니다. 인덱스 의미 체계 구성과 선택적 점수 매기기 프로필, 동의어 맵, 분석기 및 normalizer(필터를 추가하는 경우)는 모두 쿼리 실행 중에 사용됩니다. 의미 체계 구성 및 점수 매기기 프로필에 대한 명명된 기본값이 있어야 합니다.

필수 구성 요소

구성 요소 서비스 역할
Llm Azure OpenAI 대화 컨텍스트에서 하위 쿼리를 만들고 나중에 응답 생성을 위해 접지 데이터를 사용합니다.
기술 자료 Azure AI 검색 파이프라인을 오케스트레이션하고 LLM에 연결하고 쿼리 매개 변수를 관리합니다.
기술 자료 Azure AI 검색 기술 자료 사용량과 관련된 속성으로 검색 인덱스를 래핑합니다.
검색 인덱스 Azure AI 검색 의미 체계 구성을 사용하여 검색 가능한 콘텐츠(텍스트 및 벡터)를 저장합니다.
의미 체계 순위 Azure AI 검색 에이전트 검색 파이프라인에서 내부적으로 관련성에 대한 결과를 재정렬하는 데 사용됨(L2 재정렬)

통합 요구 사항

애플리케이션은 기술 자료를 호출하고 응답을 처리하여 파이프라인을 구동합니다. 파이프라인은 대화 인터페이스에서 응답 생성을 위해 LLM에 전달하는 기초 데이터를 반환합니다. 구현 세부 정보는 자습서: 엔드 투 엔드 에이전트 검색 솔루션 빌드를 참조하세요.

참고

쿼리 계획에는 gpt-4o, gpt-4.1 및 gpt-5 시리즈 모델만 지원됩니다. 최종 응답 생성을 위해 모든 모델을 사용할 수 있습니다.

가용성 및 가격 책정

에이전트 검색은 일부 지역에서 사용할 수 있습니다. 또한 기술 원본 및 기술 자료에는 가격 책정 계층 및 검색 추론 노력에 따라 달라지는 최대 한 도가 있습니다.

결제

에이전트 검색은 다음 두 서비스에서 요금이 발생합니다.

  • Azure AI 검색는 하위 쿼리 실행 및 의미 순위 과정에서 소비된 검색 토큰에 대해 요금을 청구합니다. 무료 플랜(기본값)은 월별 토큰 허용량을 제공합니다. 표준 요금제는 무료 수당을 사용한 후 종량제 가격을 사용하도록 설정합니다. 자세한 내용은 에이전트릭 리트리벌 청구 사용 설정 또는 해제를 참조하세요.

  • Azure OPENAI LLM 기반 쿼리 계획 및 answer 합성 사용되는 입력 및 출력 토큰에 대한 요금을 청구합니다. 가격 책정은 항상 종량제이며 기술 자료에 할당하는 모델을 기반으로 합니다. 요금은 Azure OpenAI 청구서에 표시됩니다. 요금은 Azure OpenAI 가격 책정 참조하세요.

다음 표에서는 클래식 단일 쿼리 파이프라인과 에이전트 검색 다중 쿼리 파이프라인 간의 청구를 비교합니다. 클래식 파이프라인에서 청구 가능한 구성 요소는 semantic ranker입니다.

특성 클래식 파이프라인 에이전트 검색
단위 쿼리 기반 토큰 기반
단위당 비용 쿼리당 균일한 비용 토큰당 가변 비용(추론 노력에 따라 다름)
비용 예측 쿼리 수 예측 토큰 사용량 예측
무료 수당 월별 무료 쿼리 허용 월별 무료 토큰 허용

예: 비용 예측

이 예제는 쿼리 계획 및 쿼리 실행에 대한 비용 예측 프로세스를 보여 주지만 응답 합성에는 도움이 되지 않습니다. 비용은 더 낮을 수 있습니다. 현재 요금은 Azure AI 검색 가격 책정Azure OpenAI 가격 책정 참조하세요.

쿼리 계획 비용을 Azure OpenAI에서 종량제로 예측하려면 gpt-4o-mini를 가정해 보겠습니다.

  • 입력 토큰 100만 개에 대해 15센트
  • 100만 개의 출력 토큰에 대해 60센트.
  • 평균적인 채팅 대화 크기에는 2,000개의 입력 토큰이 사용됩니다.
  • 출력 계획의 평균 크기에 대해 350개의 토큰을 사용합니다.

쿼리 실행에 대한 예상 청구 비용

에이전트 검색 토큰 수를 예측하려면 먼저 인덱스의 평균 문서가 어떻게 표시되는지 파악합니다. 예를 들어 근사치를 구할 수 있습니다.

  • 10,000개의 청크- 각 청크는 PDF의 1~2개 단락입니다.
  • 청크당 500개의 토큰.
  • 각 하위 쿼리는 최대 50개의 청크를 다시 랭킹합니다.
  • 평균적으로 쿼리 계획당 세 개의 하위 쿼리가 있습니다.

실행 가격 계산

  1. 계획당 3개의 하위 쿼리를 사용하여 2,000개의 에이전트 검색을 만든다고 가정합니다. 이를 통해 총 쿼리는 약 6,000개입니다.

  2. 하위 쿼리당 50개의 청크를 재정렬합니다 (총 청크 300,000개).

  3. 평균 청크는 500개의 토큰이므로 재정렬을 위한 총 토큰은 1억 5천만 개입니다.

  4. 토큰당 0.022라는 가상 가격을 감안할 때 $ 3.30은 미국 달러로 재전송하는 총 비용입니다.

  5. 쿼리 계획 비용으로 이동: 2,000개의 입력 토큰에 2,000개의 에이전트 검색을 곱한 값은 총 60센트에 대해 4백만 개의 입력 토큰과 같습니다.

  6. 평균 350개의 토큰을 기준으로 출력 비용을 예측합니다. 350개와 2,000개의 에이전트 검색을 곱하면 총 42센트에 대해 총 700,000개의 출력 토큰을 얻을 수 있습니다.

이 모든 것을 종합하면, Azure AI 검색에서 대리인 검색 비용으로 약 $3.30를 지불하며, Azure OpenAI에서는 입력 토큰에 대해 60센트, 출력 토큰에 대해 42센트를 지불하여 쿼리 계획 비용 총합이 $1.02가 됩니다. 전체 실행에 대한 결합 비용은 $4.32입니다.

비용 제어를 위한 팁

  • 응답에서 활동 로그를 검토하여 사용된 원본 및 매개 변수에 대해 실행된 쿼리를 확인합니다. 인덱스에 대해 해당 쿼리를 다시 실행하고 공용 토큰 변환기를 사용하여 토큰을 예측하고 API에서 보고한 사용량과 비교할 수 있습니다. 그러나 쿼리 또는 응답의 정확한 재구성은 보장되지 않습니다. 요소에는 공용 웹 데이터 또는 쿼리 재현에 영향을 줄 수 있는 사용자 ID에 근거한 원격 SharePoint 기술 원본과 같은 기술 원본 유형이 포함됩니다.

  • 지식 원본(인덱스) 수를 줄입니다. 콘텐츠를 통합하면 팬아웃 및 토큰 볼륨이 줄어들 수 있습니다.

  • 쿼리 계획 및 쿼리 확장(반복 검색)을 수행하는 동안 LLM 사용량을 줄이기 위한 추론 노력을 낮춥니다.

  • 더 적은 수의 원본 및 문서(예: 큐레이팅된 요약 또는 테이블)로 가장 관련성이 큰 정보를 찾을 수 있도록 콘텐츠를 구성합니다.

시작하는 방법

에이전트 검색 솔루션을 만들려면 Azure 포털, REST API 또는 기능을 제공하는 Azure SDK 패키지를 사용할 수 있습니다.

다음 단계