Abstract:
- 새로운 에이전트 프레임워크를 소개하는 논문임.
- TapeAgents는 “테이프(tape - Structured log)” 라는 개념을 중심으로 동작
- 테이프를 이용하면 Agent 를 개발할 때, 운영할 때 다 이점이 있다고 함.
- 테이프: 에이전트가 수행한 “생각(thought)”과 “행동(action)”, 그리고 환경에서 받은 “관찰(observation)”을 모두 순차적으로 기록하는 일종의 로그이자 상태(state).
- 그래서 중단된 시점부터 재시작(resumable)이 가능하고, 에이전트의 실행 과정을 완전히 디버깅할 수 있음.
- 개발 단계에서 이점:
- 테이프를 통해 에이전트가 어떤 과정을 거쳐 행동을 결정했는지 한눈에 파악가능.
- 에이전트가 생각 단계에서 어떤 연산(추론)을 했고, 어떤 출력(행동)을 했는지 투명하게 확인 가능함. tracking 이 가능하다.
- 테이프가 곧 세션 정보이므로, 에이전트가 어디까지 작업했는지 기록하고, 이후 다시 이어서 실행할 수 있음.
- 배포 후 이점:
- 에이전트가 만든 테이프 기록을 그대로 다시 검토하거나 재생해볼 수 있으므로, 성능 분석과 평가를 쉽게 할 수 있음.
- 과거 기록된 테이프(에이전트의 실행 과정 및 로그)를 활용하여 LLM 을 파인튜닝 해보거나 프롬프트를 수정할 수 있음.
- 여러 에이전트를 함께 사용할 때, 테이프 구조를 통해 한 에이전트의 결과(로그)를 쉽게 다른 에이전트에 전달하고 재활용할 수 있음.
- 다른 Agent 프레임워크와의 주요 차이:
- 모든 기록을 로그로 남겨둔다는 것과 이를 활용해서 프롬프트 최적화와 파인튜닝에 이용할 수 있다는 것.
- 그러면 이 테이프는 영속적인가? 그렇다면 언제 플러쉬를 하는거지?
- 사례 연구:
- 논문에서는 Llama-3.1-8B 모델을 예시로 들어, TapeAgents 방식으로 파인튜닝하여 GPT-4 수준의 성능을 달성하면서도, 비용은 훨씬 저렴하게 만드는 사례를 보고
Introduction:
- 기존 에이전트 프레임워크의 흐름:
- LangChain, CrewAI, AutoGen 등: 로우코드(low-code) 형태로 빠르게 에이전트를 구성할 수 있도록 도와주는 프레임워크, 프롬프트 체이닝, 멀티 에이전트 구성을 쉽게 가능.
- LangGraph: 에이전트 실행 중단-재시작(resumability), 비동기 실행, 병렬 처리, 분석(instrumentation)을 저수준에서 지원
- DSPy, TextGrad, Agents(Zhou 등): 데이터 기반 최적화(모델 파인튜닝, 프롬프트 튜닝)를 중심으로 한 연구용 프레임워크, 그러나 상대적으로 개발 단계에서의 디버깅과 로깅, 운영상의 편의성은 덜 지원됨.
- TapeAgents 는 양쪽을 포괄하는 Holsitic 접근을 함:
- TapeAgents는 테이프(tape) 라는, 에이전트 세션 내의 모든 단계별 기록을 남기는 방식을 근간으로 삼아 두 가지 큰 목표를 달성:
- 에이전트 개발 지원: 디버깅, 모니터링, 세션 유지(resumability), 단계별 실행 제어 등
- 데이터 기반 최적화 지원: 파인튜닝, 프롬프트 튜닝, 재학습, 재사용 가능한 로그 등
- TapeAgents는 테이프(tape) 라는, 에이전트 세션 내의 모든 단계별 기록을 남기는 방식을 근간으로 삼아 두 가지 큰 목표를 달성:
- 테이프(tape)의 구조와 동작 방식:
- TapeAgents에서는 에이전트가 생각(thought)과 행동(action)을 테이프에 기록하고, 환경은 이에 대한 관찰(observation)을 테이프에 추가함.
- 오케스트레이터(orchestrator): 에이전트와 환경이 번갈아가며 테이프를 업데이트하도록 관리하며, 원하는 시점에서 에이전트의 상태를 재시작(resume) 가능하게 함.
- 테이프는 각 단계가 어느 구성 요소(모델 파라미터, 특정 프롬프트 설정 등)로부터 기인했는지까지 담고 있어, 데이터 분석과 자동화된 최적화에 쓰일 수 있음.
- TapeAgents 툴체인과 활용 예시:
- TapeAgents의 “Studio” 툴(개발·디버깅)을 이용해 쉽게 에이전트를 구축하고, “Optimize” 툴(최적화)을 통해 테이프 데이터를 활용하여 모델 및 프롬프트를 개선하는 과정을 설명
- 단일(monolithic) 에이전트, 멀티 에이전트 팀 구성, 함수형 프롬프트 등 다양한 예시가 등장
TapeAgents - Foundation (기초):
- 에이전트는 노드라는 최소 LLM 호출 단위로 구성됨. 그리고 각 노드가 만들어내는 Step은 Tape 에 기록됨.
- TapeAgents 구조 개요:
- 오케스트레이터(orchestrator):
- 에이전트와 환경(environment) 간 상호작용을 번갈아가며 실행하고, 스텝을 테이프에 추가하도록 관리하는 주체임. 이를 통해 중간에 멈춘 에이전트를 재시작(resume) 할 수 있고, 개발자가 디버깅하기도 수월해짐.
- 에이전트(Agent):
- 내부에 여러 개의 노드(node)로 구성됩니다. 각 노드는 LLM 호출 단위 + 해당 출력의 후처리(symbolic processing) 로직을 캡슐화
- 여러 노드가 모여 하나의 에이전트를 이루고, 여러 에이전트가 팀(team) 형태로 협력할 수도 있음.
- 여러개의 노드가 있는 이유는??
- 환경(Environment):
- 에이전트가 내리는 액션(action)에 반응하여 관찰(observation) 을 테이프에 추가
- 테이프(Tape):
- 에이전트와 환경이 생성하는 스텝들을 모두 기록하는 순차적, 구조화된 로그입니다. 테이프에 기록되는 각 스텝은 에이전트의 기억이 됨.
- 오케스트레이터(orchestrator):
- 노드(Node):
- 노드는 한 번의 LLM 호출과 해당 출력 결과를 처리하는 로직을 한 덩어리로 묶은 “지능의 최소 단위”
- 예: “LLM에게 질문을 던지고, 답변을 받아서 다음 액션을 결정하는 로직”을 하나의 노드로 만들 수 있음.
- make_prompt 메서드:
- 노드는 LLM 호출을 위해 프롬프트(prompt)를 생성하는 메서드(함수)인 make_prompt(self, agent, tape)를 가짐.
- 만약 LLM 호출이 필요 없는 노드라면, 기본 구현(널 프롬프트)을 사용해도 됨.
- generate_steps 메서드:
- LLM 출력(또는 null)을 받아, 실제 스텝(step) 객체를 생성하는 메서드
- 시그니처: generate_steps(self, agent, tape, llm_stream) -> Generator[Step | PartialStep]
- 최종적으로 생성된 Step 객체(생각, 액션 등)는 테이프에 추가됨.
- Nodes That Can Make Training Data:
- 어떤 노드는 역방향(Reverse)의 기능도 지원해, “특정 스텝을 만들어내기 위해 LLM 출력이 어떻게 되었어야 하는가”를 산출할 수 있음.
- 이 기능은 파인튜닝을 위해 필요한 데이터를 추출하는데 사용됨.
- 스텝(Step):
- 생각(Thought):
- 에이전트의 내부 추론 단계(계획 수립, 사고 과정 등)
- 액션(Action):
- 외부에 영향을 주는 요청(예: 툴(tool) 호출, API 호출 등).
- 관찰(Observation):
- 환경이 에이전트의 액션에 응답하여 제공하는 정보.
- 생각(Thought):
- Agents:
- TapeAgent 에이전트는 agent.run(tape) 호출 시, 내부의 반복 추론 루프(iterative reasoning loop)를 돌면서 노드를 선택하고 실행하고 노드가 생성하는 step(생각/액션/관찰) 을 현재 테이프에 계속해서 추가해나감. (이 과정은 노드는 make_prompt와 generate_steps로 프롬프트를 만들고, Step을 생성하는 것을 포함)
- 에이전트의 기본 실행 흐름:
- 기본적으로 에이전트는 소유한 노드들을 순서대로 실행 (Agent 가 테이프에 기록된 step 을 보고 적절한 노드를 고르는게 아니네)
- 다만, 만약 이전 노드가 SetNextNode 같은 특정 Step(“다음에 이 노드를 실행하라”)을 만들면, 순차 실행 대신 그 지시에 따라 노드 실행 순서가 변경될 수 있음.
- 에이전트가 노드를 실행해 Step을 생성하는 중, 만약 생각(Thought)만 나오면 에이전트는 계속 노드를 실행(즉, 내부 루프를 계속)합니다
- 하지만 액션(Action) Step이 나오면, 에이전트는 그 시점에서 중단을 선언하고(정확히는 “액션이 만들어졌으니 일단 멈춘다”는 식), 새로 생성된 Step이 추가된 테이프를 반환
- 반환되는 결과: agent.run(tape) 호출 시, 최종적으로는 “새로운 Step들이 추가된 테이프”가 반환 (사실상, 더 정확히는 AgentStream이라는 객체가 반환되고, 그 안의 get_final_tape() 메서드로 “완성된 테이프”를 얻을 수 있음)
- 에이전트 간 계층 구조 및 협업 (Manager - Subagent):
- 한 에이전트가 다른 에이전트를 하위 에이전트(subagent)로 둘 수 있으며, 이 하위 에이전트도 또 다른 하위 에이전트를 가질 수 있는 트리 구조가 가능.
- 맨 위(root) 는 매니저가 없는 루트 에이전트가 존재
- 에이전트들은 테이프에 “Call”이나 “Respond” 같은 스텝(일종의 생각/Thought 형태)으로 상호 요청을 주고받음. 예를 들어, 루트 에이전트(또는 상위 에이전트) A가 “Call(agent_name=‘B’, content=…)”라고 하면, 테이프에는 A가 B를 호출하는 Step이 기록 그 후 B 에이전트가 일을 마치고 “Respond(content=…)” Step을 테이프에 추가하면, 다시 A가 활성화되어 계속 진행
- 오케스트레이션(Delegation) 로직으로 테이프를 살펴보고 가장 최근에 Call을 받았지만 아직 Respond하지 않은 에이전트가 있다면, 그 에이전트를 다음 실행 주체로 선택
- TapeView:
- 기본적으로 TapeAgents 는 하나의 테이프레 모든 에이전트의 상태를 통합해서 저장
- 전통적으로라면, 각 에이전트가 독립적인 메모리를 가지겠지만, TapeAgents는 하나의 “공유 테이프” 구조 안에서 에이전트별 뷰(view)만 달리 보는 방식으로 구현합니다.
- Tape View Stack:
- 멀티에이전트 시나리오에서, 특정 에이전트 A가 자신의 활동 범위에 해당하는 테이프 내용만 볼 수 있도록 뷰(View) 를 제공
- 예를 들어, 에이전트 A가 새로 “Call”되어 활성화된 시점부터, A가 다른 서브에이전트(하위 에이전트)를 호출할 때까지(=하위 에이전트의 내부 내용은 제외) 스텝들만 볼 수 있게 할 수도 있습니다(그림 3 예시).
- 기본 구현에서는 “가장 최근 Call 스텝부터 해당 에이전트가 Respond하기 전까지”를 Tape View로 설정하는데, 이는 파이썬의 call stack과 유사합니다.
- 문맥상 에이전트는 파이썬의 함수(function)와 유사, 노드는 함수 내부의 코드 한 줄, 스텝은 바이트코드 수준의 명령, Tape View Stack 은 파이썬의 호출 스택
- Optimizable Agents:
- TapeAgents는 에이전트가 사용하는 프롬프트나 구조(구성) 을 바꿔서 성능을 높이는 연구를 지원 (프롬프트 튜닝, 파인튜닝, 구조 변경)
- Agent 모델에 반드시 포함되어야 하는 필드:
- llms: 사용하는 LLM 구성(어떤 LLM, 어떤 파라미터 등)
- templates: 프롬프트 템플릿(문자열 템플릿 등)
- nodes: 노드 목록(어떤 노드가 어떤 순서로 구동되는지)
- subagents: 하위 에이전트 목록
- 학습 데이터 생성 (make_training_text):
- TapeAgents의 에이전트는 자신이 사용한 LLM 호출 기록(프롬프트와 응답)을 재구성해서 학습용 텍스트로 만들 수 있음.
- agent.make_training_text(tape) 메서드:
- 주어진 테이프에서 LLM 호출을 추출
- 해당 호출(및 생성 스텝)을 재생(replay)하여 올바른 결과를 만드는지 검사
- 최종적으로 “학습 텍스트”를 반환
- Environment:
- 에이전트의 액션(Action)에 대응하여 관찰(Observation) 스텝을 테이프(tape)에 추가합니다
= def react(self, tape) -> Tape 메소드를 통해 실행됨. 이 메서드는 테이프에 아직 처리되지 않은(unfulfilled) 액션들을 확인하고, 그 액션들에 해당하는 관찰(Observation) 스텝을 생성해 테이프에 추가.
- 에이전트의 액션(Action)에 대응하여 관찰(Observation) 스텝을 테이프(tape)에 추가합니다
- Orchestration:
- 에이전트와 환경 호출을 번갈아 진행하는 메인 루프(“에이전트 → 환경 → 에이전트 …”).
- TapeAgents는 기본적으로 tapeagents.orchestrator.main_loop라는 표준 오케스트레이션 함수를 제공합니다.
- 하지만 안전성·추가 검증 로직 등 애플리케이션별 요구사항이 있을 수 있으므로, 개발자가 직접 오케스트레이터를 작성하여 세밀하게 제어하는 경우도 권장됩니다
- Tape 및 Step 메타데이터:
- TapeAgents에서 에이전트(agent.run()) 혹은 환경(environment.react())이 테이프를 생성·갱신할 때 메타데이터가 자동으로 기록됨.
- tape.metadata.author:
- 현재 테이프를 작성(“author”)한 주체가 누구인지 나타냅니다
- 에이전트(Agent) 혹은 환경(Environment)이 테이프에 스텝을 추가했다면, 해당 주체가 author가 됩니다
- tape.metadata.parent_id
- 이 테이프가 이전 테이프를 이어받아(continuation) 생성된 경우, 그 부모 테이프의 ID를 가리킵니다.
- 이를 통해 테이프를 계층적으로 추적할 수 있습니다.
- step.metadata.agent
- 해당 스텝을 생성한 에이전트의 계층 이름(hierarchical name) 을 기록합니다
- step.metadata.node
- 스텝을 생성한 노드(node) 이름.
- step.metadata.prompt_id
- 스텝을 만들어낸 LLM 호출 프롬프트에 대한 고유 식별자
- 하나의 노드가 여러 번 실행될 수 있는데, 각 실행에 대해 유일한 prompt_id 를 생성해둠.
- 이를 통해 스텝을 특정 LLM 호출과 연결지어 추적할 수 있음.
- 역추적(backtrace): 스텝 → 노드 → 프롬프트 → LLM 출력으로 이어지는 과정을 추적할 수 있어, 문제 발생 시 근본 원인을 빠르게 찾기 쉬움
- 디버깅·관찰: 어떤 에이전트·노드가 특정 스텝을 만들었고, 해당 스텝이 어떤 프롬프트 ID와 연결되어 있는지 알 수 있음.
- 버전 관리: author, parent_id 등을 이용해 테이프가 어떻게 파생되었는지 “분기” 구조로 살펴볼 수 있음.
- 노드가 LLM 호출을 할 때마다, 프롬프트와 LLM 출력 결과를 SQLiteDB 에 기록함.
- TapeAgents는 “LLM 호출 내용”을 “테이프” 그 자체에는 넣지 않고, 별도 DB로 분리하여 테이프를 좀 더 가볍고 간결하게 유지합니다
- 대신, step.metadata.prompt_id 를 이용해 “해당 스텝과 LLM 호출 DB 기록”을 연결 지어줍니다
- 이러한 DB 구조 덕분에 LLM 호출 로그도 필요할 때 언제든 쉽게 조회하면서, 테이프 파일의 크기 자체는 최소화할 수 있음.
TapeAgents - Low-code Mini-Frameworks:
- TapeAgents가 제안하는 세 가지 미니 프레임워크: 공통적으로 “노드에서 프롬프트를 생성(make_prompt)하고, 출력 텍스트를 스텝(step)으로 파싱(generate_steps)하는 반복적인 과정을 간소화”하려는 목적을 가지고 있음.
- 이건 손쉽게 에이전트를 개발할 수 있는 방법을 말함 크게 다음과 같이 있다:
- MonoAgent:
- 모놀리식(monolithic) 에이전트를 구현할 수 있도록 하는 가장 단순한 방식
- MonoNode 노드들이 공통된 템플릿(프롬프트)을 공유하되, 마지막 사용자 메시지 지시(instruction)만 다르게 설정하며 동작.
- LLM에서 출력된 텍스트를 Pydantic 모델과 연결해, 만들어질 수 있는 모든 스텝(step) 형식을 정의하고, 그 중 어느 스텝을 생성할지를 파싱
- TeamAgent:
- AutoGen 방식의 “에이전트 팀(team)”을 하나의 테이프에서 동작하게 하는 예시.
- 다음과 같은 세 가지 팀 에이전트 종류를 지원:
- (a) Initiator: 첫 번째 Call 메시지를 보내는 역할 (팀 구성을 시작).
- (b) Manager: 어떤 에이전트가 다음으로 활성화될지를 결정(=오케스트레이션 일부).
- (c) Worker: 자신의 시스템 프롬프트(System Prompt)에 따라 응답(Respond)하는 에이전트.
- LLMFunction:
- 함수형(function-style) 프롬프트 템플릿을 사용하는 방식
- 예: DSPy(Signature) 같은 형식으로, 프롬프트를 “함수 시그니처”처럼 정의하고, 내부에 데몬스트레이션(demonstrations) 을 첨부하여 성능을 높이기 쉬움.
- 구조가 비교적 간결해, 프롬프트 튜닝이나 예시(샘플) 추가 같은 최적화를 단순화할 수 있음.
- MonoAgent:
TapeAgents - Examples:
- Financial Analyst + Web Search Helper:
- 사용자 대면 금융분석 에이전트(Financial Analyst)가 존재하고 이 에이전트가 하위 에이전트(subagent)인 웹 검색 헬퍼(Web Search Helper)에게 검색 업무를 위임하도록 구성된 사례
- 구현 상세:
- 에이전트가 사용하는 툴 (회사 티커(ticker) 가져오기, 주가 데이터를 다운로드, 웹 검색 및 브라우징 툴)
- 에이전트의 노드 프롬프트에 “툴의 스키마(schemas)”를 포함해, 어떤 툴을 호출할 수 있는지 알려줌.
- Tape 타입: DialogTape:
- 액션(Action) 스텝으로 두 가지 종류만 허용:
- ToolCalls: 툴 호출 (검색, 다운로드, 등)
- AssistantStep: 사용자에게 응답
- 오픈 도메인 QA & 웹 브라우징:
- 이 예시는 보다 정량적(quantitative)인 평가를 위해, 기존 벤치마크를 목표로 하는 에이전트를 구성하는 사례입니다.
- GAIA Benchmark용 QA 에이전트:
- GAIA 벤치마크(Mialon et al., 2024)의 질문답변(QA) 태스크를 수행하는 에이전트
- 에이전트 기능:
- 웹 검색 (search the web)
- 파이썬 코드 실행 (run Python code)
- 다양한 파일 형식 읽기
- 구현 방식:
- MonoNode 노드 기반으로 계획(Planning) 노드 2개 + 행동(Acting) 노드 1개를 반복(loop)하여 추론(ReAct + Planning 유사)
- RAG(Retrieval-Augmented Generation) 에이전트:
- 에이전트 동작 흐름:
- 두 번의 쿼리 생성(질의 생성) → 위키(Wikipedia)에서 검색 → 검색 결과 사용해 짧고 정확한 답변 생성.
- 노드 구성:
- 주로 LLMFunctionNode로 이루어진 5개의 노드를 사용.
- 노드들은 각각 자신의 LLMFunction 템플릿에 따라, 테이프(tape)의 특정 스텝(검색 결과, 이전 쿼리 등)을 입력 필드로 매핑해 프롬프트를 생성함.
- 별도로, 검색된 문단을 중복 제거하기 위한 “null-prompt node”(LLM 호출 없이 단순 중복 제거 로직)도 포함
- Prompt-Tuning 과정:
- 데몬스트레이션(예시) 수집:
- HotpotQA 훈련 예제 50개를 에이전트로 실행하여 나온 테이프 중, 정답이 맞고(accurate), 중복 쿼리가 아닌 것만 선별 → “좋은(good) 테이프”로 분류.
- 데몬스트레이션 선택:
- 무작위로 4개의 “좋은 테이프” 조합을 10가지 시도 → 총 10개의 후보 프롬프트 튜닝안 생성.
- 각 후보안에 이 데몬스트레이션들을 LLMFunction 템플릿에 추가(지시사항, I/O 포맷, 예시 등).
- 검증 및 성능 측정:
- Validation 셋(검증 데이터)에 대해 검색 정확도(retrieval accuracy) + 정답 정확도(answer accuracy) 합을 측정.
- 검색 정확도(retrieval accuracy) + 정답 정확도(answer accuracy) 합을 측정.
- 데몬스트레이션(예시) 수집:
- 에이전트 동작 흐름:
Case Study: Building a Cost-Effective Enterprise Form-Filling Assistant
- TapeAgents를 활용해 엔터프라이즈(기업) 환경에서 저비용으로 고품질의 대화형 폼 작성(Form-Filling) 어시스턴트를 만드는 과정
- 문제 설정 (Problem Setting):
- 기업용 폼 작성의 필요성:
- 대기업에서 직원이 자원, 도움, 접근 권한 등을 요청하기 위해 폼을 작성해야 하는 경우가 많음.
- 이 과정을 대화형 어시스턴트가 도와주면, 사용자 입장에서는 어떤 폼을 골라야 할지, 어떻게 채워야 할지 등 번거로운 과정을 쉽게 처리할 수 있음.
- “Unhappy-path” 상황 처리:
- 사용자가 요청하는 것이 불가능하거나, 어시스턴트가 답변할 수 없는 상황 등, 예외 케이스를 어떻게 다룰지 중요함.
- 어시스턴트가 적절히 안내하거나 명확하게 거절하는 등, 사용자 경험(UX)이 중요.
- GREADTH 점수:
- 이 사례 연구에서는 사용자 경험 품질을 평가하는 GREADTH 라는 지표를 사용함.
- Grounded, REsponsive, Accurate, Disciplined, Transparent, Helpful
- 제한된 어시스턴트 시나리오:
- 폼 기반 정보만 사용 (추가적인 외부 문서 검색 X).
- 한 번에 하나의 폼만 다룬다 (중간에 다른 폼으로 바꾸지 않음).
- 대화 초반에 “어떤 폼을 써야 하는지” 사용자와 상의 → 결정 후 해당 폼 작성 절차만 진행.
- 폼 작성 과정에서 사용자 입력 값(슬롯, slots)을 유지하고, 최종적으로 폼 제출 또는 사용자가 더 이상 대화 필요 없음을 확인하면 종료.
- 기업용 폼 작성의 필요성:
- TapeAgents를 통한 구현 방향:
- 저비용 & 고품질 목표:
- 고가의 모델(GPT-4급)만 쓰면 정확도와 사용자 만족도는 높겠지만, 비용이 매우 큼.
- TapeAgents를 사용하여:
- 모델 최적화 (프롬프트 튜닝, 파인튜닝 등)
- 세세한 로그(테이프) 관리로 디버깅 및 성능 평가
- “Unhappy-path” 같은 예외 시나리오도 로그 기반으로 파악해 개선
- 결과적으로 “GPT-4 수준”에 근접한 품질을 훨씬 낮은 비용으로 달성하는 전략을 추구
- Tape & Slots:
- 사용자 입력(슬롯)과 어시스턴트 응답은 Tape에 모두 기록 → 현재 폼의 상태, 사용자가 제공한 필드 값 등을 구조적으로 추적 가능.
- 중간에 특정 시점 테이프로 돌아가 재시작(resume)할 수도 있어, 디버깅·시뮬레이션 편의성 높음
- 저비용 & 고품질 목표:
- GREADTH의 6가지 요소:
- Grounded:
- 어시스턴트가 말하는 모든 내용은 오직 폼 문서(form documentation), 대화 이력(conversation history), 그리고 어시스턴트의 정체성과 목적(grounding statement)에서만 근거를 얻어야 함.
- 즉, 확인되지 않은 정보나 “잡담(small talk)” 같은 것은 허용되지 않음.
- Helpful:
- 대화를 적극적으로 이어가며, 사용자에게 필요한 정보를 제공하고 다음 슬롯을 채우도록 안내.
- (a) 각 슬롯을 요청할 때 기본값, 허용 범위, 필수 여부(옵션 여부) 등 관련 정보를 충분히 알려줄 것
- (b) 폼 문서에 답이 있으면, 사용자의 질문에 반드시 답변할 것
- (c) 사용자가 원하면, 언제든 대화 종료(exit) 가능하도록 해야 함.
- Accurate:
- 사용자의 의도를 정확히 파악해, 폼 문서에서 필요한 정보를 끌어오고, 슬롯을 올바르게 채우거나(해당하면), 사용자가 의견을 바꾸면 업데이트하고, 해당 없는 슬롯은 건너뛰는 등 정확한 폼 작성을 보장.
- Transparent:
- 사용자가 입력한 슬롯값 혹은 자동으로 스킵한/기본값으로 채운 슬롯 등, 모든 변경사항을 사용자에게 알기 쉽게 요약.
- 음성 대화처럼 시각적 표시가 없는 상황에서는, 변경 내용을 명시적으로 알려주는 투명성이 핵심.
- Disciplined:
- 자신이 세운 계획(“이제 ~슬롯을 물어보기”, “이 요청은 거부해야 함” 등)을 충실히 이행해야 함.
- 폼 문서에 맞지 않는 잘못된 슬롯값이나, 잘못된 요청은 거부하거나 고쳐줄 것.
- REsponsive:
- 사용자가 예상 밖(“오프토픽”) 질문을 하더라도, 가능한 한 의도를 파악하고, 그에 대한 적절한 대응을 하도록 함.
- Grounded:
- 평가 방법: 이분법적(Binary) 기준:
- 각 요소(G, R, E, A, D, T, H)에 대해 예/아니오(만족/미충족)로만 평가(“binary criteria”)하는 방식을 선택.
- 실제 대화 품질을 더욱 세밀하게 평가하려면 유창성, 표현 방식, 정보량 등의 주관적 요소도 고려해야 하지만, 이 연구에서는 단순화를 위해 이분법적 체크를 우선 택함.
- 폼 작성 TapeAgent 설계 개요:
- (1) Tape 구조 및 “생각(Thought) + 액션(Action)” 방식
- 한 번의 에이전트 응답(메시지)을 생성하기 전에, 에이전트는 테이프(Tape)에 ‘생각(Thought)’ 여러 개와 ‘액션(Action)’ 하나를 기록합니다.
- “생각”에는 사용자가 의도한 폼(또는 슬롯 정보)을 어떻게 파악하고, 폼 상태를 어떻게 갱신하며, 어떤 응답이 필요한지 등에 대한 체인 오브 톳(Chain-of-Thought)이 담깁니다.
- “액션”에는 실제 사용자에게 메시지를 보내거나, 폼 제출을 진행하거나, 대화를 종료하는 등 한 번에 딱 하나의 행동을 명시합니다.
- (2) GREADTH 경험을 위한 Thought 설계
- GREADTH(Section 5.2) 기준을 만족하기 위해, 생각(Thought) 단계에서 사용자 의도 분석 (form을 찾거나, 슬롯 값을 확인, 질문을 파악 등), 내부 상태 업데이트 (슬롯 채우기, 거부하기 등), 다음 액션 기획 (슬롯 요청, 사용자 확인 요청 등) 등을 수행합니다.
- (1) Tape 구조 및 “생각(Thought) + 액션(Action)” 방식
- Multi-node Teacher Agent:
- 복수 노드를 사용하여 다단계 프롬프트(multi-step prompting)로 상세히 에이전트 로직을 제어 → 인간 평가(human evaluation) 결과, GREADTH 측면에서 좋은 성능을 달성.
- 모델로 Llama-405B를 사용(논문에서는 ‘Teacher’)하며, 의도 분류 + 슬롯 채우기를 총 7개 노드로 나눠서 진행합니다
- Teacher 에이전트의 7개 노드 흐름 (그림 5 참조)
- Is Form Selected?:
- LLM 호출 없이, 테이프를 검사해 사용자가 이미 폼을 골랐는지 확인
- 폼이 없으면 Intent Discovery로 넘어가고, 선택된 폼이 있으면 바로 폼 작성 단계로 이동.
- Intent Discovery:
- 가능한 폼 목록을 요청(ResolveFunctionAction) 후, 적절한 폼 문서를 가져옴(InspectFunctionAction).
- 폼을 식별하지 못하면, 다시 사용자에게 어떤 폼이 필요한지 묻거나(RefuseInexistentFunctionThought 등) 더 구체적 정보를 요청.
- Gather Raw Parameter Values:
- 폼 문서를 가져왔으니, 사용자 메시지에서 슬롯 후보 값(raw slot values)을 추출(GatherValuesThought).
- Verify Parameter Values & Types:
- 추출한 슬롯 값들이 폼 문서에 적합한지 검증(VerifyValuesThought).
- Update Slots and Plan Response:
- 올바른 값은 UpdateFunctionParametersThought로 슬롯에 반영,
- 잘못된 값은 RefuseInvalidFunctionParameterValueThought로 거부,
- 사용자에게 답변(AnswerFromFunctionSchemaThought)이 필요하다면 준비.
- Plan Next Slot or Confirmation Requests:
- 다음 슬롯을 요청(RequestFunctionParametersThought)할지,
- 폼 제출 전 확인(RequestFunctionCallConfirmationThought)을 할지,
- 대화를 종료(RequestExitConfirmationThought)할지 결정.
- Generate:
- 최종적으로 사용자에게 텍스트를 보낼(PromptUserForTextMessageAction)지,
- 폼을 제출(CallFunctionAction)할지,
- 대화를 끝낼(ExitAction)지를 선택해 액션 스텝으로 기록하고 종료.
- Is Form Selected?:
- Single-node Student Agent:
- Teacher”와 달리 토큰 수(비용)를 최소화하고 추론 시간을 줄이기 위해 설계.
- 모델은 Llama-8B를 사용(“Student”), 노드 수를 크게 줄여(의도 분류 2개 + 슬롯 채우기 1개 = 총 3개 노드) 하나의 짧은 프롬프트에 모든 로직을 합침.
- Student 에이전트의 3개 노드:
- Is Form Selected?
- Teacher와 동일한 구조이지만, 지시문이 더 간단함.
- Intent Discovery:
- 마찬가지로 간략화된 지시문으로 폼을 식별.
- Update Slots, Generate Plan, and Respond:
- 한 번의 “짧은 프롬프트” 안에 RefuseInvalidFunctionParameterValueThought, UpdateFunctionParametersThought, RequestFunctionParametersThought 의 모든 생각을 출력한 뒤 최종 액션(Action)(PromptUserForTextMessageAction 등)으로 대화 진행.
- Is Form Selected?
