[논문 리뷰] Procedural Graphs: Self-Evolving Execution Structures for LLM Agents

• 메타정보
• TL;DR
• 소개 (Introduction)
• 핵심 기여 (Key Contributions)
• 관련 연구 / 배경 지식
  • Semantic memory와 procedural memory
  • AutoGuide·AWM·KnowAgent와의 차이
• 방법 / 아키텍처 상세
  • 1. Procedure triplet과 세 가지 간선 속성
  • 2. Active node와 2-hop local subgraph
  • 3. Generative guidance와 solver의 행동 선택
  • 4. 실행 기록을 이용한 그래프 편집
  • 5. Rejection memory와 채택된 checkpoint의 유지
• 학습 목표 / 평가 기준
  • Validation score와 후보 채택 규칙
  • EnterpriseArena의 생존율과 평균 기업 점수
• 학습 데이터와 파이프라인
  • 일곱 benchmark와 분리된 평가 설정
  • Solver·guidance·refiner와 비교 예산
• 실험 결과
  • Table 1의 21개 최고·공동 최고와 세 가지 예외
  • EnterpriseArena의 생존·조회·자금 조달
• 결과 분석 / Ablation
  • 초기 그래프와 반복 검증의 결합
  • Local guidance의 이득과 추가 토큰 비용
  • 열 번의 진화와 최종 test 생존율 85%
  • 실행 순서·단위·종료 조건의 사례
• 한계와 비판적 평가
  • Soft guidance와 구조 검증의 범위
  • Validation 재사용과 구성 요소별 기여
  • 도구 인터페이스 전이와 전체 운영 비용
• 시사점 / Takeaways
• 설치 및 사용법
• 참고 자료
• 더 읽어보기

메타정보

TL;DR

• Procedural Graph (PG)는 도구·추론 단계·상태를 노드로, 조건과 실행 조언을 담은 전이를 간선으로 저장한다. 매 단계 현재 노드의 2-hop 주변 구조와 최근 실행 기록을 읽고 다음 행동을 위한 안내를 생성한다.
• 모델 가중치는 고정한다. 학습 과제의 성공·실패 기록을 분석해 그래프를 수정하고, 별도 validation 점수가 유지되거나 좋아진 후보만 채택한다. 실제 과제를 수행하는 동안에는 그래프가 바뀌지 않는다.
• 주 비교의 24개 모델·벤치마크 조합에서 19승·2무·3패다. Gemini 3.5 Flash의 BFCL v3는 67.00%로 최선 baseline 58.00%보다 9.00%p 높다. 모든 과제에서의 개선이나 행동 제약의 보장을 뜻하지는 않는다.
• EnterpriseArena의 별도 10-round 진화 실험에서는 최종 반환 그래프가 test 생존율 85%를 기록한다. 탐색 도중의 최고 test 값 95%와, 별도 50-episode 비교에서 Flash의 생존율이 0%였다는 결과를 구분해야 한다.
• Local guidance는 전체 그래프를 읽는 방식보다 효율적이지만, 그래프가 없는 baseline보다 토큰을 더 쓴다. 짧아진 solver 경로와 총 추론 비용은 다른 지표다.

소개 (Introduction)

항공권 가격을 물었는데 agent가 결제와 예약까지 진행한다면, 부족한 것은 비행 정보를 찾는 능력만이 아니다. 어떤 행동이 요청의 범위 안에 있는지, 언제 충분한 답을 얻었는지, 그다음에 멈춰야 하는지를 유지하는 능력이 필요하다. 재무 의사결정에서는 같은 문제가 시간의 형태로 나타난다. 자금이 부족하다는 사실을 알아도 입금까지 몇 달이 걸린다면, 부족해진 뒤의 정확한 판단만으로는 기업을 살릴 수 없다. 정보를 보유하는 것과 적절한 순서로 행동하는 것 사이에는 간격이 있다.

보통의 ReAct agent는 질문과 지금까지의 대화·도구 결과를 읽고 다음 행동을 생성한다. 실행이 길어질수록 모델은 이전의 제약을 기억하면서 현재 위치를 추정하고, 필요한 선행 작업을 찾고, 반복 중인 행동이 유효한지도 판단해야 한다. 경험을 요약해 문맥에 넣으면 도움은 되지만, 요약 안의 조언을 현재 단계와 연결하는 부담은 여전히 모델에 남는다. 반대로 모든 순서를 코드로 고정하면 예외적인 상황에 유연하게 대응하기 어렵다.

Lu et al.의 Procedural Graphs는 그 사이에 명시적인 절차 표현을 둔다. 어떤 단계 뒤에 무엇이 올 수 있는지와 그 조건을 그래프로 저장하고, 현재 실행 상황에 맞는 부분을 언어로 풀어 준다. 더 나아가 실패한 실행이 반복되면 조언의 문장뿐 아니라 노드와 연결 자체를 고친다. 이 리뷰는 arXiv v1의 본문과 부록을 기준으로, 이 구조가 실제로 수행하는 일과 실험이 뒷받침하는 범위를 나누어 살펴본다.

