효율적인 인텔리전스를 구축하는 간단하고 효과적인 방법을 요약합니다.

10.1K 00

지난 한 해 동안 여러 산업 분야에서 대규모 언어 모델(LLM) 에이전트를 구축하는 팀과 협력해 왔습니다. 일관되게, 가장 성공적인 구현은 복잡한 프레임워크나 특수 라이브러리를 사용하지 않고 간단하고 구성 가능한 패턴으로 구축된다는 사실을 발견했습니다.

이 게시물에서는 고객과 함께 일하며 직접 에이전트를 구축한 경험을 공유하고 개발자에게 효율적인 에이전트 구축을 위한 실용적인 조언을 제공합니다.

지능형/에이전트/에이전트는 다음에서 동일한 의미를 갖습니다.

에이전트란 무엇인가요?

"에이전트"는 다양한 방식으로 정의할 수 있습니다. 일부 고객은 에이전트를 다양한 도구를 사용하여 복잡한 작업을 수행하면서 오랜 시간 동안 독립적으로 실행할 수 있는 완전 자율 시스템으로 정의하기도 합니다. 다른 고객들은 사전 정의된 워크플로우를 따르는 보다 규범적인 구현을 설명하는 데 사용합니다. 앤트로픽에서는 이러한 변형을 다음과 같이 통칭합니다. 에이전트 시스템그러나 다음과 같은 아키텍처적 과제가 있습니다. 워크플로 노래로 응답 책임 있는 위치에서 SB를 대신하여 행동합니다. 중요한 구분이 이루어졌습니다:

워크플로 는 미리 정의된 코드 경로를 통해 LLM과 도구를 오케스트레이션하는 시스템입니다.
책임 있는 위치에서 SB를 대신하여 행동합니다. 은 LLM이 자체 프로세스 및 도구 사용을 동적으로 지시하여 작업 수행 방식을 제어하는 시스템입니다.

아래에서는 이 두 가지 에이전트 시스템에 대해 자세히 살펴봅니다. 부록 1("실제로 사용되는 에이전트")에서는 고객이 이러한 시스템을 특히 유용하게 사용한 두 가지 영역에 대해 설명합니다.

프록시를 사용해야 할 때(그리고 사용하지 않을 때)

LLM으로 애플리케이션을 구축할 때는 가능한 한 가장 단순한 솔루션을 찾고 필요한 경우에만 복잡성을 추가하는 것이 좋습니다. 이는 에이전트화된 시스템을 전혀 구축하지 않는 것을 의미할 수도 있습니다. 프록시화된 시스템은 종종 더 나은 작업 성능을 위해 지연 시간과 비용을 절충하는 경우가 많으며, 이러한 절충이 그만한 가치가 있는지 고려해야 합니다.

워크플로는 복잡성이 높은 경우 잘 정의된 작업에 대해 예측 가능성과 일관성을 제공하며, 유연성과 모델 중심의 의사 결정 확장이 필요한 경우 에이전트의 성능이 향상됩니다. 하지만 많은 애플리케이션의 경우 검색 및 상황에 맞는 예시와 함께 단일 LLM 호출을 최적화하는 것으로 충분할 때가 많습니다.

프레임워크 사용 시기 및 방법

에이전트화된 시스템을 더 쉽게 구현할 수 있는 여러 가지 프레임워크가 있습니다:

LangGraph LangChain에서;
아마존 베드락의 AI 에이전트 프레임워크.;
리벳LLM 워크플로 빌더는 드래그 앤 드롭 방식의 GUI LLM 워크플로 빌더입니다;
Vellum복잡한 워크플로를 구축하고 테스트하기 위한 또 다른 GUI 도구입니다.

이러한 프레임워크는 LLM 호출, 도구 정의 및 구문 분석, 호출 연결과 같은 표준 저수준 작업을 단순화하여 개발 프로세스를 더 쉽게 만들어 줍니다. 하지만 추상화 계층이 추가되어 기본 힌트와 응답을 가릴 수 있어 디버깅이 더 어려워지는 경향이 있습니다. 또한 실제로는 더 간단한 설정으로 충분할 수 있는데도 불구하고 복잡성을 증가시키는 결과를 초래할 수도 있습니다.

