The Shift from Models to Compound AI Systems

https://bair.berkeley.edu/blog/2024/02/18/compound-ai-systems/

---

Introduction:

• 초기 AI 관심은 대규모 언어 모델에 집중하고, 한번의 LLM 호출로 응답을 만드는 구조였음.
• 하지만 지금은 최첨단 결과를 내려면 단일 모델 대신 여러 구성요소를 조합한 복합 시스템이 유리하다는 사실이 부각됨:
  • 많은 기업과 연구자들도 정보를 검색·추가하는 Retrieval-Augmented Generation(RAG), 멀티 스텝 체인 등 다양한 컴포넌트를 활용
  • AlphaCode 2: LLM으로 최대 100만 개의 코드를 생성하고, 이를 거르는 과정을 추가해 최적의 해답을 찾음.
• 이런 복합 AI 시스템을 설계하는 과정에서 다양한 엔지니어링 기법, 툴, 최적화 방법이 필요해짐

 

 

복합 AI 시스템(Compound AI System)을 사용하는 이유:

• 복합 AI 시스템: 여러 컴포넌트(모델 여러 개 호출, 검색 엔진, 외부 툴 등)가 상호작용하여 AI 문제를 해결하는 시스템을 말함.
• 복합 시스템이 필요한 이유는 다음과 같음:
  • 시스템 디자인을 통한 성능 향상:
    • LLM(대규모 언어 모델) 자체가 점점 더 발전하고 있으나, 무작정 모델을 더 크게(또는 학습 비용을 크게) 만드는 것에는 한계가 있음. 예로 코딩 대회 문제를 푸는 정확도가 30% → 학습 규모를 3배로 늘려도 35% 정도라면 여전히 “실전”에는 부족. (비용 효율적이지 않다는 것)
    • 하지만 같은 모델이라도 복합 시스템(여러 번 샘플링+테스트+필터링 등)을 도입하면 80%대의 정확도까지 높일 수 있음.
    • 시스템 디자인은 상대적으로 빠르게 반복·개선 가능하기 때문에, 값비싼 모델 훈련을 계속하는 것보다 효율적.
  • 모델 외부 데이터 접근 및 동적(動的) 활용:
    • ML 모델은 정적인 데이터로 학습되므로, 학습 후 업데이트된 정보를 바로 반영하기 어려움.
    • 복합 시스템 내에서 검색(검색 엔진, DB 등)을 통해 갱신된 데이터를 불러오고, 필요한 권한(Access Control)에 따라 정보를 조합할 수 있음
    • 예: Retrieval-Augmented Generation (RAG) 등은 모델이 최신 정보나 특정 사용자 권한에 맞는 정보를 검색해 답변하도록 함.
  • 제어(Control) 및 신뢰성(Trust) 향상:
    • 신경망 기반 모델은 원하는 특정 행동을 100% 통제하기가 어려움.
    • 복합 시스템으로 모델 출력을 필터링하거나, 신뢰할 수 있는 자료로 교차 검증하는 등 다양한 방식으로 제어 가능
    • 예: 모델이 “환각(hallucination)”을 일으키는 상황에서, 검색을 통한 근거 제시(citations) 또는 사실 확인 루틴을 추가하면 사용자의 신뢰도가 상승.
  • 다양한 성능·비용 요구사항 대응:
    • 어떤 애플리케이션(예: 실시간 코드 자동완성)에서는 최고 성능 모델이 비용이 지나치게 높아 적합하지 않을 수 있음 → 작은 모델과 별도의 탐색 알고리즘으로 충분히 커버.
    • 하지만 반대로 “문제가 조금 복잡해도 추가 비용을 낼 테니 더 높은 정확도를 원한다”는 경우가 있을 수 있음 → 이때는 더 크고 비싼 모델을 활용하거나, 복합 설계를 통해 여러 단계를 거쳐 사실 여부를 엄격히 검증.
    • 요구사항에 맞는 적절한 모델이 필요할 수 있음.
  • 타 분야 AI 트렌드와의 일치:
    • 자율주행 자동차 분야 등 이미 다른 AI 분야에서는 여러 요소(센서, 분리된 모듈, 예측 모델 등)를 결합한 시스템 설계가 보편적
    • 생성 AI도 점차 그 방향으로 발전하고 있으며, 복합 AI 시스템이 앞으로도 주요 패러다임이 될 것이라는 전망.