핵심 기여 (Key Contributions)

• 편집 가능한 procedural memory. 과거 실행을 그대로 보관하는 대신 재사용할 행동 전이와 조건을 모델 밖의 그래프로 표현한다. 수정 대상은 모델의 파라미터가 아니라 외부 절차 지식이다.
• 현재 단계에 연결된 generative guidance. 관련 문장 몇 개를 독립적으로 검색하는 대신 연결된 주변 구조를 읽고, 현재 질문과 최근 이력에 맞는 조언을 매 단계 생성한다.
• Validation을 포함한 그래프 진화. 구조 검사를 통과한 후보를 실제 과제로 평가하고, 실패한 수정안도 보존해 이후 제안의 반례로 활용한다.
• 다양한 과제와 실패 양상의 분석. 질의응답·대화·전문 업무·행동 실행·함수 호출·장기 재무 시뮬레이션에서 비교하고, 잘못된 초기 그래프의 복구와 비용 증가를 함께 보고한다.

관련 연구 / 배경 지식

Semantic memory와 procedural memory

Knowledge Graph가 표현하는 것은 대개 사실의 관계다. 어떤 인물이 어떤 작품을 만들었는지, 작품이 어디에 있는지를 연결한다. 반면 procedural memory는 주어진 상황에서 어떤 행동을 어떤 순서로 해야 하는지를 담는다. 논문은 CoALA의 기억 구분을 배경으로 삼는다. 현재 문맥을 유지하는 working memory, 과거 경험을 담은 episodic memory, 사실을 담은 semantic memory와 절차를 담은 procedural memory는 서로 다른 역할을 한다.

이 구분은 저장 형식만으로 결정되지 않는다. 실행 기록을 그래프로 저장해도 그 안의 관계가 단지 사건의 시간 순서라면, 아직 재사용 가능한 행동 규칙을 얻었다고 할 수 없다. PG가 저장하려는 것은 특정 고객에게 어떤 답변을 했다는 사실보다, 답변 전에 어떤 조건을 확인해야 하는지에 가깝다. 그래프라는 자료구조의 선택과, 그 그래프가 담는 지식의 성격을 함께 보아야 한다.

AutoGuide·AWM·KnowAgent와의 차이

AutoGuide는 특정 상황에서 어떤 행동이 적절한지를 조건부 지침으로 만들기 때문에 가장 가까운 비교 대상이다. Agent Workflow Memory는 반복해서 사용할 행동 흐름을 경험에서 추출한다. 논문의 baseline 구현에서 KnowAgent는 행동과 가능한 전이를 텍스트 지식으로 제공한다. 따라서 기존 방법에는 조건이나 절차가 전혀 없고 PG만 처음 도입했다고 설명하면 부정확하다.

PG의 차이는 조건이 달린 전이를 연결된 구조로 저장하고, 현재 위치에서 주변 연결을 꺼내며, 피드백으로 그 구조까지 수정한다는 조합에 있다. 예컨대 제출 방법만 검색하면 검증이 선행해야 한다는 관계를 놓칠 수 있다. 연결된 절차를 읽으면 제출과 검증을 함께 고려할 여지가 생긴다. 다만 본문의 검색은 현재 노드에서 나가는 방향을 확장한다. 모든 가능한 선행 조건을 역방향으로 찾아 완전하게 증명하는 시스템은 아니다.

방법 / 아키텍처 상세

1. Procedure triplet과 세 가지 간선 속성

원문 식 (1)은 PG를 다음과 같이 정의한다. V는 노드, R은 관계 종류, E는 방향이 있는 전이, Φ는 간선 속성이다.

노드는 도구 함수뿐 아니라 skill, 내부 추론 단계, 과제 상태를 나타낼 수 있다. 간선 하나는 출발 노드 u에서 관계 r을 통해 도착 노드 v로 진행할 수 있음을 표현한다. 실험에 사용한 관계에는 LEADS_TO, TRIGGERS, PROVIDES_INPUT_FOR, CONVERGES_TO가 있다. 각각의 간선에는 세 가지 텍스트 필드가 붙는다.

이 예시의 장점은 현금 부족과 자금 요청을 연결하는 동시에, 요청의 시점과 중복 금지까지 담을 수 있다는 것이다. 그러나 조건은 기본적으로 자연어다. 간선이 있다는 사실만으로 도구 호출의 적법성을 프로그램이 판정하는 것은 아니다. 모델이 읽고 해석할 절차 지식과 환경이 강제하는 실행 규칙은 분리되어 있다.