개발자는 먼저 LLM API를 직접 사용하는 것이 좋습니다. 코드 몇 줄로 많은 패턴을 구현할 수 있기 때문입니다. 프레임워크를 사용하는 경우 기본 코드를 이해해야 합니다. 프레임워크의 기본 로직에 대한 잘못된 가정은 클라이언트 오류의 일반적인 원인입니다.

참조 요리책 를 클릭해 몇 가지 샘플 구현을 확인하세요.

빌딩 블록, 워크플로 및 상담원

이 섹션에서는 프로덕션 환경에서 흔히 볼 수 있는 에이전트화된 시스템 패턴을 살펴보겠습니다. 기본 빌딩 블록인 향상된 LLM부터 시작하여 단순한 조합형 워크플로에서 자율 에이전트까지 점차 복잡성을 높여 보겠습니다.

빌딩 블록: 향상된 LLM

에이전트화된 시스템의 기본 구성 요소는 검색, 도구 및 메모리와 같은 향상된 기능을 통합하는 향상된 LLM입니다. 현재 모델은 자체 검색 쿼리를 생성하고, 적절한 도구를 선택하고, 보유할 정보를 결정하는 등 이러한 기능을 능동적으로 사용할 수 있습니다.

: 향상된 LLM

특정 사용 사례에 맞게 이러한 기능을 사용자 정의하고 사용하기 쉽고 잘 문서화된 LLM 인터페이스를 제공하는지 확인하는 두 가지 핵심 측면에 중점을 두고 구현하는 것이 좋습니다. 이러한 개선 사항은 여러 가지 방법으로 구현할 수 있지만, 최근 출시된 모델 컨텍스트 프로토콜을 사용하면 개발자가 간단한 클라이언트 측 구현을 통해 성장하는 타사 도구의 에코시스템에 통합할 수 있는 한 가지 방법이 있습니다.

이 백서의 나머지 부분에서는 모든 LLM 호출에서 이러한 개선 사항을 이용할 수 있다고 가정합니다.

워크플로: 프롬프트 체인

힌트 체인은 작업을 일련의 단계로 나누고, 각 LLM(대규모 언어 모델) 호출은 이전 단계의 출력을 처리합니다. 중간 단계마다 절차적 검사(아래 그림의 "게이트" 참조)를 추가하여 프로세스가 여전히 올바른 방향으로 진행되고 있는지 확인할 수 있습니다.

: 큐 체인 워크플로

이 워크플로를 언제 사용해야 할까요?
이 워크플로는 작업을 고정된 하위 작업으로 쉽고 명확하게 분류할 수 있을 때 이상적입니다. 주요 목표는 각 LLM 호출을 보다 관리하기 쉬운 작업으로 간소화하여 대기 시간을 줄이면서 정확도를 높이는 것입니다.

큐 체인이 적용되는 위치의 예입니다:

마케팅 카피를 생성한 다음 다른 언어로 번역하세요.
문서의 개요를 작성하고, 개요가 특정 기준을 충족하는지 확인한 다음 개요에 따라 문서를 작성합니다.

워크플로: 라우팅

라우팅은 입력을 분류하여 전문화된 후속 작업으로 안내합니다. 이 워크플로를 사용하면 우려 사항을 분리하고 보다 전문화된 프롬프트를 구성할 수 있습니다. 이 워크플로를 사용하지 않을 경우 한 가지 유형의 입력에 대해 최적화하면 다른 입력의 성능이 저하될 수 있습니다.

: 라우팅 워크플로

이 워크플로를 언제 사용해야 할까요?
라우팅 워크플로는 복잡한 작업에 개별적으로 처리해야 하는 다양한 카테고리가 있고 LLM 또는 보다 전통적인 분류 모델/알고리즘으로 분류를 정확하게 처리할 수 있을 때 잘 수행됩니다.

