OpenAI Responses API의 Multi-Agent 기능을 테스트하기: RAG의 오답을 6가지 관점에서 병렬 분석하기

SoftBank의 CHEN입니다. 평소에는 데이터 구조화 도구인 「TASUKI Annotation」의 기술 연구 및 전사 RAG 기반 구축을 담당하고 있습니다. 본 기사에서는 OpenAI가 Responses API에 추가한 **Multi-Agent 기능 (Beta)**를 사용하여, RAG 운영의 정석적인 태스크인 「오답 원인 분석」을 병렬화하는 방법을 소개합니다.

TL;DR

• 모델이 서브 에이전트 (Sub-agent)를 자동으로 생성하여 병렬로 작업하고 결과를 통합한다. 오케스트레이션 (Orchestration) 코드는 필요 없다. multi_agent: {"enabled": true}를 추가하기만 하면 된다.
• RAG의 오답 1건을 「원문 문서 · 구조화 · 청크 분할 (Chunking) · 검색 · 생성 · 채점」의 6가지 관점에서 동시에 심층 분석시킨 결과, 1회의 API 호출과 약 60초 만에 관점별 검증 리포트 6개와 진정한 원인에 대한 통합 결론이 반환되었다.
• 「독립적이고 무거운 분석을 병렬로 실행하여 결론을 통합하는」 태스크에 적합하다.

1. Multi-Agent 기능이란

Responses API에 multi_agent 파라미터를 추가하면, 1회의 API 호출 과정 내에서 리더 역할을 하는 에이전트가 서브 에이전트를 생성하여 태스크를 분담, 병렬 실행 및 통합합니다 (GPT-5.6 계열에서 이용 가능). 기존처럼 Agents SDK나 LangGraph를 사용하여 에이전트의 연결이나 제어 흐름 (Control flow)을 작성할 필요가 없습니다.

OpenAI가 제시하는 장점은 3가지입니다:

• 병렬 실행 (Parallel execution) — 독립된 태스크를 동시에 진행하여 실행 시간을 단축
• 컨텍스트 분리 (Context separation) — 각 서브 에이전트가 자신의 태스크에 집중할 수 있어 간섭이 줄어들고 정밀도가 향상됨
• 모델 주도 조정 (Model-led orchestration) — 생성, 대기, 통합을 모델이 수행하므로 애플리케이션 측의 조정 코드가 불필요

권장 유스케이스는 「복수 문서 비교」, 「장애 원인의 병렬 조사」, 「코드베이스의 병렬 탐색」 등, 독립적인 워크스트림 (Workstream)으로 분할할 수 있는 태스크입니다.

2. 주제: RAG의 오답을 6가지 관점에서 분석하기

RAG에서 오답이 발생했을 때, 원인은 한 곳에만 있지 않습니다. 원문 문서 → 구조화 → 청크 분할 → 검색 → 생성 → 채점으로 이어지는 파이프라인의 어디에나 잠재되어 있을 수 있으므로, 구분을 위해서는 관점별로 꾸준한 검증이 필요합니다. 각 관점의 검증은 독립적으로 진행될 수 있으며, 이는 Multi-Agent에 딱 맞는 형태입니다.

입력 데이터

오답 케이스 1건과 파이프라인 각 계층의 증거를 텍스트로 전달합니다 (실제 입력은 전체 약 2,500자).

■ 질문: 「관리직의 국내 출장 숙박비 상한액은 얼마입니까?」
■ 기대 답변: 「1박에 15,000엔입니다 (출장 여비 규정 2025년 4월 개정)」
■ 봇의 답변: 「국내 출장 숙박비 상한액은 1박에 12,000엔입니다」
...

※ 이 케이스는 검증용으로 작성된 모의 데이터입니다. 실제 규정 QA를 모방하여 「주원인 = 청크 분단, 부원인 = 생성 모델의 값 전용, 다른 계층은 정상」이라는 다층적인 원인을 의도적으로 심어 두었습니다. 모델이 이를 올바르게 구분해낼 수 있는지가 포인트입니다.

요청 (Request)

분석 지시에 「관점별로 서브 에이전트를 통해 병렬로」라는 문장을 추가하고, multi_agent를 활성화하기만 하면 됩니다.