그래프의 크기도 거대한 지식망과 다르다. Table 7에서 BFCL v3를 제외하면 노드는 7~17개, triplet은 7~27개다. BFCL v3는 함수 목록이 커서 131개 노드와 265개 triplet을 사용한다. 이 결과는 비교적 작은 절차 구조도 도움이 될 수 있음을 보여 준다. 동시에 수천 개의 연결을 갖는 환경에서 검색이 얼마나 안정적으로 동작할지는 별도의 질문으로 남는다.

2. Active node와 2-hop local subgraph

온라인 실행은 현재 위치 찾기, 주변 구조 추출, 상황별 안내 생성의 순서다. 이전 행동을 그래프의 노드와 정확히 대응시키고, 그 노드에서 나가는 간선을 최대 h번 따라가며 이웃 구조를 얻는다. 원문의 기본값은 h=2다. 일치하는 노드를 찾지 못하면 빈 안내를 주는 대신 전체 그래프를 사용한다. 첫 단계는 Start에 대응시킨다.

여기서 q는 질문, T는 행동과 관찰을 이어 붙인 이력, Ψ는 guidance model이다. 안내에는 최근 w=3 단계의 이력을 사용한다. 최근 기록만 쓰는 것은 안내 생성의 입력 범위를 줄이는 장치이며, solver가 과제 전체를 세 단계만 기억한다는 뜻은 아니다. 다음 행동을 만드는 solver는 질문과 자신의 이력, 생성된 안내를 함께 받는다.

2-hop이라는 말도 미래 행동을 실제로 두 번 실행해 본다는 뜻이 아니다. 그래프에 기록된 두 단계 앞의 가능성을 읽는 것이다. 따라서 이 부분은 rollout 기반 탐색과 다르다. 불확실한 미래를 시뮬레이션해 가치를 계산하기보다, 지금 주변에 어떤 절차적 선택지가 있는지를 모델이 고려하게 한다.

3. Generative guidance와 solver의 행동 선택

Guidance model은 간선의 문장을 그대로 복사하는 데 그치지 않는다. 질문과 최근 관찰을 읽고 당장 필요한 행동, 도구 인자, 반복 실패를 피할 방법을 구체적인 안내로 바꾼다. Solver는 그 안내를 추가한 프롬프트에서 다음 행동을 생성한다. 원문 식 (3)의 구조는 다음과 같다.

따라서 PG는 허용된 간선만 따라가도록 action을 차단하는 실행 엔진이 아니다. 안내를 받더라도 최종 선택은 solver가 한다. 저자들이 강조하는 reasoning flexibility는 여기서 나온다. 반면 어떤 규칙도 어길 수 없다는 보장은 같은 이유로 제공하지 않는다. 실험에서 적절한 행동이 늘었다는 관찰과 형식적으로 위반이 불가능하다는 주장을 구분해야 한다.

부록의 HotpotQA 예시는 첫 번째 문서를 가져온 뒤 연결 개체를 확인하고 두 번째 검색으로 이어지는 맥락을 보여 준다. 한 문장씩 유사도 검색을 하는 경우와 달리, 각 조언이 어떤 출발점과 도착점을 잇는지 유지된다. 다만 부록 B.5의 실제 serializer 예시에는 관계 label 자체가 출력되지 않는다. 이를 고려하면 결과를 특정 relation 이름의 효과로 단정하기보다, 연결과 속성을 함께 제시하는 전체 설계의 효과로 읽는 편이 타당하다.

4. 실행 기록을 이용한 그래프 편집

Offline evolution에서는 현재 채택된 그래프로 학습 과제를 실행하고 최종 점수와 trajectory를 모은다. Refiner는 점수가 높은 실행과 낮은 실행을 비교해 반복 실패, 빠진 검증, 불필요한 우회 경로를 찾는다. 이후 노드와 간선의 추가·삭제를 JSON 편집안으로 제안한다. 간선 속성을 바꾸는 경우에도 기존 간선을 지우고 새 속성으로 다시 추가하는 인터페이스를 사용한다.

편집은 현재 그래프의 복사본에 적용한다. 삭제를 먼저 처리한 뒤 추가를 적용하고, 간선의 양 끝 노드와 타입, 종료 노드까지의 도달 가능성을 검사한다. Cycle을 허용하지 않는 설정에서는 감지된 cycle을 닫는 간선을 제거하고 비순환 조건을 검사한다. Cycle을 허용하는 과제에서는 그 검사와 보정을 생략한다. 모든 과제가 동일한 DAG를 강제받는 것으로 이해하면 안 된다.

두 가지 구현 경계가 중요하다. 첫째, 모든 노드가 도달해야 하는 terminal node는 out-degree가 0인 노드다. 이름이 반드시 End인 노드까지 도달해야 하는 것은 아니다. 둘째, ACTION 노드 이름이 실제 도구 목록과 일치해야 한다는 요구는 refiner 프롬프트에 있지만, 일반 구조 검증기가 도구 목록 membership까지 독립적으로 확인하지는 않는다. 구조적으로 유효한 그래프와 실제 도구 환경에서 완전히 유효한 그래프 사이에는 여전히 간격이 있다.

