Building effective agents

25년은 에이전트 해가 될거라고 하지만 Agent서비스나 플랫폼들이 나오는걸 보면 아직은 잘 모르겠다는 생각이 든다.
리뷰논문을 작성해보고 하는 일을 되돌아보면서 드는 생각은.. 현재 니즈는 '대화'를 통해서 봇,에이전트라는 개념이 하이브리드의 접근이 비용이나 속도 측면에서도 효율적이지 않을까 싶다.
하이브리드 측면의 접근이 라우팅이라는 개념으로 나오게된것 같다는 생각이다. 플래닝과 수행능력이 있는 모델을 선택하는것인데 이 비율을보면 현 시대를 사는 사용자들의 행동패턴이 보일것같다.

여튼.. 그렇게 생각하는 이유는 나 역시도 난이도가 높거나 또는 맞춤형과 같은 요구사항을 하고 있진 않다. 아마도 검색에 익숙한 세대이기 때문이지 않나 싶다. 검색을 해서 정보를 이해하는 세대였으니까 말이다.
그래서 궁금한걸 물어보는 행위 = 검색으로 해소 --> 시키는 행위가 습관화 되는 세대일때 비로소 에이전트가 의미잇지 않을까 싶다.

시키는 행위를 하려면 나의 메모리 / 그리고 내가 인터렉션하는 에이전트 / 나의 에이전트가 갖는 툴(스킬)에 어떤게 있는지, '툴'쪽에 투자하는것이 승산이 있지 않을까 싶다. 
에이전트를 사고파는 개념보다 특별한 스킬=툴=펑션=플러그인 을 개발하는게 사업승산이 있지 않을까 싶다. 뭐 지극히 내생각 ㅎ

---

앤트로픽은 LLM을 활용한 프로그램을 아래와 같이 크게 두 가지로 구분

• 워크플로우(Workflow) - 개발자가 사전에 정의한 코드 흐름으로 LLM과 도구를 활용하는 시스템
  • 예, 고객상담챗봇이 정해진 응답 트리에 따라 작동하는 경우를 말함
• 에이전트(Agent) - 작업을 완료하기 위해 필요한 경로, 도구 사용 여부 등을 LLM이 스스로 선택하는 시스템
  • 예, 데이터 분석 에이전트가 상황에 따라 필요한 도구를 선택하고 분석하는 방법을 결정하는 경우

에이전트 사용시 고려사항으로

• 지연 시간과 비용이 증가하더라도 작업 성능향상이 필요한 경우에만 에이전트 시스템을 도입
• 고객 서비스 봇을 만든다고 하면
  • (1)단순한 QnA봇 → (2)필요한 경우 정해진 워크플로우 추가 → (3)더 복잡한 상황처리가 필요할때 에이전트로 발전
• 지난번 매출이 안좋았던 이유를 알고싶어. 의 고객을 응대해야 한다고 하면
  • 이런 요청을 처리하려면:
    • 매출 데이터 분석이 필요한지
    • 시장 상황 확인이 필요한지
    • 고객 피드백을 봐야 하는지
    • 어떤 메트릭을 중점적으로 봐야 하는지 을 미리 정의하기는 어렵다.
  • 미리 예상이 되는케이스 = (1),(2) 그렇지 않은 경우 (3)번만 에이전트로 처리 할수도 있겠다. 이렇게 복잡한 요청을 지인/비지인 기반에 대화에 얼마나 차지할까 싶다.

분석Agent를 예로 들면

AugmentedLLM?

• LLM에 메모리, 툴, 검색(지식)을 증강하는것을 말한다. 
• 툴은 에이전트가 수행할수있는 본인의 스킬셋과 같은 것이고, 검색이 필요한 지식을 아규먼티드 할수 있고, 해당 에이전트가 주변을 인지할수있는 메모리가 요즘 주된 Agent에서 사용되는 빌딩블록이라고 볼수 있다.

프롬프트 체이닝

• 개념: 작업을 순차적인 단계로 분해하여 각 LLM 호출이 이전 단계의 출력을 처리
• 특징: 중간에 Gate(검증 단계)를 두어 프로세스가 올바른 방향으로 진행되는지 확인 가능
• 사용 시기: 작업이 명확한 하위 작업으로 나눌 수 있을 때

라우팅

• 개념: 입력을 분류하여 전문화된 후속 작업으로 연결 = 어떤 모델이 이 작업을 더 효율적으로 처리할수 있는가?
• 특징: 각 유형별로 최적화된 프롬프트와 도구 사용 가능
• 사용 시기: 복잡한 작업을 distinct한 카테고리로 구분할 수 있을 때
  • 고객 서비스 문의를 일반 질문/환불 요청/기술 지원으로 분류
  • 난이도에 따라 다른 모델로 라우팅(간단한 질문은 Haiku, 복잡한 질문은 Sonnet) → 다른 모델로 라우팅을 한다는것은 ""플래닝과 실행능력"" 을 기준으로 해야 하지 않을까?

병렬화

• 개념: 여러 LLM이 동시에 작업하고 결과를 통합
• 두 가지 방식:
  • Sectioning: 독립적인 하위 작업으로 나누어 병렬 처리
  • Voting: 같은 작업을 여러 번 수행하여 다양한 결과 얻기
• 사용 시기
  • 작업을 병렬로 처리할 수 있거나
  • 여러 관점이나 시도가 필요할 때
• 예시:
  • 가드레일: 한 모델은 쿼리 처리, 다른 모델은 부적절 콘텐츠 스크리닝
  • 코드 취약점 검토: 여러 프롬프트가 각각 다른 관점에서 검토

