7장이 검색에 스스로를 비추는 거울을 하나 들였다면, 8장은 여럿이 서로를 비추는 자리를 짓는다. 서로 다른 결의 말뭉치를 하나의 파이프라인으로 감당하려는 순간 모든 선택은 타협이 된다. 타협을 그만두고, 각자의 자리에서 뛰어난 전문가들을 세우고, 그들을 조정하는 계층을 두는 일 — 홀로 서는 나무가 아니라 더불어 서는 숲의 구조다.
한 글로벌 제약사의 의학부 팀이 조용한 실험을 했다. 지난 한 해 배포해 온 RAG 기반 연구 어시스턴트 — 임상시험 보고서, 규제 서류, 과학 문헌, 사내 과학 각서를 아우르는 지식 베이스 전체를 검색하는 단일 에이전트 시스템 — 가 그것이 대체한 이전 워크플로보다 정말로 연구자들을 더 잘 섬기고 있는지 알고 싶었다. 실험은 단순했다. 신약 발견 과학자들이 예사로 던지는 복잡한 연구 질문 열 개를 고른다. RAG 시스템이 각각에 답하게 한다. 같은 지식 베이스에 온전히 접근할 수 있는 주제 전문가 세 사람이 각자 독립적으로 답하게 한다. 견주어 본다.
결과는 불편했다. 열 문항 가운데 셋에서 시스템은 옳고 근거도 잘 갖춘 답을 냈다. 넷에서는 부분적으로만 옳은 답을 냈다 — 답의 일부는 붙잡았으나 인간 전문가들이 잡아낸 결정적 미묘함을 놓쳤다. 남은 셋에서는 자신 있게 틀린 답을 냈다. 세 전문가 중 누구라도 당연하게 여겼을 맥락을 놓친 답이었다. 전문가들 사이에서 정답에 대한 합의는 높았다. 시스템은 전문가들이 이미 아는 것에 이르는 속도가 느린 데 그치지 않았다. 전문 연구자들이 본능적으로 결합하는 종류의 정보를 체계적으로 결합하지 못하고 있었다.
사후 분석에서 드러난 진단이 시사적이다. 전문가들에게 어떻게 답에 이르렀는지 물었을 때, 하나같이 비슷한 과정을 이야기했다. 그들은 지식 베이스를 하나의 말뭉치로 검색하지 않았다. 특정한 하위 영역을 특정한 순서로 찾아 읽었다. 먼저 직접 증거를 얻으려 임상시험 보고서를, 다음으로 규제 지형의 맥락을 얻으려 규제 서류를, 그다음 회사 자신의 앞선 해석을 얻으려 사내 과학 각서를, 마지막으로 넓은 과학적 합의를 얻으려 외부 문헌을 읽었다. 이 하위 영역들은 저마다 고유한 관례와 어휘와 불확실성 표현법을 지녔다. 전문가들은 각 영역을 다른 심상 모형으로 읽었다.
반면 RAG 시스템은 말뭉치 전체를 구별 없는 내용으로 다루었다. 모든 종류의 문서에 같은 검색 전략, 같은 청킹, 같은 임베딩 모델, 같은 생성 프롬프트를 적용했다. 구조화된 유효성 데이터와 표준화된 통계 보고를 담은 임상시험 보고서가, 같은 용어가 전혀 다른 함의를 지닐 수 있는 문헌 리뷰와 나란히 회수되었다. 회사 고유의 약어와 진행 중인 프로젝트 참조로 가득한 사내 각서가, 격식 있는 규제 서류와 같은 벡터 공간에 임베딩되었다. 이 모든 문서 유형을 가로지르는 단일 에이전트의 평균적 유능함은 각 유형에 전문화된 검색이 낼 성과보다 크게 못했고, 워크플로를 통해 사실상 전문화된 검색을 수행한 인간 전문가들보다도 크게 못했다.
처방은 구조적이었다. 팀은 시스템을 네 개의 전문 검색 에이전트 — 임상시험 전문가, 규제 전문가, 사내 과학 전문가, 외부 문헌 전문가 — 로 다시 지었다. 각각은 자기 말뭉치의 관례에 맞춰 조율된 자기만의 검색 캐스케이드를 지녔고, 오케스트레이터가 연구 질문마다 하위 질문으로 쪼개어 해당 전문가에게 배정했다. 그다음 오케스트레이터는 전문가들의 응답을 조리 있는 답으로 종합했다. 어느 전문가가 어느 증거를 보탰는지 명시적으로 밝히면서였다. 다시 지은 뒤 석 달, 같은 열 문항으로 후속 평가를 하자 깔끔한 답 여덟, 부분적 둘, 자신 있게 틀린 답 영이 나왔다. 시스템은 사실상 협력하는 네 명의 전문가가 되었다.
멀티 에이전트 RAG는 3부를 닫는 패턴이다. 7장의 에이전틱 패턴 — 성찰, 자기교정, 멀티홉 분해 — 위에 곧바로 서서, 그것을 오케스트레이션의 규율과 결합한다. 7장이 각 검색 에이전트를 스스로 고쳐 나가게 만들었다면, 이 장은 그런 에이전트 여럿을 어느 하나도 홀로는 할 수 없는 일을 하는 체계로 조정한다. 이 장을 마치면 이 책 앞 세 부의 건축적 호(弧)가 완성된다. 검색이 왜 중요한가의 기초에서, 어떻게 잘 검색하는가의 핵심 아키텍처를 지나, 프로덕션급 검색을 가능하게 하는 고급 패턴까지.
이 책이 지금까지 살펴본 모든 검색 아키텍처 — 벡터 검색, 하이브리드 융합, GraphRAG, 자기교정 루프 — 는 하나의 말뭉치 위에서 도는 하나의 파이프라인을 가정한다. 하나의 청킹 전략, 하나의 임베딩 모델, 한 벌의 검색 파라미터, 하나의 생성 프롬프트. 설명하기에 편하고 많은 응용에 충분한 가정이다. 그러나 상당한 부류의 프로덕션 배포에는 구조적으로 불충분하다. 제약사 연구 어시스턴트의 실패는 파이프라인의 어느 개별 부품의 실패가 아니었다. 하나의 파이프라인이 시스템이 검색해야 할 모든 종류의 콘텐츠를 섬길 수 있다는 가정의 실패였다.
전문화의 논거는 이질적인 말뭉치를 다루는 숙련된 사람을 관찰할 때에야 보이는 성질에 기댄다. 문서 유형이 다르면 보답하는 검색 전략도 다르다는 것이다.
표준화된 절 구성, 통계 관례, 일관된 어휘를 지닌 고도로 구조화된 문서다. 절 경계를 존중하는 청킹, 생의학 텍스트로 훈련된 임베딩, 이를 서사가 아니라 증거로 다루는 검색 프롬프트에 보답한다.
독특한 논증 구조와 옮겨 다니는 개념적 강조를 지닌 비구조 산문이다. 서사를 아는 청킹, 범용 과학 임베딩, 증거의 열거가 아니라 개념적 포괄을 붙잡는 검색에 보답한다.
짧고 밀도 높으며 회사 고유의 약칭과 진행 중인 프로젝트 참조로 가득하다. 작은 청크 크기, 사내 용어로 미세조정된 임베딩, 포괄성보다 최근성을 앞세우는 검색에 보답한다.
법률 어휘와 완고한 구조 관례를 지닌 격식 있는 문서다. 구조를 아는 청킹, 법률 도메인 임베딩, 모든 진술을 잠재적으로 구속력 있는 것으로 다루는 검색에 보답한다.
하나의 검색 파이프라인은 이 모든 문서 유형에 대해 하나의 설정을 골라야 한다. 무엇을 고르든 그것은 타협이다. 임상시험에 맞는 청킹 전략은 서사형 리뷰를 조각낸다. 생의학 동의어를 붙잡는 임베딩 모델은 법률적 미묘함을 놓친다. 증거 열거를 요구하는 생성 프롬프트는 개념적 자료의 딱딱한 요약을 낳는다. 평균적 유능함은 실재하지만 도메인별 탁월함은 이룰 수 없다. 이질적 말뭉치 위의 프로덕션 시스템은 전문화된 검색이 낼 성과에 꾸준히 못 미치며, 그 폭은 이질성에 따라 다르되 가장 중요한 질의들에서 예사로 20%를 넘는다.
멀티 에이전트의 답은 단일 파이프라인 가정을 버리는 것이다. 모든 문서 유형을 가로질러 타협하는 검색기 하나를 짓는 대신, 각각 특정 문서 유형이나 도메인에 조율된 전문 검색기 여럿을 짓고 오케스트레이션 계층으로 그들을 조정한다. 오케스트레이터가 들어온 질의를 쪼개고, 하위 질의를 알맞은 전문가에게 배정하고, 전문가들의 응답을 최종 답으로 종합한다. 각 전문가는 자기 도메인 안에서 탁월하고, 조정 계층은 그 탁월함을 어느 단일 파이프라인도 따를 수 없는 시스템 수준의 성능으로 구성한다.
전문화는 공짜가 아니다. 전문가마다 자기 몫의 공학이 필요하다 — 자기 청킹 결정, 자기 임베딩 평가, 자기 캐스케이드 조율, 자기 평가 집합. 오케스트레이션 계층은 신중한 설계를 요구한다. 너무 적극적인 분해는 불필요한 조각남을 낳고, 너무 보수적인 배정은 전문가를 놀리게 만든다. 운영 부담은 실재하고, 많은 응용에서 그것은 정당화되지 않는다. 규율은 전문화가 그 투자를 되갚기 시작하는 문턱을 알아보고 아키텍처의 약속을 그에 맞게 정하는 것이다. 문턱에 이르렀음을 알리는 신호는 셋이다.
관례와 어휘와 구조가 참으로 다른 문서 유형을 가로질러 검색해야 할 때, 단일 파이프라인의 타협은 이질성이 커질수록 점점 아파진다.
전형적인 질의가 여러 문서 유형의 정보를 결합해야 할 때 — 내용을 회수하는 데 그치지 않고 범주를 가로질러 구성해야 할 때 — 단일 검색기는 그 구성을 효과적으로 조율할 수 없다.
오답이 의미 있는 비용을 지닐 때, 전문화에 드는 한계 투자는 오답의 한계 감소로 정당화된다.
제약사 연구 어시스턴트는 세 신호를 모두 보였고, 그래서 멀티 에이전트로 다시 지은 것이 성공했다. 셋 가운데 어느 것도 보이지 않는 응용은 대개 앞 장들의 더 단순한 아키텍처가 낫다.
멀티 에이전트 RAG 아키텍처가 정당한 것은, 말뭉치가 어떤 단일 검색 설정도 의미 있는 타협이 될 만큼 이질적일 때, 전형적 질의가 그 이질성을 가로질러 정보를 구성해야 할 때, 그리고 답의 무게가 추가 공학 투자를 정당화할 때다.
세 기준을 모두 충족하는 응용 — 규제 산업의 지식 시스템 대부분, 부서를 넘나드는 기업 검색 대부분, 전문 서비스의 연구 도구 대부분 — 은 전문화로 검색 품질에서 통상 20~40%를 얻는다. 두 기준에 못 미치는 응용은 통상 얻지 못한다.
전문 검색 에이전트는 아키텍처의 말로 하면 앞 장들에서 세운 온전한 검색 파이프라인 — 청킹, 임베딩, 인덱싱, 검색 캐스케이드, 선택적 성찰 — 을 말뭉치의 특정 부분이나 특정 종류의 질의로 범위 지은 것이다. 전문화는 파라미터를 조금 손보는 일이 아니다. 각 전문가는 마치 자기가 섬기는 말뭉치의 유일한 검색기인 듯 공학되며, 그 설계 선택은 여러 말뭉치를 가로지르는 타협이 아니라 그 말뭉치의 특성으로 정당화된다. 전문가를 작동하게 만드는 규율은 어떤 검색 파이프라인이든 작동하게 만드는 그 규율이다. 다만 전면적 일반성이 아니라 초점과 함께 적용된 것이다.
범위를 짓는 축은 넷이다. 도메인 전문가는 말뭉치의 주제로 범위를 짓는다. 제약사의 네 전문가가 그러했다. 법률 연구 시스템이라면 판례, 법령, 규제 지침, 사내 각서의 전문가를 둘 것이고, 금융 컴플라이언스라면 SEC 서류, 사내 정책, 시장 데이터, 과거 집행 조치의 전문가를 둘 것이다. 도메인 전문화가 통하는 까닭은 한 도메인 안의 관례가 대개 내적으로 일관되기 때문이다 — 임상시험 보고서는 연구를 가로질러 일관된 통계 어휘를 쓰고, 규제 서류는 구조 관례를 공유하며, 과학 문헌은 안정된 분과 규범을 지닌다 — 반면 다른 도메인의 관례와는 의미 있게 다르다. 전문가의 임베딩 모델과 청킹 전략과 캐스케이드는 이질성을 평균 내는 대신 도메인 안의 일관성에 맞춰 조율될 수 있다.
문서 유형 전문가는 주제가 아니라 구조적 형식으로 범위를 짓는다. 다형식 말뭉치라면 구조화된 표(PDF·엑셀·데이터베이스 내보내기에서 추출된), 서사형 산문(기사·각서·보고서), 대화 기록(채팅 전사, 회의록, 고객지원 응대), 코드(기술 문서, 소스 파일, 시스템 로그)의 전문가를 둘 수 있다. 이 전문화는 같은 도메인이 여러 구조 형식에 걸칠 때 특히 강력하다. 고객지원 말뭉치는 사용자용 문서(서사형 산문), 내부 제품 문서(기술 레퍼런스), 과거 티켓 기록(대화형), 코드 예제(형식 코드)를 함께 담을 수 있다. 이를 하나의 말뭉치로 다루면 타협이 나오고, 네 문서 유형으로 다루어 각각에 전문가를 두면 극적으로 나은 검색이 나온다. 그리고 종합 계층이 답의 각 부분이 어디서 왔는지 설명해야 할 때 출처가 훨씬 명료해진다.
과업 전문가는 문서의 종류가 아니라 질문의 종류로 범위를 짓는다. 금융 연구 시스템이라면 과거 조회("2024년 3분기에 우리가 무엇을 보고했나"), 비교 분석, 추세 탐지("열두 달에 걸쳐 어떻게 변했나"), 엔티티 판별("우리가 말하는 Apple이 어느 Apple인가")의 전문가를 둘 수 있다. 과업마다 검색 요구가 다르다 — 과거 조회는 정밀한 날짜 필터링을, 비교 분석은 병렬 다중 말뭉치 검색을, 추세 탐지는 시계열을 아는 청킹을, 엔티티 판별은 신중한 식별자 해소를 요구한다. 과업 전문화는 이 요구들을 붙잡되 그 덕을 보지 않는 과업에 강요하지 않는다. 통상 오케스트레이션 계층의 과업 라우팅 로직과 짝을 이룬다 — 오케스트레이터가 질의의 과업 유형을 분류해 알맞은 전문가에게 넘긴다.
프로덕션은 흔히 전략들을 결합한다. 복합 전문가는 도메인과 문서 유형 양쪽으로 범위를 지을 수 있다 — 이를테면 임상시험 구조화 데이터 표의 전문가를 임상시험 서사 요약의 전문가와 구별하는 것이다. 복합 전문화는 더 잘게 나뉜 전문가 집합을 낳고 각자가 더 집중할 수 있게 하지만, 오케스트레이션 계층이 더 큰 전문가 명부로 배정해야 하므로 라우팅 결정의 비용과 복잡성이 커진다. 성숙한 멀티 에이전트 RAG 시스템 대부분은 최상위 전문가 셋에서 일곱으로 수렴하고, 복합 범위는 이득이 조각남을 정당화하는 곳에만 선별적으로 쓴다.
전문 검색기 여럿을 갖추면 물음은 그들을 어떻게 조정하느냐가 된다. 오케스트레이션 계층이 독립적 전문가들의 모음을 멀티 에이전트 체계로 바꾸는 것이다. 프로덕션을 지배하는 패턴은 셋이고, 저마다 맞는 시스템의 꼴이 다르다.
조정하는 에이전트 하나를 체계의 중심에 둔다. 오케스트레이터가 질의를 받아 어느 전문가를 부를지 결정하고, 하위 질의를 병렬이나 순차로 내보내고, 응답을 모아 최종 답을 종합한다. 전문가들끼리는 이야기하지 않으며 모든 조정이 오케스트레이터를 지난다.
대부분의 멀티 에이전트 RAG에 옳은 패턴이다. 추론하기 가장 단순하고 감시하기 가장 쉬우며, 평가와 관측 가능성이 가장 곧바르다. 오케스트레이터가 시스템이 무엇을 했고 왜 했으며 각 전문가가 무엇을 보탰는지에 대한 단일한 진실의 자리가 된다.
오케스트레이터가 병목이 된다. 처리량에서도(전문가 배정은 병렬이어도 질의는 시간상 순차로 흐른다), 장애에서도(오케스트레이터가 멎으면 체계 전체가 멎는다). 대부분의 응용에서 이 대가는 받아들일 만하다. 단순함이 대안 패턴의 한계적 처리량 이득보다 값지다.
전문가들이 오케스트레이터를 통해서만이 아니라 서로 직접 이야기하게 한다. 규제 사항을 언급한 결과를 회수한 임상시험 전문가가 중앙을 거치지 않고 규제 전문가에게 곧바로 맥락을 물을 수 있다.
전문가들 사이의 워크플로가 단단히 얽혀 있을 때 — 한 전문가의 출력이 다른 전문가의 질의를 중앙이 미리 내다보기 어려운 방식으로 체계적으로 규정할 때 — 알맞다. 그러나 좀처럼 출발점으로 옳지 않다. 이를 채택한 팀은 대개 먼저 중앙 오케스트레이터 체계를 짓고, 직접 소통이 값어치를 내는 구체적 패턴을 식별한 뒤, 그 패턴에만 선별적으로 동료 상호작용을 들인다.
감시하고 평가하고 믿음직하게 운영하기가 훨씬 어렵다. 신설 시스템을 동료 협력으로 시작하면 거동을 예측하기 어렵고 실패를 진단하기 어려운 체계가 되기 쉽다.
중앙 오케스트레이션을 여러 층으로 늘린다. 최상위 오케스트레이터가 질의를 넓은 영역으로 쪼개고, 영역마다 하위 오케스트레이터가 자기 안의 전문가들을 조정한다. 제약사의 네 전문가라면 '내부 증거'(임상시험, 사내 각서)와 '외부 증거'(규제 서류, 외부 문헌)의 하위 오케스트레이터가 최상위 연구 질문 오케스트레이터에게 보고하는 꼴이 된다.
전문가 명부가 하나의 오케스트레이터로 잘 감당하기에 너무 클 때 — 통상 여덟 이상, 또는 전문가들이 자연스레 조리 있는 무리로 뭉칠 때 — 옳은 패턴이다. 조직 구조(서로 다른 팀이 서로 다른 전문가 무리를 소유하는)와도, 규모 요구(개별 하위 오케스트레이터를 자기 영역의 패턴에 최적화하는)와도 잘 맞는다.
조정 계층이 하나 늘어난 만큼 지연이 더하고 평가가 복잡해진다. 대부분의 체계에서 계층적 위임은 전문가 수가 평평한 오케스트레이터가 깔끔히 감당할 수준을 넘기까지는 과잉 공학이다.
# 멀티 에이전트 RAG의 중앙 오케스트레이터 패턴 from concurrent.futures import ThreadPoolExecutor from typing import Dict, List class Specialist: def __init__(self, name, scope_description, retrieval_pipeline): self.name = name self.scope = scope_description # 오케스트레이터 라우팅에 쓰인다 self.pipeline = retrieval_pipeline # 5·6·7장의 온전한 캐스케이드 def answer(self, sub_query) -> Dict: return self.pipeline.retrieve_and_generate(sub_query) class Orchestrator: def __init__(self, specialists: List[Specialist], planner_llm): self.specialists = {s.name: s for s in specialists} self.planner = planner_llm def route_and_synthesise(self, query): # 1. 질의를 쪼개고 어느 전문가를 부를지 정한다 plan = self.planner.plan(query, list(self.specialists.values())) # 2. 하위 질의를 전문가들에게 병렬로 내보낸다 with ThreadPoolExecutor(max_workers=len(plan.assignments)) as pool: futures = {a.specialist_name: pool.submit(self.specialists[a.specialist_name].answer, a.sub_query) for a in plan.assignments} specialist_results = {n: f.result() for n, f in futures.items()} # 3. 출처를 명시해 전문가들의 기여를 종합한다 return self.planner.synthesise(query, plan, specialist_results)
동료 협력이나 계층적 위임으로 시작한 프로덕션 팀은 압도적으로 그것을 후회하고, 중앙 오케스트레이션으로 시작해 선별적으로 다른 패턴으로 졸업한 팀은 압도적으로 후회하지 않는다.
중앙 오케스트레이션은 초기 프로덕션 배포가 필요로 하는 관측 가능성과 운영의 단순함을 준다. 체계가 안정되고 실제 워크로드 데이터로 자기의 진짜 조정 패턴을 이해한 뒤라면, 동료나 계층 패턴을 선별적으로 들이는 것은 통제된 개선이다. 더 정교한 패턴으로 시작하는 것은 초기 프로덕션에 감당할 수 없는 조정 문제를 안는 일이다.
멀티 에이전트 검색은 그 종합만큼만 좋다. 오케스트레이터가 질의를 쪼개고, 전문가에게 배정하고, 응답을 받았다. 사용자가 기대하는 것은 하나의 조리 있는 답이다. 네 전문가의 독립적 응답을 이어 붙인 것이 아니다. 종합 계층이 전문가들의 기여를 그 조리 있는 답으로 바꾸는 자리이며, 다른 데는 잘 지어진 멀티 에이전트 체계가 조용히 실패하는 자리도 여기다.
종합의 첫 규율은 명시적 출처다. 종합된 답이 어떤 주장을 할 때, 사용자(또는 상류의 감사 체계)는 어느 전문가가 그 증거를 주었고 그 전문가가 어느 문서에서 끌어왔는지 되짚을 수 있어야 한다. 프로덕션 멀티 에이전트 체계가 의지하는 출처의 사슬이 이것이다. 그것이 없으면 종합된 답은 불투명한 단언이고, 있으면 감사하고 반박하고 고칠 수 있는 검증 가능한 구성물이 된다.
구현은 통상 출처를 파이프라인 전체에 실로 꿰어 나간다. 각 전문가가 자기 응답에 이름, 자기가 답한 하위 질의, 끌어온 원문 청크를 식별하는 메타데이터를 태그한다. 종합 프롬프트가 그 태그를 포함하고, 언어 모델에 최종 답에서 출처를 보존하라고 지시한다 — 통상 인라인 참조나 대괄호 인용의 형태다. 규율은 출처를 감사 시점에 뒤늦게 만들어 내는 부산물이 아니라 종합 출력의 일급 기능으로 만드는 것이다.
전문가들은 예사로 어긋난다. 임상시험 전문가가 특정 용량에서 약의 유효성을 받치는 증거를 찾는데, 외부 문헌 전문가가 그 유효성에 의문을 던지는 더 최근의 리뷰를 띄울 수 있다. 종합 계층은 이 불일치를 의도적으로 다뤄야 한다. 거짓 합의로 뭉개서는 안 된다. 지배적인 전략은 셋이다.
우선순위를 매긴다. 전문가 범주 사이에 어느 쪽이 우선하는지를 종합기에 알려 두고, 발견이 충돌할 때 그에 따른다. 일관된 목소리를 지켜야 하는 고객 대면 응용이 대개 이것을 필요로 하며, 불일치는 사용자에게 유관할 때만 드러낸다.
각 전문가가 내놓은 증거의 강도를 쓴다. 종합이 바탕 출처의 품질로 각 기여의 무게를 잰다.
불일치를 사용자에게 명시적으로 내놓는다. 종합된 답이 전문가들이 어긋났음을 밝히고, 어느 편을 고르는 대신 그 어긋남을 요약한다. 연구 지원이 흔히 이 덕을 본다. 연구자는 문헌이 어디서 갈라지는지 알고 싶어 한다.
옳은 전략은 응용이 모호함을 얼마나 견딜 수 있는지에 달렸다. 임상 의사결정 지원은 모든 불일치를 임상의에게 올릴 수 없으므로 해소 규칙을 결정론적으로 적용해야 한다. 프로덕션 대부분은 여러 전략을 구현해 충돌 유형에 따라 골라 쓴다.
마지막 규율은 종합이 사용자의 원래 질의에 실제로 답하는지 검증하는 일이다. 오케스트레이터가 쪼갰고, 전문가들이 응답했고, 종합기가 결합했다. 이 지점의 위험은, 종합이 모든 하위 질의에 아름답게 답하고서도 어쩐 일인지 원 질문에는 답하지 못하는 것이다. 분해가 한 측면을 놓쳤거나, 종합이 실제로 물어진 것을 겨누지 않는 방식으로 부분들을 결합했기 때문이다. 프로덕션은 명시적 검증을 넣는다. 종합 뒤에 별도의 모델 호출(또는 학습된 분류기)이 종합된 답이 원 질의에 응답하는지 확인하고, 아니면 회복 행동으로 인도한다.
종합 검증은 7장 성찰 단계의 멀티 에이전트 대응물이다. 철저해 보이지만 실은 사용자의 질문을 섬기지 않는 답을 시스템이 자신 있게 내놓는 것을 막는 반복적 점검이다. 그것이 없으면 멀티 에이전트 RAG는 단일 에이전트 RAG보다 더 정교하게 틀린 답을 낼 수 있다. 나아진 실패 양식이 아니라 나빠진 실패 양식이다.
프로덕션의 멀티 에이전트 RAG는 분산 시스템 공학의 과제다. 앞 장들의 단일 파이프라인 규율은 각 전문가 안에서 여전히 유효하되, 체계 전체는 새로운 장애 양식과 새로운 관측 요구와 새로운 비용 역학을 지닌다. 이를 잘 운영하는 팀은 처음부터 분산 시스템으로 대접하고, 오케스트레이터를 공유하는 검색 파이프라인 몇 개로 대접하는 팀은 프로덕션 첫 몇 달에 걸쳐 그 결과를 발견한다.
각 전문가의 거동이 관측되어야 하고, 체계의 거동도 전체로서 관측되어야 한다. 관측 틀에는 세 계층이 필요하다. 전문가별 지표 — 검색 재현율, 지연 백분위, 질의당 비용 — 는 각 부품이 홀로 어떻게 하고 있는지 알려 준다. 오케스트레이션 지표 — 분해 품질, 라우팅 정확도, 종합 충실도 — 는 조정 계층이 어떻게 하고 있는지 알려 준다. 종단 간 지표 — 질의 만족도, 답의 정확성, 답까지의 시간 — 는 사용자의 눈에서 체계 전체가 어떻게 하고 있는지 알려 준다. 세 계층 모두 계측되어야 한다. 종단 간만 보면 장애를 진단할 수 없고, 전문가별만 보면 조정에서 창발하는 체계적 문제를 놓친다.
멀티 에이전트 RAG는 질의당 비용이 단일 에이전트보다 의미 있게 비싸다. 오케스트레이터의 계획 단계가 모델 호출 하나를 더하고, 종합 단계가 또 하나를 더하며, 부름을 받은 전문가마다 자기 검색·생성 비용을 더한다. 전문가 넷을 건드리는 질의는 같은 질의가 단일 에이전트에서 들 비용의 5~10배가 될 수 있다. 고volume 응용에서 이 규율은 존재의 문제가 된다. 질의당 경제를 다스릴 수 없는 체계는 규모를 감당할 수 없다.
비용 공학을 지배하는 패턴은 둘이다. 선별적 전문가 호출 — 오케스트레이터가 모두를 부르는 대신 이 질의에 정말 필요한 전문가를 정하는 것 — 은 답에 기여하지 않을 일을 피해 비용을 극적으로 줄인다. 전문가 계층화 — 1차 검색에는 빠르고 싼 전문가를, 1차 증거가 불충분할 때만 느리고 유능한 전문가를 부르는 것 — 은 어려운 질의의 품질을 지키면서 비용을 줄인다. 둘 모두 신중한 오케스트레이터 설계를 요구한다. 라우팅을 잘못 잡으면 순진한 멀티 에이전트보다 더 비싸면서 그에 상응하는 품질 개선은 못 내는 체계가 나온다.
멀티 에이전트 체계는 단일 에이전트가 겪지 않는 방식으로 실패한다. 전문가의 부재 — 한 전문가가 느리거나 닿지 않는 것 — 가 체계 전체를 멎게 해서는 안 된다. 오케스트레이터에게는 응답한 전문가들만으로 종합하는 퇴화 운영 경로가 필요하다. 조정의 표류 — 개별 설정이 서로 갈라져 전문가들의 출력이 더는 깔끔히 결합되지 않는 것 — 는 시간이 가며 떠오르고 주기적 정렬 감사를 요구한다. 분해의 실패 — 오케스트레이터가 중요한 측면을 놓치는 방식으로 질의를 쪼개는 것 — 는 모든 전문가가 자기가 받은 하위 질의에 옳게 응답해도 체계적으로 틀린 답을 낳는다.
프로덕션 팀은 각 장애 양식에 대한 런북을 기른다. 전문가의 부재는 우아한 퇴화로 다룬다 — 어느 전문가가 응답했고 어느 전문가가 응답하지 않았는지 종합기에 알려, 부분적임을 표시한 답을 내거나 재시도를 위해 질의를 올린다. 조정의 표류는 정기적인 교차 전문가 평가로 다룬다 — 종합 계층을 훈련하는 주기적 시험 집합과, 문제가 전문가 수준인지 오케스트레이션 수준인지 종합 수준인지 식별하는 진단이다. 분해의 실패는 8.4절의 종합 검증이 잡는다 — 종합이 원 질의에 실제로 답하지 않을 때, 실패는 대개 검색이 아니라 분해에 있다.
전문가 몇을 지어 품질 개선을 본 팀에게, 구별되는 말뭉치 부분마다 전문가를 더하고 싶은 유혹은 강하다. 이것이 전문가 난립으로 가는 길이다. 오케스트레이터가 효과적으로 배정할 수 없는 열다섯 전문가, 원래 체계의 열 배가 드는 비용, 그러면서 잘 고른 다섯 전문가의 체계를 눈에 띄게 앞서지 못하는 결과.
규율은 현재의 전문가 집합이 특정 질의 범주에서 의미 있는 품질을 탁자에 버려두고 있음을 측정이 보여 줄 때만 전문가를 더하는 것이다. 새 전문가는 측정을 통해 자기 존재를 정당화해야 한다. 그러지 않으면 수확은 줄어드는데 영원히 운영하고 감사해야 하는 복잡성을 짓는 셈이다.
가장 흔한 멀티 에이전트 실수는 잘 조율된 단일 에이전트로 족했을 곳에 이 아키텍처를 채택하는 것이다. 팀은 에이전틱 패턴에 들떠 전문가 서넷을 짓고 오케스트레이터를 얹은 뒤, 체계가 단일 파이프라인보다 나을 것이 없음을 발견한다 — 운영 비용은 다섯 배, 복잡성은 열 배를 치르고서.
처방 — 8.1절의 전문화 문턱이 진단 도구다. 세 기준을 모두 충족하지 않는다면 멀티 에이전트는 이른 최적화다. 단일 에이전트로 시작하고, 데이터가 뒷받침할 때 졸업하라.
종합된 답을 원 질의에 견주어 검증하지 않는 멀티 에이전트 체계는, 자기가 대체한 단일 에이전트 체계보다 더 정교하게 틀린 답을 예사로 낸다. 여러 전문가의 기여를 결합했기에 종합은 철저하게 들리지만, 그 정교한 구성이 체계가 물어진 것에 실제로 답하지 않았다는 사실을 가릴 수 있다.
처방 — 종합 검증, 곧 최종 답이 원 질의를 겨누는지에 대한 명시적 점검은 협상의 여지가 없다. 그것 없이는 전문가라는 추가 기계가 오답의 확신 증폭기가 된다.
전문가들이 어긋날 때 초기 구현들은 충돌을 암묵적으로 해소한다 — 종합기가 더 자신 있게 들리는 전문가, 프롬프트에서 먼저 나온 전문가, 청크가 더 많은 전문가를 고르는 것이다. 이런 암묵적 해소는 일관되지 않은 체계 거동을 낳는다. 같은 질의를 두 번 물으면 전문가 응답 순서의 미묘한 차이에 따라 다른 답이 나올 수 있다.
처방 — 충돌 해소는 명시적이어야 한다. 우선순위 규칙이든 증거 가중이든 공개 전략이든, 의도적으로 정의하고 일관되게 적용할 일이다. 암묵적 해소는 프로덕션에서 예측 불가능하게 떠오르는 신뢰성 결함이다.
멀티 에이전트 RAG는 말뭉치의 이질성, 질의의 복잡성, 답의 무게가 함께 단일 파이프라인이 타협으로 감당할 수 있는 바를 넘어설 때 정당하다. 전문화의 문턱에 이르는 응용은 비교적 적지만, 그 응용들은 이 아키텍처로 검색 품질에서 20~40%를 얻는다.
전문 검색 에이전트는 특정 말뭉치 부분, 문서 유형, 과업 부류로 범위 지어진 온전한 검색 파이프라인이다. 각 전문가는 자기 범위의 유일한 검색기인 듯 공학된다. 전문화는 파라미터를 손보는 데서 오지 않고 초점에서 온다.
중앙 오케스트레이션이 거의 모든 멀티 에이전트 RAG의 옳은 출발점이다. 동료 협력과 계층적 위임은 중앙 오케스트레이션이 체계를 제약하고 있음을 측정이 보여 준 뒤에 채택할 정교함이지, 그 전에 채택할 것이 아니다.
종합 계층이 명시적 출처, 의도적 충돌 해소, 종합 검증을 통해 전문가들의 기여를 조리 있는 답으로 바꾼다. 규율 있는 종합이 없으면 멀티 에이전트 체계는 단일 에이전트보다 더 정교하게 틀린 답을 낸다 — 나아진 실패 양식이 아니라 나빠진 실패 양식이다.
멀티 에이전트 RAG는 분산 시스템 공학의 과제다. 세 계층의 관측 가능성(전문가별·오케스트레이션·종단 간), 선별적 호출과 전문가 계층화를 통한 명시적 비용 공학, 전문가 수준과 조정 수준 장애 양식의 런북 — 이 운영 규율이 프로덕션에서 작동하는 멀티 에이전트 RAG와 유지보수의 짐이 되어 버린 멀티 에이전트 RAG를 가른다.
위 문헌 목록은 원서 8장의 Further Reading을 그대로 옮긴 것이다. 서지 사항의 최종 확인은 원 출처를 통해 하는 것이 옳다.
9장은 4부를 연다. 2부와 3부의 아키텍처를 규모 있게 믿음직하게 도는 체계로 바꾸는 프로덕션 공학의 규율이다. 시작은 평가다. 검색 품질을 체계적으로 재는 법, 사용자보다 먼저 실패를 감지하는 법, 그리고 다른 모든 프로덕션 규율을 가능하게 하는 평가 기반을 짓는 법. 캐스케이드는 이제 온전하다. 다음 물음은 그것이 잘 돌고 있음을 우리가 어떻게 아는가다.
3부를 지나며 배운 것을 돌아보면, 결국 하나의 이야기였다. 6장은 답이 문서 안이 아니라 문서 사이의 관계에 있음을 배웠고, 7장은 시스템이 자기를 돌아보는 자리를 배웠고, 8장은 다름을 지운 평균이 아니라 다른 채로 어우러지는 구성을 배웠다. 하나로 모든 것을 하려 할 때 잃는 것을 알아보는 눈, 그리고 여럿이 서로를 비추게 하는 손이 여기까지의 공부였다. 화이부동(和而不同)이라 하였으니, 어우러지되 같아지지 않는 것이 이 아키텍처의 이름이기도 하다.