라우팅 적용 가능한 예시:

다양한 유형의 고객 서비스 문의(일반 문의, 환불 요청, 기술 지원)를 다양한 다운스트림 프로세스, 팁 및 도구로 안내하세요.
단순/일반적인 문제는 더 작은 모델로 라우팅(예 Claude 3.5 하이쿠), 복잡하고 흔하지 않은 문제는 더 강력한 모델(예: 클로드 3.5 소네트)로 라우팅하여 비용과 속도를 최적화합니다.

워크플로: 병렬화(병렬화)

LLM은 때때로 작업을 동시에 처리할 수 있으며, 그 출력은 프로그래밍 방식으로 집계됩니다. 병렬화된 워크플로에는 크게 두 가지 주요 변형이 있습니다:

섹션 나누기: 작업을 병렬로 실행할 수 있는 독립적인 하위 작업으로 분해하세요.
투표: 동일한 작업을 여러 번 실행하여 다양한 결과물을 얻으세요.

: 병렬화된 워크플로

이 워크플로를 언제 사용해야 할까요?
병렬화는 속도를 위해 분해된 하위 작업을 병렬로 처리할 수 있거나 신뢰도 높은 결과를 위해 다양한 관점이나 시도가 필요한 경우에 효과적입니다. 여러 가지 고려 사항이 있는 복잡한 작업의 경우, 일반적으로 각 고려 사항을 별도의 LLM 호출로 처리하여 각 특정 측면에 집중하는 것이 더 효과적입니다.

병렬화가 적용되는 예시입니다:

섹션 나누기:
- 한 모델 인스턴스는 사용자 쿼리를 처리하고 다른 모델 인스턴스는 부적절한 콘텐츠나 요청을 차단하는 안전장치를 구현하세요. 이는 일반적으로 동일한 LLM 호출이 가드와 핵심 응답을 모두 처리하는 것보다 낫습니다.
- LLM 성능 자동 평가: 각 LLM 호출이 주어진 큐에 대해 모델 성능의 다른 측면을 평가합니다.
투표:
- 코드에 취약점이 있는지 검토하고, 다양한 프롬프트를 통해 코드를 여러 번 확인하고, 발견된 문제에 플래그를 지정합니다.
- 콘텐츠의 부적절성을 평가하고, 여러 프롬프트를 사용하여 다양한 측면을 평가하거나, 오탐과 누락의 균형을 맞추기 위해 다양한 폴링 임계값을 요구합니다.

워크플로: 오케스트레이터-워커

코디네이터-워커 워크플로에서 센터 LLM은 작업을 동적으로 분해하여 워커 LLM에게 위임하고 그 결과를 종합합니다.

: 코디네이터-워커 워크플로

이 워크플로를 언제 사용해야 할까요?
이 워크플로는 작업이 복잡하고 필요한 하위 작업을 예측할 수 없을 때 매우 적합합니다(예: 변경할 파일 수와 각 파일의 변경 내용이 특정 작업에 따라 달라질 수 있는 코딩 작업). 병렬화된 워크플로우와 유사하지만 주요 차이점은 유연성입니다. 하위 작업은 미리 정의되어 있지 않고 특정 입력에 따라 코디네이터가 결정합니다.

코디네이터-워커 적용 예시:

한 번에 여러 파일을 복잡하게 변경하는 코딩 제품.
여러 출처에서 정보를 수집하고 분석하여 관련성이 있을 수 있는 정보를 찾는 검색 작업입니다.

워크플로: 평가자-옵티마이저

평가자-최적화기 워크플로에서는 하나의 LLM(대규모 언어 모델) 호출이 응답을 생성하고 다른 하나는 평가 및 피드백을 제공하여 루프를 형성합니다.

: 평가자-옵티마이저 워크플로