5. Rejection memory와 채택된 checkpoint의 유지

구조 검사에 실패한 후보는 validation rollout 전에 버린다. 구조는 통과했지만 점수가 떨어진 후보도 채택하지 않는다. 이때 실패한 수정안과 후보 그래프, 관련 학습 기록, validation 결과 또는 구조 오류를 rejection memory에 남긴다. 다음 refiner 호출이 같은 실패를 다시 제안하지 않도록 주는 정보다. 이것은 실패한 행동을 확률적으로 억제하도록 모델을 학습하는 과정이 아니라, 다음 프롬프트에 반례를 제공하는 과정이다.

학습 trajectory가 길이 한도를 넘으면 앞부분을 버리고 마지막 토큰들을 보존한다. 결말과 오류의 결과를 남기는 데 유리하지만 초반의 원인을 잃을 가능성도 있다. 다음 round의 출발점은 마지막으로 제안한 후보가 아니라 마지막으로 채택한 그래프다. 거절된 후보는 기억에 남을 뿐 실행 정책의 새 기준이 되지 않는다. 원문 Algorithm 1은 이 상태를 cached validation score와 함께 명시하고, round 예산이 끝나면 최종 유지 그래프를 반환한다.

학습 목표 / 평가 기준

Validation score와 후보 채택 규칙

이 방법에는 모델 가중치에 적용하는 별도 gradient loss가 없다. 최적화하는 것은 외부 그래프이며, 제안된 수정을 채택할지 결정하는 목적값은 held-out 과제의 평균 점수다. 각 과제의 점수를 S로 쓰면 원문 식 (4), (5)는 다음과 같다.

위에서 S의 아래첨자 k-1은 이전 채택 그래프의 저장된 validation 점수다. 초기 그래프를 한 번 평가해 기준을 만들고, 새 후보가 그 점수와 같아도 받아들인다. 매번 현재 그래프와 후보를 같은 시점에 다시 실행해 비교하는 방식은 아니다. 따라서 채택된 측정 점수가 나빠지지 않도록 관리할 수는 있지만, 실제 기대 성능이 단조롭게 좋아진다는 수학적 보장을 얻는 것은 아니다.

또한 test 점수는 후보 선택 기준이 아니다. Validation에서 선택한 그래프가 test에서도 좋아야 일반화의 근거가 생긴다. 여러 round의 test 결과 중 가장 높은 수치를 최종 성능으로 택하면 test를 사실상 선택에 사용하게 된다. 뒤의 EnterpriseArena 분석에서 85%와 95%를 구분하는 이유가 바로 이것이다.

EnterpriseArena의 생존율과 평균 기업 점수

EnterpriseArena는 대출 기관의 현금과 자금 조달을 최대 132개월 동안 관리하는 시뮬레이터다. 현금이 음수가 되면 파산하고, 조달 요청 후 실제 입금까지 1~6개월이 걸린다. 과제는 agent에게 사전에 알려 주지 않은 32·59·112개월의 위기를 포함한다. Full survival은 이 전체 기간을 버틴 episode의 비율이며, 평균 생존 개월에는 일찍 종료된 실행도 포함된다.

기업 점수는 마지막 날의 현금만을 뜻하지 않는다. 생존 중인 월에는 최근 12개월 매출의 5배와 현금을 더한 뒤, 누적 정보 도구 호출 수에 회당 5,000달러의 penalty를 적용한다. 12개월 미만이면 이용 가능한 월평균 매출을 연율화한다. 파산한 시점의 점수는 0이다. 논문은 각 실행의 종료 시점까지 월별 점수를 평균한 뒤 실행 간 평균을 낸다. 그러므로 최종적으로 파산한 실행도 시간 평균 기업 점수는 양수일 수 있다.

Table 8의 Tools/Mo 역시 모든 API 호출 수가 아니다. 정보 조회 도구의 실행별 호출 수를 해당 실행의 개월 수로 나눈 비율의 평균이며, memory 작업과 상태 변경 행동은 제외한다. Raised는 실제 들어온 equity와 debt의 누적액이다. 이 정의를 놓치면 정보 조회가 줄었다는 결과를 총 LLM 비용 절약으로, 많은 자금 조달을 높은 수익성으로 잘못 바꾸어 읽게 된다.

학습 데이터와 파이프라인

일곱 benchmark와 분리된 평가 설정

이 표는 부록 B.1의 주 비교 설정이다. Construction 실험에서는 HotpotQA가 train/validation/test 각각 1,000개이고, MultiChallenge는 100/100/56개다. EnterpriseArena의 10-round 진화 실험은 20/20/20 episode를 사용한다. 따라서 Table 1의 MultiChallenge 166개 결과와 Table 2의 56개 결과, Table 8의 장기 비교와 Table 11의 작은 진화 실험을 서로 같은 모집단의 연속 결과처럼 연결하면 안 된다.