The AI System Design Space:

• AlphaCode 2:
  • Components:
    • Fine-tuned LLMs (코드 샘플링 및 점수화)
      • 대규모 언어 모델을 코딩 분야에 특화되도록 파인 튜닝하여, 한 문제에 대해 최대 수십~수백만 개의 코드를 생성함.
      • 생성된 코드 각각에 대해 ‘문제 해결 가능성(점수)’을 매기는 역할도 함.
    • Code Execution Module
      • 실제로 코드를 실행하고, 테스트 케이스 등을 통과하는지를 검사하여 정확도를 평가함.
    • Clustering Model
      • 유사한 코드 해답을 묶어 중복을 제거하거나, 서로 다른 풀이 전략을 찾는 데 기여
      • 이를 통해 효율적으로 최고의 답안을 선별할 수 있음
  • Designs:
    • 최대 100만 개의 코딩 문제 해답 후보를 생성한 뒤, 테스트 및 점수화 과정을 거쳐 올바른 해답을 추려냄
  • Results:
    • 코딩 대회에서 인간 상위 15% (85th percentile) 수준에 해당하는 결과
• AlphaGeometry:
  • Components:
    • Fine-tuned LLM
      • LLM이 ‘이 문제에서 어떤 도형 구성이 필요한지’ 등 추상적인 해법 과정을 자연어로 제안
    • Symbolic Math Engine
      • 전통적 방식의 수학 엔진으로, 제안된 해법을 구체적으로 증명 또는 반증하거나, 식을 변형해봄.
      • LLM이 제안한 (가정) → 기호 엔진이 결과 해석 → LLM이 피드백 받고 수정 … 이런 식의 반복 설계가 가능
  • Designs:
    • 기하 문제를 해결하기 위해 LLM이 먼저 해결 전략(구성) 제안을 하고, 기호 기반 엔진이 추론된 사실을 점검 및 피드백. 여러 차례의 상호작용을 통해 답안 완성
  • Results:
    • 국제수학올림피아드(IMO) 기준, 은메달(silver)~금메달(gold) 사이의 실력으로 평가
• Medprompt:
  • Components:
    • GPT-4 LLM:
      • 의료 질의에 대한 주요 추론 엔진 역할.
    • Nearest-Neighbor Search DB (정답 예시 검색)
      • 과거에 정답이 확인된 예시(증상, 진단, 치료사례 등)를 빠르게 찾아, GPT-4가 참조하도록 도움.
    • LLM-Generated Chain-of-thought Examples
      • LLM이 예시들에 대해 “어떤 논리 과정을 거쳤는지”를 추가 기술(체인 오브 띠솟) → 이를 학습 프롬프트에 포함해 추론 정확도 향상.
    • Multiple Samples & Ensembling
      • 한 번에 한 답변만 내는 것이 아니라, 여러 번의 응답을 받아 투표 또는 결합(ensemble) 하여 최종 결정.
  • Designs:
    • 의학 관련 질의에 대해, 비슷한 예시(few-shot 예시)를 검색해 프롬프트 구성 → 각 예시에 대해 체인 오브 띠솟(chain-of-thought) 생성 → 최대 11개의 답안을 생성·판단 후 최종 결정
  • Results:
    • Med-PaLM 등 기존 의료 특화 모델보다 더 높은 정확도 달성 (간단한 프롬프트만 쓰는 방식 대비 우수)
• Gemini on MMLU:
  • Components:
    • Gemini LLM
    • Custom Inference Logic
      • 모델이 32개의 체인 오브 띠솟(추론 과정을 담은 답변)을 생성.
      • 다수결로 특정 답을 선택하거나, 일치가 부족하면 다른 생성 방식을 시도하는 맞춤형 추론 규칙
  • Designs:
    • MMLU 벤치마크에서 CoT@32(32번 체인 오브 띠솟) 전략을 사용해 32개의 답안을 샘플링하고, 다수가 일치하면 그 답안을 채택. 불충분하면 체인 오브 띠솟 없이 재생성
  • Results:
    • MMLU 정확도 90.04% 달성 (GPT-4의 5-shot 86.4%, Gemini 자체 5-shot 83.7%보다 우수)