이 워크플로를 언제 사용해야 할까요? 이 워크플로는 명확한 평가 기준이 있고 반복적인 최적화를 통해 측정 가능한 가치를 제공할 때 특히 효과적입니다. 두 가지 적용 가능한 특징은 첫째, 사람이 피드백을 제공하면 LLM의 응답이 크게 개선될 수 있다는 점과 둘째, LLM이 그러한 피드백을 제공할 수 있다는 점입니다. 이는 사람이 세련된 문서를 작성할 때 반복적인 글쓰기 과정을 거치는 것과 유사합니다.

평가기-최적화기 적용 가능성의 예:

문학 번역의 경우 번역자 LLM이 처음에는 모든 뉘앙스를 포착하지 못할 수 있지만 평가자 LLM이 유용한 비평을 제공할 수 있습니다.
포괄적인 정보를 수집하기 위해 여러 차례의 검색과 분석이 필요한 복잡한 검색 작업으로, 평가자가 추가 검색이 필요한지 여부를 결정합니다.

인텔리전트/요원

복잡한 입력 이해, 추론 및 계획, 안정적인 도구 사용, 오류 복구와 같은 주요 기능에서 LLM이 성숙해짐에 따라 에이전트(에이전트)가 점차 프로덕션에 등장하고 있습니다. 에이전트는 인간 사용자의 지시를 받거나 대화형 토론을 통해 작업을 시작합니다. 작업이 명확해지면 에이전트는 독립적으로 계획하고 운영하며, 추가 정보나 판단을 위해 인간에게 다시 문의할 수도 있습니다. 실행하는 동안 에이전트는 진행 상황을 평가하기 위해 각 단계에서 환경으로부터 '실제 정보'(예: 도구 호출 또는 코드 실행 결과)를 얻어야 합니다. 에이전트는 사람의 피드백을 얻기 위해 체크포인트에서 또는 장애물을 만나면 일시 중지할 수 있습니다. 작업은 일반적으로 완료 시 종료되지만 제어를 유지하기 위해 중지 조건(예: 최대 반복 횟수)을 포함하는 경우가 많습니다.

에이전트는 복잡한 작업을 처리할 수 있지만 구현은 일반적으로 비교적 간단합니다. 도구 사용을 위한 환경 피드백 루프에 기반한 대규모 언어 모델일 뿐인 경우가 많습니다. 따라서 도구 세트와 그 문서를 설계할 때는 명확하고 신중하게 고려해야 합니다. 부록 2("도구를 위한 힌트 엔지니어링")에서 도구 개발을 위한 모범 사례를 자세히 설명합니다.

: 자율 에이전트

프록시 사용 시기: 에이전트는 필요한 단계 수를 예측할 수 없고 고정된 경로를 하드코딩할 수 없는 개방형 문제에 사용할 수 있으며, 여러 차례의 작업이 필요할 수 있으므로 에이전트의 의사 결정 기능에 대한 신뢰가 있어야 합니다. 에이전트의 자율성은 신뢰할 수 있는 환경에서 작업을 확장하는 데 매우 적합합니다.

에이전트의 자율성은 더 높은 비용과 오류 누적의 잠재적 위험을 수반합니다. 적절한 보안 조치가 마련되어 있는 샌드박스 환경에서 광범위한 테스트를 수행할 것을 권장합니다.

프록시 적용 예시:

다음 예시는 실제 구현한 것입니다:

작업 설명에 따라 여러 파일을 편집해야 하는 SWE 벤치 작업을 해결하기 위한 코딩 에이전트입니다;
우리의 "컴퓨터 사용" 참조 실현이 경우 클로드는 컴퓨터를 사용하여 작업을 완료했습니다.

: 에이전트 코딩을 위한 높은 수준의 프로세스

다음 모델을 결합하고 사용자 지정

이러한 빌딩 블록은 필수는 아닙니다. 개발자가 다양한 사용 사례에 맞게 조정하고 결합할 수 있는 일반적인 패턴입니다. 다른 LLM 기능과 마찬가지로 성공의 열쇠는 성능을 측정하고 구현을 반복하는 것입니다. 다시 한 번 강조하지만, 복잡성을 추가하는 것은 결과를 크게 개선하는 경우에만 고려해야 합니다.