지표도 다르다. Table 1의 HotpotQA는 Gemini 3.1 Pro judge가 질문·정답·agent 답변을 받아 의미상 일치를 판정한 accuracy다. Construction 실험은 string Exact Match와 단어 수준 F1을 별도로 보고한다. MultiChallenge도 Gemini 3.1 Pro judge를 사용하고, GDPval은 과제별 rubric으로 산출물을 평가한다. 모델이 만든 답을 어떤 방식으로 채점했는지가 숫자의 의미를 정한다.

Solver·guidance·refiner와 비교 예산

주 실험은 Claude Sonnet 4.6, Gemini 3.1 Pro, Gemini 3.5 Flash, Grok 4.1 Fast를 사용한다. 각 설정 안에서는 solver, guidance model, offline refiner가 같은 기반 LLM을 사용하며 temperature는 0이다. Construction 실험의 부록 D.3은 Gemini 3.5 Flash snapshot, top-k=1, agent 최대 출력 2,048토큰, refiner 최대 출력 8,192토큰을 명시한다. 이 출력 상한을 모든 실험의 공통 설정으로 확대하지 않는 것이 정확하다.

비교 방법들은 같은 ReAct solver와 도구 인터페이스를 사용하고, 학습 기반 baseline은 PG와 같은 학습 자료를 이용한다. 다만 경험을 저장하고 호출하는 방식은 다르다. PG는 매 단계 안내를 생성하므로 같은 solver를 썼다는 사실이 같은 호출 수나 토큰 예산을 보장하지는 않는다. 학습 batch의 stride는 HotpotQA 100개, MultiChallenge 20개다. 논문의 online evolution이라는 construction 이름도 이 학습 batch 사이의 갱신을 가리킨다. Test episode 도중 그래프를 다시 학습한다는 뜻이 아니다.

실험 결과

Table 1의 21개 최고·공동 최고와 세 가지 예외

PG는 24개 조합 중 21개에서 최고 또는 공동 최고다. 각 조합의 가장 강한 baseline과 비교하면 19승·2무·3패이며, 논문은 동률을 제외한 단측 exact binomial sign test의 p값을 0.00043으로 보고한다. 이 집계는 다양한 설정에서 개선 방향이 반복된다는 근거다. 각 셀의 차이가 모두 통계적으로 유의하다는 뜻은 아니다.

큰 차이가 나타나는 예는 Gemini 3.5 Flash의 BFCL v3 67.00% 대 58.00%로 +9.00%p, Gemini 3.1 Pro의 GDPval 78.78 대 RAP 71.37로 +7.41점, 같은 모델의 τ-bench 80.00% 대 RAP 73.04%로 +6.96%p다. GDPval과 BFCL에서는 네 모델 모두 PG가 모든 baseline보다 높다. 이 두 과제에서는 특정 solver 한 개에만 의존한 개선이라고 보기 어렵다.

예외도 분명하다. Claude Sonnet 4.6의 HotpotQA는 PG 74.50%보다 AutoGuide 75.40%가 높다. Grok 4.1 Fast의 ALFWorld는 PG 39.55%보다 ExpeL 42.54%가, τ-bench는 PG 67.83%보다 KnowAgent 68.70%가 높다. HotpotQA에서 최선 baseline 대비 차이는 전체 모델에 걸쳐 -0.90~+1.30점으로 작다. 절차 안내의 이득이 모든 종류의 추론에서 같은 크기로 나타나지는 않는다.

EnterpriseArena의 생존·조회·자금 조달

50-test-episode 비교에서 PG는 Claude Sonnet 4.6의 전체 기간 생존율을 44%에서 58%로, Gemini 3.1 Pro는 6%에서 34%로, Grok 4.1 Fast는 26%에서 40%로 높인다. Gemini 3.5 Flash는 비교한 모든 방법의 전체 생존율이 0%다. 다만 평균 생존 기간은 baseline 33.58개월에서 PG 40.62개월로 늘어난다. 논문의 최고 또는 공동 최고라는 표현에는 이 0% 동률도 포함된다.

정보 조회가 줄어드는 방향도 모든 모델에 공통되지는 않는다. Flash는 18.94회/월에서 12.53회/월로 줄지만 Sonnet은 0.13에서 0.36으로, Pro는 0.89에서 3.18로 늘어난다. 기존 agent가 과도하게 확인만 반복하는지, 필요한 예측과 시장 확인을 생략하는지에 따라 바람직한 수정이 달라지는 것이다. 호출 수를 무조건 줄이는 규칙으로 PG를 설명할 수 없는 이유다.

생존율과 기업 점수도 분리해야 한다. Sonnet의 PG 평균 점수는 70.38백만 달러로 baseline 78.86백만 달러보다 낮다. Flash에서도 PG 29.08백만 달러보다 MemoryBank 29.34백만 달러가 높다. 반면 Grok의 PG 점수는 39.62백만 달러로 해당 모델 비교 중 최고다. 높은 생존율, 높은 시간 평균 가치, 적은 조회 비용은 같은 순위를 만들지 않는다.

