Building effective agents
published : 2024-12-20
지난 1 년 동안, 우리는 산업 전역의 LLM (Lange Language Model) 에이전트를 구축하는 수십 명의 팀과 함께 일했습니다. 지속적으로 가장 성공적인 구현은 복잡한 프레임 워크 또는 전문 라이브러리를 사용하지 않았습니다. 대신, 그들은 단순하고 종합 가능한 패턴으로 건축했습니다.
이 게시물에서는 고객과 협력하여 배운 내용을 공유하고 에이전트를 구축하고 효과적인 에이전트 구축에 대한 개발자에게 실질적인 조언을 제공합니다.
What are agents?
"에이전트"는 여러 가지 방법으로 정의 될 수 있습니다. 일부 고객은 복잡한 작업을 수행하기 위해 다양한 도구를 사용하여 장기 동안 독립적으로 작동하는 완전 자율 시스템으로 에이전트를 정의합니다. 다른 사람들은이 용어를 사용하여 사전 정의 된 워크 플로를 따르는 더 많은 규범 구현을 설명합니다. Anthropic에서는 이러한 모든 변형을 에이전트 시스템으로 분류하지만 워크 플로와 에이전트간에 중요한 건축 적 구분을 가져옵니다.
- 워크 플로는 사전 정의 된 코드 경로를 통해 LLM과 도구가 조정되는 시스템입니다.
- 반면 에이전트는 LLM이 자신의 프로세스와 도구 사용량을 동적으로 지시하여 작업을 수행하는 방법에 대한 제어를 유지하는 시스템입니다.
아래에서는 두 가지 유형의 에이전트 시스템을 자세히 살펴볼 것입니다. 부록 1 (“실제로 에이전트”)에서 고객이 이러한 종류의 시스템을 사용하여 특정 가치를 찾은 두 가지 도메인을 설명합니다.
When (and when not) to use agents
- LLM을 이용한 응용 프로그램을 구축
- 간단한 솔루션을 찾는 것이 좋고, 필요한 경우 복잡성만 증가하는 것이 좋다.
- 복잡성이 보장된 경우, workflow는 잘 정의된 작업에 대한 예측가능성과 일관성을 제공.
- Agentic 시스템 구축
- 종종 대기시간과 더 나은 작업 성능을 위해 거래 비용을 거래하며 트레이드 오프가 합리적일때를 고려해야함.
- 유연성과 모델 중심 의사 결정이 규모로 필요한 경우 LLM보다 더 나은 옵션.
When and how to use frameworks
에이전트 시스템을 쉽게 구현할 수 있도록하는 많은 프레임 워크가 있습니다.
- Langchain의 Langgraph;
- Amazon Bedrock의 AI 에이전트 프레임 워크;
- 리벳, 드래그 앤 드롭 Gui LLM 워크 플로 빌더; 그리고
- 복잡한 워크 플로를 구축하고 테스트하기위한 또 다른 GUI 도구 인 Vellum.
이러한 프레임 워크를 사용하면 LLMs호출, 도구 정의 및 구문 분석 및 통화를 체인하는것과 같은 표준 저수준 작업을 단순화하여 쉽게 시작 할수 있다.
But, 이들은 종종 기본 프롬프트와 응답을 가릴 수 있는 여분의 추상화 층을 만들어 debug하기 더 어려워진다.
So, 개발자는 LLM API를 직접 사용하여 시작하는 것이 좋다는 의견.
몇 줄의 코드로 많은 패턴을 구현 가능
프레임 워크를 사용하는 경우 기본 코드를 이해해야한다.
Building blocks, workflows, and agents
이 섹션에서는 생산에서 본 에이전트 시스템의 일반적인 패턴을 살펴 보겠습니다. 우리는 단순한 구성 워크 플로에서 자율적 인 에이전트에 이르기까지 기초 빌딩 블록 (증강 된 LLM)부터 시작하여 복잡성을 점차적으로 증가시킬 것입니다.
Building block: The augmented LLM
에이전트 시스템의 기본 빌딩 블록은 검색, 도구 및 메모리와 같은 증강으로 향상된 LLM임.
자체 검색 쿼리를 생성하고, 적절한 도구를 선택하고 유지해야할 정보를 결정 가능.
Figure. The augmented LLM
중점을 두어야할 구현의 두가지 주요 측면
특정 사용 사례에 맞게 기능 최적화
Retrieval, tools, memory 기능을 단순히 추가하는것이 아니라, 사용자의 특정 요구사항에 맞게 최적화
LLM이 쉽게 활용할 수 있도록 직관적이고 문서화된 인터페이스 제공
모델이 어떤 상황에서 Retrieval을 사용할지, Tools를 호출할지, Memory에 저장할지를, 명확하게 정의하고 관리할 수 있어야함.
Model Context Protocol(MCP) 같은 표준화 된 방식으로 구현 추천.
Workflow: Prompt chaining
Prompt Chaining(프롬프트 체이닝)은 하나의 작업을 여러 개의 단계로 나누고, 각 LLM 호출이 이전 단계의 출력을 기반으로 다음 단계를 수행하는 방식이다.
- 즉, 큰 작업을 작은 하위 작업들로 분해하여 처리
- 특정 단계에서 Gate(게이트, 검증 절차)를 추가해 진행 여부를 결정
- The prompt chaining workflow
주요 특징
- 단계별 검증 가능 -> “Gate”를 활용해 프로세스가 올바르게 진행되는지 확인 후 다음 단계 진행
- 정확성 향상 --> 한번에 복잡한 문제를 해결하는 대신, 여러 단계를 거쳐 더 정확한 결과 도출
- 지연 시간(latency) 증가 --> 여러번 LLM을 호출하기 때문에 속도는 느려짐
프롬프트 체이닝이 적합한 경우
- 작업을 고정된 하위 작업으로 쉽게 나눌 수 있을 때
- 정확성이 중요한 경우(각 단계를 검증해야할 때)
- LLM이 한번에 너무 많은 정보를 처리하기 어려운 경우
Workflow: Routing
Routing(라우팅)은 입력을 특정 카테고리로 분류한 후, 해당 카테고리에 적절한 후속 작업을 수행하는 방식이다.
즉, 입력의 성격을 분석하여 최적의 LLM 호출이나 작업을 선택하는 구조이다.
- The routing workflow
주요 특징
- 입력에 따라 최적화된 LLM호출 가능
- 입력 데이터를 분류하여 적절한 프롬프트나 모델을 선택
- 특정 유형의 입력은 가벼운 LLM으로, 복잡한 입력은 강력한 LLM으로 처리 - Separation of Concern(관심사 분리)
- 서로 다른 성격의 작업을 독립적으로 처리할 수 있도록 구성
- 예 ) 일반적인 고객 문의와 기술지원 요청을 따로 처리 - 성능 저하 방지
- 하나의 LLM이 모든 입력을 처리하면 성능 저하 가능성이 있음.
- Routing을 통해 적절한 모델과 프롬프트를 선택하여 최적의 결과 도출
Routing이 적합한 경우
- 입력 유형이 다양하고 각 유형에 따라 최적의 처리 방식이 다를때
- 정확한 입력 분류가 가능할 때 (LLM 또는 전통적인 분류 모델 사용가능)
- 비용과 속도를 균형있게 최적화하고 싶을때
적용 사례
- 고객 서비스 자동화
- 일반 질문 -> 간단한 FAQ시스템 또는 가벼운 LLM
- 환불요청 -> 정책 검토 후 프로세스 자동진행
- 기술 지원 -> 심화된 기술 분석이 필요한 경우 강력한 LLM 활용 - LLM최적화 및 비용절감
- 간단한 질문 -> 경량 모델 (저비용, 빠른 응답)
- 복잡한 질문 -> 고성능 모델(비용증가, 높은정확도)
Workflow: Parallelization
Parallelization(병렬 처리)은 여러 개의 LLM 호출을 동시에 실행한 후, 그 결과를 Aggregator(집계기)에서 합쳐 최종 결과를 도출하는 방식이다.
즉, 하나의 큰 작업을 병렬로 실행해 속도를 높이거나, 다양한 관점에서 결과를 생성해 신뢰성을 높이는 방법이다.
- Sectioning : 독립적 인 하위 작업으로 작업을 중단하는 것은 병렬로 실행됩니다.
- Voting : 다양한 출력을 얻기 위해 동일한 작업을 여러 번 실행합니다.
- The parallelization workflow
When to use this workflow : 병렬화는 속도를 위해 분할 된 하위 작업을 병렬화 할 수 있거나 신뢰도가 높은 결과를 얻기 위해 여러 관점이나 시도가 필요한 경우 효과적입니다. 여러 고려 사항이있는 복잡한 작업의 경우 각 고려 사항이 별도의 LLM 호출로 처리 될 때 일반적으로 LLM이 더 잘 수행되어 각 특정 측면에 집중할 수 있습니다.
Examples where parallelization is useful:
- Sectioning :
- 하나의 모델 인스턴스가 사용자 쿼리를 처리하고 다른 모델이 부적절한 컨텐츠 또는 요청에 대해 화면을 화면으로 가드 레일 구현합니다. 이는 가드 레일과 핵심 응답을 모두 동일한 LLM 통화 처리보다 더 잘 수행하는 경향이 있습니다.
- LLM 성능을 평가하기위한 EVAL 자동화. 각 LLM 호출은 주어진 프롬프트에서 모델 성능의 다른 측면을 평가합니다.
- Voting :
- 취약점에 대한 코드를 검토하여 여러 다른 프롬프트가 문제를 발견하면 코드를 검토하고 표시합니다.
- 주어진 콘텐츠가 부적절한 지 여부를 평가하고 여러 가지 프롬프트가 다른 측면을 평가하거나 잘못된 양성과 부정적인 균형을 맞추기 위해 다른 투표 임계 값을 요구합니다.
Workflow: Orchestrator-workers
오케스트레이터 노동자 워크 플로우에서 중앙 LLM은 작업을 동적으로 분해하고 작업자 LLM으로 위임하고 결과를 종합합니다.
When to use this workflow: 필요한 하위 작업을 예측할 수없는 복잡한 작업에 적합합니다 (예 : 변경해야 할 파일 수와 각 파일의 변경 특성은 작업에 의존). 지형적으로 유사하지만 병렬화와의 주요 차이점은 유연성입니다. 서브 타스크는 사전 정의되지 않았지만 특정 입력을 기반으로 오케스트레이터에 의해 결정됩니다.
Example where orchestrator-workers is useful :
- 매번 여러 파일을 복잡하게 변경하는 코딩 제품.
- 가능한 관련 정보를 위해 여러 출처에서 정보 수집 및 분석과 관련된 작업을 검색합니다.
Workflow: Evaluator-optimizer
Evaluator-Aptimizer Workflow에서 하나의 LLM 호출은 응답을 생성하는 반면 다른 LLM은 응답을 생성합니다. 다른 LLM은 루프에서 평가 및 피드백을 제공합니다.
- The evaluator-optimizer workflow
When to use this workflow: 명확한 평가 기준이 있고 반복 정제가 측정 가능한 값을 제공 할 때 특히 효과적입니다. 우수한 두 가지 징후는 먼저 인간이 피드백을 표현할 때 LLM 반응이 명백히 개선 될 수 있다는 것입니다. 둘째, LLM은 그러한 피드백을 제공 할 수 있습니다. 이것은 세련된 문서를 제작할 때 인간 작가가 겪을 수있는 반복적 인 작문 과정과 유사합니다.
Examples where evaluator-optimizer is useful:
- 번역가 LLM이 처음에는 캡처하지 못할 수있는 뉘앙스가 있지만 평가자 LLM이 유용한 비판을 제공 할 수있는 문학적 번역.
- 평가자가 추가 검색이 필요했는지 여부를 결정하는 포괄적 인 정보를 수집하기 위해 여러 라운드의 검색 및 분석이 필요한 복잡한 검색 작업.
Agents
LLM이 주요 기능에서 LLM이 성숙함에 따라 생산에 등장하고 있습니다. 복잡한 입력을 이해하고, 추론 및 계획에 참여하고, 도구를 안정적으로 사용하고, 오류에서 복구하는. 에이전트는 인간 사용자와의 명령 또는 대화식 토론으로 작업을 시작합니다. 작업이 명확 해지면 에이전트는 독립적으로 계획하고 운영되며 잠재적으로 추가 정보 나 판단을 위해 인간에게 돌아갑니다. 실행하는 동안 에이전트가 각 단계 (예 : 도구 통화 결과 또는 코드 실행)에서 환경에서“진실”을 얻는 것이 진행 상황을 평가하는 것이 중요합니다. 그런 다음 에이전트는 체크 포인트 또는 차단제를 만날 때 인간의 피드백을 위해 일시 중지 할 수 있습니다. 작업은 종종 완료시 종료되지만 제어를 유지하기 위해 정지 조건 (예 : 최대 반복 수)을 포함하는 것이 일반적입니다.
에이전트는 정교한 작업을 처리 할 수 있지만 구현은 종종 간단합니다. 일반적으로 루프의 환경 피드백을 기반으로 한 도구를 사용하는 LLM입니다. 따라서 도구 세트와 문서를 명확하고 신중하게 디자인하는 것이 중요합니다. 우리는 부록 2 ( "신속한 엔지니어링 도구")에서 도구 개발을위한 모범 사례를 확장합니다.
When to use agents: 이전트는 필요한 단계를 예측하기가 어렵거나 불가능한 개방형 문제에 사용될 수 있으며 고정 경로를 하드 코딩 할 수없는 곳에서 사용될 수 있습니다. LLM은 잠재적으로 많은 턴 동안 운영 될 것이며 의사 결정에 대해 어느 정도의 신뢰를 가져야합니다. 에이전트의 자율성은 신뢰할 수있는 환경에서 작업을 확장하는 데 이상적입니다.
에이전트의 자율적 특성은 더 높은 비용과 복합 오류의 가능성을 의미합니다. 적절한 가드 레일과 함께 샌드 박스 환경에서 광범위한 테스트를 권장합니다.
Examples where agents are useful:
The following examples are from our own implementations:
- 작업 설명을 기반으로 많은 파일을 편집하는 SWE 벤치 작업을 해결하는 코딩 에이전트;
- Claude가 컴퓨터를 사용하여 작업을 수행하는 "컴퓨터 사용"참조 구현.
Combining and customizing these patterns
이 빌딩 블록은 규범이 아닙니다. 그들은 개발자가 다른 사용 사례에 맞게 형성하고 결합 할 수있는 일반적인 패턴입니다. LLM 기능과 마찬가지로 성공의 핵심은 성능을 측정하고 구현을 반복하는 것입니다. 반복하려면 : 결과를 명백히 향상시킬 때만 복잡성을 추가하는 것을 고려해야합니다.
Summary
LLM 공간에서의 성공은 가장 정교한 시스템을 구축하는 것이 아닙니다. 그것은 당신의 요구에 맞는 적절한 시스템을 구축하는 것입니다. 간단한 프롬프트로 시작하여 포괄적 인 평가로 최적화 한 후 간단한 솔루션이 부족할 때만 멀티 단계 에이전트 시스템을 추가하십시오.
에이전트를 구현할 때는 세 가지 핵심 원칙을 따르려고 노력합니다.
-
에이전트 디자인의 단순성을 유지하십시오.
-
에이전트의 계획 단계를 명시 적으로 보여줌으로써 투명성 우선 순위를 정합니다.
-
철저한 도구 문서 및 테스트를 통해 ACI (Agent-Computer Interface)를 조심스럽게 작성하십시오.
프레임 워크는 신속하게 시작하는 데 도움이 될 수 있지만 주저하지 말고 추상화 레이어를 줄이고 생산으로 이동할 때 기본 구성 요소로 빌드하십시오. 이러한 원칙을 따르면 강력 할뿐만 아니라 신뢰할 수 있고 유지 가능하며 사용자가 신뢰할 수있는 에이전트를 만들 수 있습니다.