• 코드로 이해를 더해보면 다면평가나 컨텐츠 모더레이션은 병렬처리라고 볼수 있다. 물론 이러한 병렬화는 비용과 복잡성이 증가한다. 따라서 정확성과 신뢰성이 매우 중요한 경우에 주로 사용하면 좋겠다.
  • 다면평가

오케스트레이터-워커

• 중앙의 LLM(Large Language Model)이 동적으로 작업을 분해하고, 이를 작업자(worker) LLM들에게 위임한 후, 그들의 결과를 종합하는 워크플로우다.
  
  1. 입력(In) → 작업이 시작되는 지점
  2. 오케스트레이터(Orchestrator) → 작업을 분석하고 하위 작업으로 분할
  3. LLM 호출(LLM Calls) → 여러 작업자 LLM들이 병렬로 작업 수행
  4. 합성기(Synthesizer) → 개별 결과들을 종합
  5. 출력(Out) → 최종 결과물 도출
• 워크플로우 구조
• 언제쓰면 적합한가?
  
  • 이 워크플로우는 다음과 같은 상황에서 특히 유용합니다
    • 하위 작업들을 미리 정의할 수 없는 복잡한 작업
    • 입력에 따라 필요한 작업이 동적으로 변하는 경우
    • 병렬화가 가능하지만 유연성이 필요한 경우
  • 주로 사용되는경우가 코드 수정작업, 정보를 검색 한 후 '분석' 해야 하는 경우 (자동화시스템이 필요한 = 진단을 하거나, 리포트나 상담씬이 맞겠지)

워크플로우 - Evaluation & Optimizer

• 개념 : 평가자-최적화 도구 워크플로우에서는 하나의 LLM 호출이 응답을 생성하고, 다른 하나는 루프 내에서 평가와 피드백을 제공
• 이 워크플로우를 사용해야 하는 경우?
  1. 이 워크플로우는 
     1. 명확한 평가 기준이 있을 때
     2. 반복적인 개선이 측정 가능한 가치를 제공할 때
     
     
     1. 사람이 피드백을 제공할 때 LLM 응답이 입증 가능하게 개선될 수 있다는 점
     2. LLM이 그러한 피드백을 제공할 수 있다는 점 두 가지 적합성 판단 기준?
• 이는 인간 작가가 문서를 다듬어가는 반복적인 작성 과정과 유사하다. 대규모 콘텐츠 생성 파이프라인, 문서 자동화 시스템, 품질 보증이 중요한 콘텐츠를 최적화할때, 장기적인 데이터 분석 프로젝트에 적합하겠다. 
• 예를 들면
  1. 문학 번역
     • 번역기 LLM이 처음에는 포착하지 못할 수 있는 뉘앙스가 있는 경우
     • 평가자 LLM이 유용한 비평을 제공할 수 있는 경우
  2. 복잡한 검색 작업
     • 포괄적인 정보를 수집하기 위해 여러 단계의 검색과 분석이 필요한 경우
     • 평가자가 추가 검색이 필요한지 결정하는 경우
• 장점은 
  • 지속적인 품질 개선
  • 자동화된 품질 관리
  • 특정 도메인이나 컨텍스트에 맞는 최적화 가능
  • 일관된 평가 기준 적용
• 적합하지 않은 예로는
  • 채팅봇, 실시간성 = 즉각적인 응답이 필요한경우에는 적합하지 않겠다.

그래서 Agents?

• 에이전트는 llm이 다음과 같은 핵심 기능들에서 검토되고 있다.
  • 복잡한 입력을 이해
  • 추론과 계획을 수행
  • 도구의 신뢰성 있는 사용
  • 오류로부터의 복구
• 그럼 에이전트 사용이 적합한 경우는 언제일까?
  • 필요한 단계 수를 예측하기 어려운 경우
  • 고정된 경로를 하드코딩할 수 없는 상황
  • llm이 여러턴에 걸쳐 작동해야 하는 경우
  • 의사결정에 대한 신뢰도가 확보된 경우

랭체인팀의 에이전트관련된 기술 블로그를 읽어보면, llm이 작업흐름을 결정하는 경우 = 개발자가사전에 흐름을 정의하고 llm이 그중에 하나를 선택하는 경우 - 즉 이 범위부터 에이전트로 본다.
대부분 기본적인 대화와 정보를 교환하거나 간단한 문의성이 대부분일것이다.  그럼 우리는 어떤 에이전트를 만들어야 할까?

PersonalAssistantAgent 개인비서

GroupAssistantAgent

• 복잡한 의사결정 지원
  • 여러 사람의 의견 취합
  • 데이터 기반 분석 필요
  • 다양한 정보원 참조 필요
• 프로젝트 관리 지원 = 협업을 돕는 에이전트

하이브리드접근이 필요한 Agent

비용과 속도에 따른 효율성을 위해 하이브리드접근이 필요한 케이스가 아래와 같지 않을까 싶다.
일반적인 문의 = 단순한 워크플로우로 충분히 가능한다. 이외 fallback으로 볼수 있는것에만 에이전트를 활용하는것이다. 예를 들면 '우리 아이 상황에 맞는 학습 플랜 짜줘', '체형과 취향에 맞는 전체 코디 추천해줘' '학습진단하고 장기적인 플래닝을 세워줘'

ParentingAdvisorAgent

LLM 패턴 조합

원칙이라고 할수는 없지만, 투명성 = 의사결정과정을 단계적으로 명시적으로 보여주는것이 중요하다고 생각한다. step.설명 , step.reasoning, step.expected_outcome

 
B2B씬에서 고객상담 에이전트를 예시로 두고, 글을 마무리 한다.

 
 
부록

• 앤트로픽 https://www.anthropic.com/research/building-effective-agents
• 랭체인팀 에이전트https://blog.langchain.dev/what-is-an-agent/
• openai 오케스트레이션 https://cookbook.openai.com/examples/orchestrating_agents