결과 분석 / Ablation

초기 그래프와 반복 검증의 결합

Construction 실험은 다섯 가지 설정을 비교한다. Mode 1은 사람이 만든 고정 그래프, Mode 2는 그 그래프를 한 번 수정한 결과, Mode 3은 전문가 그래프를 반복 개선한 결과다. Mode 4는 Start → End에서 한 번에 만든 그래프, Mode 5는 같은 최소 구조에서 반복 진화한 그래프다. Mode 2와 4는 한 번 만든 결과를 validation gate 없이 채택하며, Mode 3과 5는 batch별 피드백과 검증을 사용한다.

HotpotQA의 Mode 5는 F1 78.79로 unguided 71.21보다 7.58점 높고, EM도 58.80에서 66.30으로 7.50점 오른다. 그러나 Mode 4의 F1은 69.49로 baseline보다 낮다. 최소 구조에서 출발한다는 사실만으로 좋은 절차가 만들어지지는 않는다. 반복적인 경험 수집과 검증을 포함한 전체 과정이 중요하다.

MultiChallenge에서는 사람의 초기 그래프가 오히려 해롭다. Unguided 87.50%가 Mode 1에서 58.93%로 떨어지고, 한 번 수정한 Mode 2는 53.57%가 된다. 반복 진화한 Mode 3은 92.86%로 회복하고, scratch 기반 Mode 5는 91.07%다. 여기서 얻을 수 있는 결론은 검증 없는 전문가 prior도 실패할 수 있고 반복 수정으로 복구할 수 있다는 것이다. 전문가 지식이 일반적으로 불필요하다는 결론은 아니다.

부록 F.2의 사례는 이 차이를 구체화한다. 초기 후보는 사용자가 요구한 농담을 생성하는 대신, 대화가 수동태 조건을 지켰는지 평가하는 답을 내놓는다. 이후 그래프는 분석 단계에서 바로 종료하는 연결을 없애고 제약 추출을 거치도록 수정하며, 평가 질문에 직접 답하지 말라는 안내를 추가한다. 성공 기록은 0에서 1로 바뀐다. 다만 연결과 텍스트가 함께 바뀌므로 둘 중 어느 하나만이 개선을 일으켰다고 분리할 수는 없다.

Local guidance의 이득과 추가 토큰 비용

같은 그래프로 범위와 사용 방식을 바꾼 Table 3은 이 논문의 설계를 판단하는 중요한 실험이다. ALFWorld의 성공률은 no-graph 72.58%, full-graph raw injection 70.34%, full-graph generative guidance 54.48%, local generative guidance 81.53%다. 전체 그래프를 더 적극적으로 읽게 만드는 것이 오히려 해로울 수 있다. 현재 진행 상황과 관련된 작은 범위를 선택하는 과정이 성능에 중요하다는 해석을 뒷받침한다.

Local 방식은 전체 그래프에서 안내를 생성하는 방식보다 ALFWorld 토큰을 96,360에서 28,064로 70.9% 줄인다. GDPval에서는 448,972에서 367,738로, MultiChallenge에서는 14,434에서 12,295로 줄어든다. 하지만 no-graph의 토큰은 각각 18,055, 275,638, 6,629다. 전체 그래프 방식 대비 절약과 baseline 대비 추가 비용을 같은 문장으로 뭉개면 안 된다.

GDPval의 solver step은 28.20에서 18.57로, ALFWorld는 21.84에서 18.80으로 줄지만 토큰은 baseline보다 각각 33.4%, 55.4% 많다. 이 추가 비용은 안내 모델 호출을 포함한 전체 시스템으로 평가해야 한다. 또한 이 ablation에는 local subgraph를 raw로 넣는 행이 없다. 따라서 local retrieval 자체의 이득과 추가 LLM 변환의 이득을 완전히 분리한 2×2 실험은 아니다.

열 번의 진화와 최종 test 생존율 85%

별도의 Gemini 3.5 Flash 실험은 split당 20개 episode로 열 번의 진화를 추적한다. 처음 validation 생존율은 0%이고 평균 생존 기간은 34.8개월이다. Round 1은 현금 확인·예측·기록·시장 확인·조달 판단의 순서를 만들며 생존율을 45%로 올린다. Round 2는 이전 달의 기록을 다시 읽는 recall_notes를 추가하고 80%에 도달한다.

Round 3~6에는 채택된 수정이 없다. Round 5는 구조 검사에 실패해 validation도 실행하지 않았다. Round 7에서는 pass_action 분기를 정리하고, Round 8에서는 조달 요청 뒤에 곧바로 또 월을 진행시키는 경로를 수정한다. 이 환경의 adapter가 조달 요청 후 이미 월을 진행시키므로, 바로 종료하고 새 달의 상태를 다시 보는 절차가 의미를 갖는다. 개선된 그래프는 추상적인 금융 상식뿐 아니라 해당 도구의 상태 전이 의미를 배운다.

