StateFlow: Enhancing LLM Task-Solving through State- Driven Workflows

https://arxiv.org/pdf/2403.11322

---

Abstract:

• 이 논문에서는 복잡한 작업 해결 과정을 상태 머신(state machine)으로 개념화한 StateFlow라는 새로운 LLM 기반 태스크 해결 패러다임을 제안함.
  • 상태 머신으로 처리가 적합한 문제와 적합하지 않은 문제가 있을 것 같은데 일반적으로는 어떻게 구별을 하는가? -> 단계별 테스크에 적합해보임.
• 상태 머신(State Machine) 개념:
  • 일련의 연속된 액션과 동적 상호작용이 필요한 작업을 효율적으로 처리할 수 있는 구조를 만들어서 처리하는 것.
  • 상태(state)와 상태 전환(state transition):
    • 작업 흐름(프로세스)을 단계적으로 분할하여 관리
    • 각 단계(상태)에서 필요한 액션(LLM 호출, 도구 활용 등)을 수행
    • 상태 전환 시에는 휴리스틱 규칙 혹은 LLM의 판단이 작용해, 동적인 분기 가능
  • StateFlow에서는 “프로세스 그라운딩(process grounding)”과 “서브태스크(sub-task) 해결”을 분리하여 처리함:
    • 프로세스 그라운딩:
      • 전체 태스크를 상태 머신으로 구성하는 과정
      • 어떤 상태가 필요하며, 어떤 조건에서 다음 상태로 넘어갈지(상태 전환)를 설정
    • 서브 태스크 해결:
      • 각 상태 내에서 실제 액션을 수행해 문제를 해결
      • 예: LLM 호출 시 다양한 프롬프트 사용, 외부 API/tool 연동 등
  • 주요 성능 지표:
    • InterCode SQL, ALFWorld 벤치마크에서 기존 방식(ReAct) 대비 성공률 상승 (13%, 28% 높은 성공률, 비용은 5배, 3배 절감)
• Reflexion과 같은 반복적(Iterative) 개선 방법과 결합했을 때 성능이 더욱 향상됨
• 상태 구조로 나눠서 처리하는 방식과 Planning 과는 어떤 차이가 있지?
  • Planning 은 다음으로 가정: Planning + Sub-planning + Replanning 방식
    • 어떤 순서로 액션을 실행할지”를 플래너(Planner) 가 자동으로 탐색 및 생성
    • 하위 목표(sub-goal)가 있을 경우, 각 하위 목표를 달성하기 위한 부분 계획(sub-plan)을 세우고 실행.
    • 실행 도중 예외 상황이나 환경 변동이 생기면 다시 계획을 수정하는 replanning
  • 잘 모르겠음. 작업을 처리하는데 일련의 계획과 목적을 설정해두고, 다음 상태 또는 작업으로 넘어가는 것이 매우 유사해보임.
  • 상태 머신은 보다 명시적으로 작업을 설계함. 그래서 의도한대로 작동할 확률이 높음. 다만 유연하지 않음.
  • 반면 Planning 방법은 플래너가 적절한 액션 시퀀스를 찾아낸다는거임. LLM 의 추론 능력에 의존함. (In-Context Learning 이나 Fine-tuning 을 통해 개발자가 원하는 방향을 넣으면 완화될 수 있을 것.)
    • 즉 LLM 이 설계/도메인 지식이 잘 정형화되어 있다면, 플래너가 의도치 않은 오류를 낼 확률이 낮을거임

 

Introduction:

• 이 논문은 LLM의 “자동 진행” 한계 때문에 제안됨. "LLM이 현재 작업 상태를 항상 올바르게 판단하고, 후속 작업을 완벽히 결정하기를 기대하기는 어려움." 때문.
  • 기존에는 ReAct 기반으로 그떄그떄 휴리스틱하게 현재 상황을 판단 후 다음 행동을 제안하는 식으로 되었는데 여기서 현재 상황 판단이나, 다음 행동 제안이 올바르지 않은 경우가 있어서임.
  • 즉 "LLM에 대해 더 정밀한 제어와 가이드를 제공할 방법은 없을까" 를 해결하기 위해 제안된 개념.

 

Methodology - StateFlow:

• StateFlow 모델을 6개의 요소 \langle S, s_0, F, \delta, \Gamma, \Omega \rangle로 정의:
  • States S:
    • 전체 프로세스의 현재 상태를 나타냄
    • 상태에 진입 시, 미리 정의된 일련의 액션(LLM 호출, 툴 사용 등)이 실행됨
    • 예: 에러 상태라면, 사전에 지정된 에러 처리 루틴(error-handling actions)을 수행
  • Initial state s_0
    • 작업(질문)을 처음 받았을 때 프로세스가 시작되는 상태
  • Final States F:
    • 프로세스가 종료되는 최종 상태들의 집합
  • Output Γ or Context history:
    • 프롬프트(P), LLM 응답(C), 툴/환경으로부터의 피드백(O)을 포함
    • 실제로는 이 메시지들이 목록(리스트) 형태로 누적되는데 이를 Context History 라고 부름
  • State transition δ:
    • 현재 상태와 context history를 바탕으로 다음 상태를 결정하는 함수
    • 예: 실행 결과 메시지에 ‘Error’라는 단어가 포함되어 있는지 등 문자열 매칭, 혹은 LLM으로 조건 검사(다음 상태 결정)를 할 수 있음
  • Output Functions Ω
    • LLM 호출, 툴 사용, 정적 프롬프트 반환 등 다양한 형태의 함수로 구성
    • 예: 도구를 호출하여 결과를 반환하거나, 특정 LLM에 특정 지침으로 쿼리를 보내는 함수
    • 생성된 결과물(응답)은 context history에 추가됨
• StateFlow 동작 흐름:
  • 시작:
    • 초기 상태 s_0에서 질문(Q) 이 context history(Γ)에 추가되어 프로세스 시작
  • 상태 전환:
    • 현 상태에서 정해진 Output Functions(Ω) 를 실행 → LLM/도구 호출 → 응답을 history에 추가
    • δ 함수(전이 규칙)를 통해 다음 상태 결정
    • 필요한 경우 최대 반복(transition) 횟수를 두어 무한 루프 방지
  • 종료:
    • 최종 상태 F 중 하나에 도달하면 프로세스 종료
    • 반환값: 종료 시점의 상태 + 전체 context history