초록

LLM(대규모 언어 모델링) 분야의 성공은 가장 복잡한 시스템을 구축하는 것이 아니라 고객의 요구에 가장 적합한 시스템을 구축하는 것입니다. 간단한 힌트로 시작하여 철저한 평가를 통해 최적화하고, 간단한 솔루션으로 요구 사항을 충족하지 못할 경우에만 다단계 에이전트 시스템을 추가하세요.

프록시를 구현할 때는 세 가지 핵심 원칙을 따릅니다:

에이전트 설계 유지 관리 단순성 .
에이전트의 계획 단계를 명확하게 보여줌으로써 계획 단계의 우선 순위를 정합니다. 투명성 .
세부 도구를 통해 문서화 및 테스트 상담원-컴퓨터 인터페이스(ACI)를 신중하게 설계하세요.

프레임워크를 사용하면 빠르게 시작할 수 있지만 프로덕션으로 이동할 때는 추상화 계층을 줄이고 기본 구성 요소로 빌드하는 것을 주저하지 마세요. 이러한 원칙을 따르면 강력할 뿐만 아니라 안정적이고 유지 관리가 쉬우며 사용자가 신뢰할 수 있는 에이전트를 만들 수 있습니다.

감사 메모

이 백서는 Erik Schluntz와 Barry Zhang이 작성했습니다. 이 작업은 다음 작업을 기반으로 합니다. 인류학 에이전트를 구축한 경험과 고객이 공유해 주신 소중한 인사이트에 깊은 감사를 드립니다.

부록 1: 프록시의 실제 적용 사례

고객과의 협력을 통해 위에서 설명한 패턴의 실질적인 가치를 입증하는 두 가지 유망한 AI 에이전트 활용 사례를 발견했습니다. 이러한 애플리케이션은 대화와 행동의 조합이 필요하고, 명확한 성공 기준이 있으며, 피드백 루프를 지원하고, 효과적인 인간 감독을 가능하게 하는 작업에서 에이전트가 가장 유용하다는 것을 보여줍니다.

A. 고객 지원

고객 지원은 친숙한 챗봇 인터페이스와 도구 통합을 위한 향상된 기능을 결합합니다. 이 시나리오는 보다 개방적인 상담원에게 적합합니다:

대화 흐름을 자연스럽게 따르는 상호작용을 지원하면서 외부 정보에 액세스하고 작업을 실행해야 합니다;
도구를 통합하여 고객 데이터, 주문 내역 및 지식창고 문서를 추출할 수 있습니다;
환불 처리나 작업 지시서 업데이트와 같은 작업은 프로그래밍 방식으로 처리할 수 있습니다;
사용자 정의 솔루션으로 성공 여부를 명확하게 측정할 수 있습니다.

몇몇 회사는 성공적으로 해결된 사례에 대해서만 요금을 부과하는 사용량 기반 요금 모델을 통해 이 접근 방식의 실행 가능성을 입증하여 대행사의 효과에 대한 확신을 보여주었습니다.

B. 프로그래밍 에이전트

소프트웨어 개발 분야는 코드 완성에서 자율적 문제 해결로 진화하면서 LLM 기능에 대한 상당한 잠재력을 보여주었습니다. 에이전트가 특히 효과적인 이유는 다음과 같습니다:

코드 솔루션은 자동화된 테스트를 통해 검증할 수 있습니다;
상담원은 테스트 결과를 피드백으로 사용하여 솔루션을 반복할 수 있습니다;
문제 영역은 명확하고 구조화되어 있습니다;
출력물의 품질을 객관적으로 측정할 수 있습니다.

우리 구현에서 프록시는 풀 리퀘스트 설명을 기반으로 풀 리퀘스트 설명을 개별적으로 해결할 수 있었습니다. SWE 벤치 검증 벤치마킹의 실제 GitHub 문제. 그러나 자동화된 테스트는 기능을 검증하는 데 도움이 될 수 있지만, 솔루션이 더 광범위한 시스템 요구 사항을 충족하는지 확인하려면 여전히 수동 검토가 필수적입니다.