Round 8과 9의 validation 생존율은 90%이며 Round 10은 85%로 떨어져 거절된다. 최종 반환값은 Round 9 그래프이고 test 생존율은 85%, baseline은 0%다. Round 7의 test 값 95%가 더 높지만 이를 최종 결과로 선택해서는 안 된다. Validation이 개선되는 방향과 test의 최고점이 항상 일치하지 않는다는 사실도 이 기록에 이미 나타나 있다.

한 split에 20개 episode이므로 한 번의 생존 여부가 5%p다. Round별 채택 판단은 작은 표본의 검색 과정이지, 매 수정이 유의하게 낫다는 독립적인 통계 검정이 아니다. 또한 이 결과는 앞선 50-episode 비교와 초기 그래프·실험 구성이 다르다. Flash의 0%와 85%를 같은 설정에서의 단순 before/after로 제시하는 것은 피해야 한다.

실행 순서·단위·종료 조건의 사례

부록 C.3의 Grok 사례에서 unguided agent는 자금 요청이 진행 중인데도 추가 요청을 보내 거절된다. Memory summary agent는 추론에서 1,800만 달러를 언급하면서 실제 인자로 18을 전달하는 단위 오류도 보인다. PG agent는 일찍 조달을 요청하고, 입금 대기와 다음 달의 현금 예측을 연결한다. 이는 같은 seed에서 관찰된 행동 차이이며 전체 실행에서의 오류 발생률을 측정한 결과는 아니다.

BFCL의 가격 조회 사례에서는 두 agent 모두 220달러 견적을 얻는다. PG agent는 요청받은 가격을 알리고 해당 turn을 끝내지만 baseline은 인증·결제·예약까지 진행해 목표 상태와 어긋난다. PG의 가치는 빠진 행동을 더하는 데만 있지 않고, 충분한 결과를 얻었을 때 멈추도록 돕는 데도 있다. 그러나 이 한 사례가 다른 요청에서도 불필요한 실행을 항상 차단한다는 보장은 아니다.

한계와 비판적 평가

Soft guidance와 구조 검증의 범위

PG의 설명 가능성은 장점이다. 어떤 조건과 연결이 바뀌었는지 사람이 읽을 수 있고, 잘못된 prior가 어떻게 복구되는지도 추적할 수 있다. 하지만 자연어 조건이 정확하게 적용되는지, 안내를 solver가 따르는지는 여전히 LLM의 판단에 달려 있다. 논문의 구조 검증은 종료 노드 도달 가능성을 확인해도 모든 실행 경로의 종료를 보장하지 않는다. 특히 cycle을 허용한다면 종료 경로가 존재한다는 사실과 실제로 반복에서 빠져나온다는 사실은 다르다.

리뷰어 관점에서는 중요한 실행 제약을 어디에 둘지가 핵심이다. 반드시 지켜야 하는 도구 인자 범위나 권한을 수정 가능한 조언에만 맡기기보다, 환경의 검증 규칙과 별도로 관리하는 구성이 필요하다. 이는 논문이 이미 제공한 안전 보장을 설명하는 것이 아니라, soft guidance를 실제 시스템에 적용할 때 보완할 지점을 지적한 것이다.

Validation 재사용과 구성 요소별 기여

Validation gate는 학습 batch만 보고 수정안을 무조건 채택하는 것보다 합리적이다. 그렇지만 같은 validation을 반복해서 후보 선택에 사용하면 그 집합에 대한 적응이 누적된다. 특히 작은 표본과 동률 허용, cached score 비교에서는 노이즈가 채택 결정에 영향을 줄 수 있다. 최종 test를 분리하고 85%를 보고한 선택은 적절하지만, 여러 독립적인 evolution 실행으로 결과의 분산을 확인하면 근거가 더 강해질 것이다.

Rejection memory, validation gate, fresh rollout, topology 편집, 속성 수정은 함께 작동한다. 현재 construction 비교는 이 요소들을 하나씩 떼어 낸 완전한 ablation이 아니다. 따라서 성공의 원인을 rejection memory 하나나 그래프 연결 하나로 환원하기 어렵다. 마찬가지로 Table 1의 confidence interval은 공식 README 설명상 한 번의 greedy 실행에서 test 표본 크기로 생기는 불확실성을 나타낸다. 학습·진화 seed를 반복했을 때의 분산으로 해석할 수 없다.

도구 인터페이스 전이와 전체 운영 비용

저자들도 다른 solver와 도구 인터페이스로의 transfer를 후속 과제로 든다. 현재 노드 식별은 행동 이름에 의존하고, refiner는 기존 ID를 보존하도록 지시받는다. EnterpriseArena의 월 진행 규칙을 학습한 사례에서 보듯, 좋은 그래프가 특정 adapter의 의미에 맞춰질 수 있다. 같은 이름의 도구가 다른 상태 전이를 만들거나 새로운 도구 목록으로 바뀌면 기존 절차가 그대로 유효하다는 보장은 없다.

