모두가 프롬프트에 대해 이야기합니다. 하지만 에이전트가 실제로 실패하는 지점은 바로 '루프(Loop)'입니다.
프롬프트 엔지니어링이 모든 관심을 독차지하고 있습니다. 사람들은 프롬프트를 공유하며 똑똑해진 기분을 느낍니다. 하지만 제가 구축하는 에이전트 시스템(agentic systems)에서 실패하는 것은 프롬프트가 아닙니다. 바로 루프입니다.
에이전트는 단 한 번의 프롬프트와 응답으로 이루어지지 않습니다. 그것은 하나의 루프입니다.
- 상태를 관찰합니다.
- 행동을 취합니다.
- 결과를 평가합니다.
- 계속할지 멈출지 결정합니다.
이 단계 중 하나라도 실패하면 에이전트는 실패합니다. 저는 이를 연구하기 위해 1,412번의 실행을 통해 12개의 모델을 분석했습니다. 루프가 실패하는 방식과 이를 해결하는 방법을 소개합니다.
일반적인 루프 실패 사례:
- 토큰 스파이럴(Token Spirals): 에이전트가 같은 말을 반복하며 너무 많은 토큰을 사용합니다.
- 사각지대(Blind Spots): 에이전트가 환경을 제대로 파악하지 못해 같은 실수를 반복합니다.
- 거짓 성공(False Success): 에이전트가 틀린 답을 내놓고도 그것이 맞다고 생각합니다.
- 막다른 길(Dead Ends): 에이전트가 오류를 발견했지만, 그 데이터를 개선에 활용하지 못합니다.
더 나은 프롬프트로는 이러한 문제를 해결할 수 없습니다. '루프 엔지니어링(loop engineering)'이 필요합니다.
더 나은 루프를 위한 네 가지 설계 원칙:
- 루프 제한(Bound the loop): 반복 횟수와 토큰 사용량에 엄격한 제한을 둡니다. 에이전트가 한계에 도달하면 반드시 멈추고 도움을 요청해야 합니다.
- 환경을 명확하게 만들기(Make the environment legible): '관찰(observe)' 단계에서 에이전트에게 모든 사실을 제공하는지 확인합니다. 에이전트가 실패하는 행동을 반복한다면, 이는 적절한 정보가 부족하기 때문입니다.
- 실행자와 평가자 분리하기(Separate the actor from the evaluator): 동일한 모델이 자신의 작업물을 검토하게 하지 마십시오. 다른 모델을 사용하거나 규칙 기반(rule-based) 체크를 통해 출력을 판단해야 합니다.
- 루프 닫기(Close the loop): 오류를 실제 수정으로 이어지게 만듭니다. 루프가 실패하면 다시는 같은 일이 발생하지 않도록 회귀 테스트(regression test)를 추가하십시오.
저는 이 규칙들을 사용하여 RelayOps라는 지원 에이전트를 구축했습니다. 우리는 에이전트를 평가하기 위해 독립적인 판정관(independent judge)을 사용했습니다.
한 번은 에이전트가 올바른 문서를 인용했지만, 실제 질문에는 답하지 못한 적이 있었습니다. 단순한 규칙 기반 체크는 이를 통과시켰지만, 우리의 독립적 평가자는 이를 잡아냈습니다. 우리는 그 실패를 바탕으로 시스템을 수정했고, 같은 일이 재발하지 않도록 테스트를 추가했습니다.
에이전트가 더 똑똑해질 필요는 없었습니다. 루프가 더 잘 설계되어야 했습니다.
프롬프트에만 집중하는 것을 멈추십시오. 구조에 집중하십시오.
여러분은 어떤 루프 실패를 경험해 보셨나요? 토큰 스파이럴, 사각지대, 아니면 확신에 찬 오답을 내놓는 에이전트였나요?
Optional learning community: https://t.me/GyaanSetuAi