부록 2: 툴팁 프로젝트

어떤 종류의 에이전트 시스템을 구축하든 도구는 에이전트에서 중요한 부분일 것입니다. 도구를 사용하면 Claude가 정확한 구조와 정의를 지정하여 외부 서비스 및 API와 상호 작용할 수 있습니다. 클로드가 응답할 때 도구를 호출할 계획이 있는 경우 API 응답에 도구 사용 블록 . 도구 정의와 사양은 전반적인 프롬프트만큼이나 프롬프트 엔지니어링의 대상이 되어야 합니다. 이 부록에서는 도구를 힌트 엔지니어링하는 방법에 대해 간략하게 설명합니다.

일반적으로 동일한 작업을 지정하는 방법에는 여러 가지가 있습니다. 예를 들어, diff를 쓰거나 전체 파일을 다시 작성하여 파일 편집을 지정할 수 있습니다. 구조화된 출력의 경우 마크다운으로 코드를 반환하거나 JSON으로 코드를 반환할 수 있습니다. 소프트웨어 엔지니어링에서 이러한 차이는 외관상의 차이일 뿐이며 손실 없이 서로 변환할 수 있습니다. 그러나 일부 형식은 다른 형식보다 LLM이 작성하기 더 어렵습니다. 예를 들어, 차이를 작성하려면 새 코드를 작성하기 전에 블록 헤더에서 몇 줄이 변경되는지 알아야 합니다. (마크다운과 달리) JSON으로 코드를 작성하려면 줄 바꿈과 따옴표를 추가로 이스케이프해야 합니다.

도구의 형식에 대한 권장 사항은 아래에 나와 있습니다:

모델에 충분한 시간 제공 토큰 "틀에 박히지 않도록 '생각'하세요.
서식을 모델이 인터넷에서 자연스럽게 볼 수 있는 텍스트에 가깝게 유지합니다.
수천 줄의 코드를 정확히 계산해야 하거나 작성된 코드를 이스케이프 처리해야 하는 등 형식에 '추가 부담'이 없는지 확인하세요.

경험상 인간-컴퓨터 인터페이스(HCI)에 얼마나 많은 노력이 들어가는지 고려하고, 또한 좋은 책임 있는 위치에서 SB를 대신하여 행동합니다. -컴퓨터 인터페이스(ACI)에도 동일한 노력을 기울입니다. 다음은 몇 가지 제안 사항입니다:

모델 측면에서 생각하세요. 설명과 매개변수에 따라 이 도구를 사용하는 것이 분명한가요? 신중한 고려가 필요하다면 모델에 대해서도 마찬가지일 것입니다. 좋은 도구 정의에는 일반적으로 사용 예시, 경계 사례, 입력 형식 요구 사항, 다른 도구와의 명확한 경계가 포함됩니다.
매개변수의 이름이나 설명을 어떻게 하면 더 명확하게 변경할 수 있을까요? 팀의 주니어 개발자를 위해 훌륭한 문서 노트(문서 스트링)를 작성한다고 생각하세요. 이는 유사한 도구를 여러 개 사용할 때 특히 중요합니다.
워크벤치에서 다양한 샘플 입력을 실행하고, 모델이 어떤 실수를 하는지 관찰하고, 반복하여 모델이 도구를 사용하는 방식을 테스트하세요.
포카 요크 도구. 매개변수를 변경하여 실수하기 어렵게 만드세요.

SWE 벤치용 에이전트를 구축할 때 실제로 전체 프롬프트 최적화보다 툴을 최적화하는 데 더 많은 시간을 할애했습니다. 예를 들어 상대 파일 경로를 사용하는 도구는 에이전트가 루트 디렉터리 밖으로 이동했을 때 오류가 발생하기 쉽습니다. 이 문제를 해결하기 위해 항상 절대 파일 경로가 필요하도록 도구를 변경했는데, 이 접근 방식을 사용해도 모델에 전혀 문제가 없다는 것을 확인했습니다.