온라인 안내 비용에 더해 offline rollout과 validation, refiner 호출도 필요하다. 반복해서 사용할 업무라면 초기 비용을 나누어 부담할 수 있지만, 논문은 모든 과제에 대해 총 비용 회수 지점을 제시하지 않는다. 효과가 작은 HotpotQA 같은 설정에서는 정확도 개선과 추가 latency를 함께 비교해야 한다. 모델을 재학습하지 않는다는 사실은 유료 추론 호출이나 데이터 준비가 필요 없다는 뜻이 아니다.

시사점 / Takeaways

• 경험 저장의 다음 단계는 적용 위치의 표현이다. 좋은 조언을 모으는 것에 더해, 어떤 행동 뒤에 어떤 조건으로 써야 하는지를 연결할 수 있다.
• 절차 지식도 평가와 수정의 대상이다. 전문가가 만든 그래프라는 이유로 신뢰하지 않고 실제 과제의 실패로 검증하는 방식이 유용하다.
• 현재 단계에 맞는 작은 구조가 중요하다. 전체 그래프를 제공하는 것보다 local neighborhood를 이용한 안내가 좋은 결과를 낸다. 정보량 자체가 성능은 아니다.
• 짧은 행동 경로와 낮은 총비용을 구분해야 한다. Solver step, 환경 도구 호출, LLM 토큰, offline 학습 비용을 따로 관찰해야 한다.
• 수정 가능한 조언과 강제 제약은 역할이 다르다. PG의 유연성을 활용하면서도 실제 실행의 권한과 유효성은 별도로 보장할 필요가 있다.

설치 및 사용법

공식 저장소의 확인한 commit은 Python 3.10 이상과 Vertex AI credentials를 안내한다. README와 runner의 인자를 대조했으며, 아래 예시는 HotpotQA parquet 파일과 모델 접근 권한을 준비한 뒤 수행하는 소규모 실행이다.

git clone https://github.com/YuxingLu613/Procedural-Graph.git
cd Procedural-Graph
python3 -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

export GOOGLE_CLOUD_PROJECT="your-project-id"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/credential.json"

PYTHONPATH=src python3 src/experiments/run.py \
  --dataset=hotpotqa \
  --hotpotqa_dataset_path=/path/to/hotpotqa.parquet \
  --num_samples=5 --num_workers=1 \
  --llm=gemini-3.5-flash --llm_location=us-central1 \
  --method=react --guided_only=True \
  --gcp_project="${GOOGLE_CLOUD_PROJECT}"

데이터는 저장소에 포함된 파일이라고 가정하면 안 된다. HotpotQA adapter는 지정한 parquet가 없으면 오류를 내며, 코드에서 id, question, answer, context 등의 필드를 읽는다. 실제 API 권한과 사용 가능한 model·region도 환경에 맞게 준비해야 한다. 이 리뷰에서는 소스와 명령 구성을 확인했으며 유료 benchmark 실행이나 논문 점수 재현을 수행하지 않았다. 작은 실행 예시와 논문의 train/validation/test 분할을 갖춘 전체 진화 실험은 별개다.

참고 자료

• 논문과 arXiv 기록: v1 본문·참고문헌·부록 36쪽. 수치와 수식의 기준.
• 공식 코드: graph, guidance, refinement, dataset adapter와 experiment runner.
• 그림·표 출처: Lu et al. (2026)의 Figure 1·2·3·4와 Table 1·2·3·8. 원저작권은 각 권리자에게 있으며 연구 설명과 비평을 위해 인용한다. arXiv 비독점 배포 라이선스는 논문을 자유로운 재라이선스 대상으로 만든다는 뜻이 아니다.

더 읽어보기

• ReAct: Synergizing Reasoning and Acting in Language Models (Yao et al., ICLR 2023): 추론과 도구 행동을 번갈아 수행하는 기본 실행 구조.
• Cognitive Architectures for Language Agents (Sumers et al., 2023): Agent의 기억·행동·의사결정을 구분하는 CoALA 관점.
• AutoGuide: Automated Generation and Selection of Context-Aware Guidelines for Large Language Model Agents (Fu et al., 2024): 실행 경험에서 조건부 지침을 추출하고 현재 상황에 맞게 선택하는 가까운 선행 연구.
• Agent Workflow Memory (Wang et al., ICML 2025): 재사용할 행동 흐름을 경험에서 유도해 후속 실행에 제공하는 방법.
• Can LLM Agents Be CFOs? Benchmarking Long-Horizon Resource Allocation in an Uncertain Enterprise Environment (Han et al., 2026): 지연된 자금 조달과 유동성 제약을 포함하는 EnterpriseArena의 원 연구.