• ChatGPT Plus:
  • Components:
    • LLM- Web Browser Plugin
      • 실시간 웹 검색이 필요한 경우 LLM이 판단하여 검색 수행 후 정보를 반영.
    • Code Interpreter Plugin (Python)
      • 파이썬 코드 실행이 필요할 때, 직접 코드를 작성·실행하여 그 결과를 사용자에게 반환.
    • DALL-E Image Generator
      • 이미지 생성을 요청받았을 때, DALL-E 엔진을 호출하여 이미지를 생성하고 반환.
  • Design:
    • 웹 검색, 코드 실행, 이미지 생성 등 다양한 툴을 호출할 수 있도록 플러그인을 통합. 대화형 모델(LLM)이 언제 어떤 툴을 사용할지 결정
  • Results:
    • 전 세계적으로 수백만 명의 유료 구독자를 확보한 대중적인 AI 서비스
• RAG, ORQA, Bing, Baleen, etc:
  • Components:
    • LLM (여러 번 호출되기도 함)
    • Retrieval System
  • Design:
    • RAG(Retrieval-Augmented Generation) 등에서 LLM이 검색 질의를 생성하거나, 현재 컨텍스트에 맞춰 직접 검색하여 필요한 정보를 받아온 뒤 답변 생성
  • Results:
    • 검색 엔진, 기업 애플리케이션 등에서 광범위하게 사용됨

Key Challenges in Compound AI Systems:

• 설계 공간(Design Space):
  • 복합 AI 시스템은 단순히 “LLM 하나”만 사용하는 것이 아니라, 검색 엔진(Retriever), LLM, 프롬프트 조정, 체인 오브 띠솟(Chain of Thought), 추가 검증 모델 등 여러 컴포넌트가 상호작용하여 작동함.
  • 자원(리소스) 배분 문제:
    • 복합 시스템에서는 지연 시간(latency) 이나 비용(cost) 같은 리소스 제한이 있음.
    • 예: RAG에서 100ms 안에 답을 주어야 할 때, 20ms를 검색에 쓰고 80ms를 LLM 추론에 할당할지, 혹은 그 반대로 할지 결정해야 함.
  • 방대한 탐색 공간;
    • 단일 모델보다 조합할 수 있는 요소가 훨씬 많아, 좋은 성능을 내기 위한 설계 탐색(Design Exploration) 자체가 복잡해짐.
    • 여러 실험이 필요함.
• 최적화(Optimization):
  • 복합 AI 시스템에서는 각 요소를 함께 최적화(co-optimization) 해야함:
    • 예: RAG에서 LLM이 검색할 질의를 생성 → 검색 엔진이 결과 제공 → 다시 LLM이 최종 답안을 생성.
    • 여기서 LLM 이 생성할 질의는 검색 시스템에 맞게 최적화가 되야하고, 검색 시스템이 가져온 결과도 LLM 이 잘 사용할 수 있도록 요약 및 재구성되있어야 함.
  • 비분화(Non-differentiable) 컴포넌트:
    • 전통적인 딥러닝 모델(Pytorch 등)은 미분 가능(differentiable) 하므로, 엔드 투 엔드(end-to-end) 학습이 비교적 쉬움.
    • 하지만 복합 AI 시스템에서는 검색 엔진, 코드 실행기 등 미분 불가능한 모듈이 많음
    • 이로 인해 새로운 최적화 기법이 필요하며, 아직은 연구 초기 단계.