import httpx
task = 케이스 데이터 + """
이 오답 케이스를 다음 6가지 관점에서 각각 독립적으로 검증해 주세요.
...

실행 중에 일어나는 일

리더 에이전트가 태스크를 읽고, 관점별로 6체의 서브 에이전트를 자동으로 생성합니다. 6체는 동일한 증거 세트를 전달받아 각자의 관점에만 집중하여 동시에 검증을 진행합니다. 리더는 모두의 완료를 기다린 후 통합 결론을 정리합니다. 애플리케이션 측에서 하는 일은 일반적인 API 호출 1회뿐입니다.

3. 반환되는 결과물

응답의 output에는 어느 에이전트의 출력인지 나타내는 라벨과 함께 모든 성과물이 들어 있습니다.

• 관점별 검증 리포트 × 6개 (각 서브 에이전트의 출력, 각 약 2,000자 내외)
• 통합 결론 (리더의 출력, 약 300자)

예를 들어 관점 3(청크 분할)의 리포트는 다음과 같이 시작됩니다 (실제 출력에서 발췌):

판정: 주원인 — 256 토큰으로 축소됨에 따라, 동일 조문 및 동일 표의 헤더(Heading)와 '관리직' 행이 서로 다른 청크(Chunk)로 분리되었다. 그 결과, 정답 값을 포함한 청크의 검색 가능성(Retrievability)이 저하되어 생성 컨텍스트(Generation Context)에서 탈락했으므로, 본 건의 주원인으로 판정한다.

각 리포트에는 증거 인용, 반증 검토("chunk-88b 자체에 정보가 남아 있어 top_k=6이라면 취득할 수 있었다" 등), 설정값 수준의 개선안, 검증 실험 절차서까지 포함됩니다. 그리고 리더의 통합 결론(실제 출력 전문):

진인(True Cause): 주원인은 chunk_size 512→256에 의한 표의 분단. 관리직 행이 헤더 정보를 잃어 검색 순위가 6위로 하락하였고, top_k=5에서 탈락함. 부원인은 생성 모델이 답변 보류 지시를 어기고 일반 사원의 12,000엔을 전용(Transferred)한 것. 원문·구조화·채점에는 문제 없음. 인과 체인(Causal Chain): 표 분단 → 정답 청크 순위 하락 → 생성 컨텍스트 결손 → 속성 불일치를 무시하고 오단정. 우선 조치 사항: ① 표 단위의 청크화 및 헤더 상속 (잠정적으로 512로 복구) ② top_k 확대 및 재랭킹(Re-ranking) ③ 질문 속성과 근거 행의 일치 검증을 생성 전 필수화.

설정된 다층적인 원인을 관점별로 명확히 가려낸 후 올바르게 통합하고 있습니다. 이번 실행은 6개 관점의 병렬 분석으로 약 60초, $0.6 정도가 소요되었습니다.

4. 요약

• 사용법: 요청(Request)에 multi_agent 파라미터와 베타 헤더를 추가하고, 프롬프트로 분담 방침을 한마디 전달하기만 하면 됩니다. 분할, 대기, 통합을 위한 코드는 전혀 필요하지 않습니다.
• 적합한 작업: 오답에 대한 다각도 분석처럼, 독립적이고 무거운 검증 작업을 병렬화하여 결론을 통합하는 태스크. 관점이나 증거가 늘어나도 소요 시간은 거의 "가장 무거운 관점 1개 분량" 그대로 유지됩니다.
• 주의사항: 서브 에이전트(Sub-agent)마다 입력 컨텍스트가 복사되므로 토큰 소비량은 증가합니다.

"오답을 하나씩 심층 분석하여 해결한다"라는 RAG 운영의 정석적인 작업이, 코드 0줄의 병렬화로 관점별 풀 뎁스(Full Depth)로 돌아가는 것은 실무 임팩트가 매우 큰 기능입니다. 베타 기간 종료 후 정식 제공이 기대됩니다.

관련 서비스

TASUKI Annotation RAG 데이터 생성 도구는 RAG를 고도화하여 활용할 때 발생하는 과제들을 기술로 지원하는 도구입니다. RAG에 대한 지식이 없더라도 사내 데이터를 활용하여 정밀도 높은 RAG 답변 생성을 간편하게 얻을 수 있습니다.

Discussion