• 운영(Operaiton):
  • MLOps의 복잡성 증가
    • 단일 모델(예: 스팸 분류기)은 예측 정확도 등을 추적하기 쉽지만, 복합 AI 시스템(예: 여러 번 ‘반추(reflection)’를 하고 검색 API도 호출하는 LLM 에이전트)은 어떤 지표로 성능을 모니터링할지조차 까다로움.
    • 예: “회고(reflection) 스텝을 몇 번 거쳤는지, 외부 API 호출은 몇 번 했는지, 그 성공률은 어떤지” 등을 모두 추적해야 할 수도 있음.
  • 모니터링(Monitoring) & 디버깅(Debugging):
    • 복합 시스템은 내부적으로 거치는 단계가 많아서, 로그를 수집해 원인을 추적하는 과정이 복잡.
  • 데이터 파이프라인(DataOps):
    • RAG처럼 벡터 DB나 검색 엔진을 사용하는 경우, 데이터 품질이 곧 시스템의 품질을 좌우.
    • 따라서 데이터 파이프라인 운영(업데이트, 권한 관리, 적절한 인덱싱 등)이 더욱 중요해짐

 

 

복합 시스템을 위한 새로운 패러다임(Emerging Paradigms):

• 설계: Composition Frameworks & Strategies:
  • 언어 모델 프로그래밍(Language Model Programming) 프레임워크
    • 여러 LLM 콜(호출)과 기타 구성 요소(검색, 데이터베이스, 외부 API 등)를 “모듈”처럼 연결해 복합 애플리케이션을 작성할 수 있게 함.
    • 대표 예시:
      • LangChain / LlamaIndex: 전통적인 프로그래밍 언어에서 LLM을 호출하고, 결과를 파이프라인처럼 연결해 조합할 수 있도록 도와줌.
      • AutoGPT / BabyAGI: “에이전트(Agent)” 컨셉을 활용해, LLM이 전체 애플리케이션 로직을 주도하게끔 하는 프레임워크.
      • Guardrails, Outlines, LMQL, SGLang: LLM의 출력 제어(예: 형식 강제, 규칙 기반 필터링)를 위한 도구들.
• 자동 품질 최적화: DSPy
  • DSPy는 LLM 호출과 외부 툴로 이루어진 “파이프라인”을 자동으로 최적화하는 첫 번째 프레임워크(학계 주도).
  • 사용자 입장:
    • 여러 단계(LLM → 검색 → 또 다른 LLM 등)로 구성된 애플리케이션을 만든 뒤, 원하는 지표(정확도 등)에 대한 목표치와 검증 데이터셋을 제공하면 됨.
• 비용 최적화: FrugalGPT & AI Gateways:
  • FrugalGPT:
    • 서로 다른 AI 모델(예: GPT-4, GPT-3.5, 기타 오픈소스 모델 등)을 자동으로 라우팅(어떤 입력에는 GPT-4, 다른 입력에는 GPT-3.5 등)하여, 주어진 예산 안에서 최대 품질을 달성하도록 하는 프레임워크.
    • 동일 비용 대비 최대 4% 성능 개선, 또는 유사 성능을 90% 저렴하게 달성 가능
  • AI Gateways / Routers:
    • Databricks AI Gateway, OpenRouter, Martian 등이 대표적.
    • 복합 AI 시스템을 여러 단계로 나누어, 각 단계마다 가장 적합한 모델을 자동 선택해 성능과 비용의 균형을 최적화.
• 운영: LLMOps & DataOps
  • LLMOps:
    • 기존 MLOps가 확장된 개념: 복합 AI 시스템에서, 여러 번의 LLM 호출과 외부 API 호출이 뒤섞여 작동하므로, 각 단계의 출력(Intermediate Output)을 모두 추적하고 모니터링하기 위한 도구·방식이 필요.
    • 예: LangSmith, Phoenix Traces, Databricks Inference Tables: 복잡한 추론 경로(에이전트의 단계별 호출, 검색 엔진 응답 등)를 로깅·시각화·평가해 디버깅을 돕는다.
  • DataOps:
    • Retrieval-Augmented Generation(RAG)처럼 벡터 DB 또는 검색 엔진을 사용하는 경우,
    • 데이터 품질(인덱싱, 갱신 주기, 권한 설정 등)이 곧 시스템 성능에 큰 영향.
    • 따라서 데이터 파이프라인 자체를 어떻게 모니터링·운영할지가 중요해짐.