WikiSkill: Compiling Agent Experience into Persistent Knowledge for Skill Evolution
- 게시일: 2026-08-30
- arXiv: 2608.27454v1 · PDF
- 저자: Liyan Tang, Cyrus Rashtchian, Chun-Sung Ferng, Andrew Tomkins, Da-Cheng Juan, Tu Vu
- 분야: cs.AI, cs.CL
- 선정 점수: 3.79
- 선정 이유: 최근성 0.5, 인용 영향 0.0 (인용 0회), 저자 영향 0.0 (최고 h-index 0), AI 주제 적합성 2.2, 개발자 관심 0.2, 학술 신호 0.9, 오픈 웨이트·주요 연구조직 신호 0.0
← 2026-08-30 목록으로 돌아가기
한 문장 요약
에이전트의 실행 기록을 불변으로 보관하고, 실행에서 추출한 패턴을 지속적으로 누적하는 위키(Wiki)로 컴파일한 뒤 이를 기반으로 절차적 스킬을 반복적으로 제안·검증해 스킬 품질을 향상시키는 WikiSkill 프레임워크를 제안한다.
해결하려는 문제
기존의 자동 스킬 발견·진화 방법들은 에이전트 경험에서 얻은 통찰이 최종 스킬 문서, 리젝된 제안 기록, 최적화 히스토리 등 여러 산재한 산물에 흩어져 있어 반복적 개선 과정에서 체계적으로 재사용되기 어렵다. 논문은 경험을 지속적·구조화된 지식 표현으로 컴파일하면 스킬 진화의 안정성과 전달성을 높일 수 있는지 탐구한다.
핵심 기여
- WikiSkill 프레임워크 제안: 불변 실행 기록(Raw Layer), 누적·구조화된 지식(Wiki Layer), 실행 가능한 절차 스킬(Skill Layer)로 작업공간을 분리하고 이들을 공동 진화시키는 루프를 제시함.
- 위키 기반 패턴 집적 및 스킬 제안 파이프라인 설계: Wiki Maintainer가 샘플된 실행 궤적을 바탕으로 패턴 페이지와 진화 로그를 지속적으로 업데이트하고, ReAct 스타일의 Skill Proposer가 위키와 궤적을 읽어 스킬 제안을 생성함.
- 광범위한 실험: 5개 벤치마크(LiveMath, SealQA, SpreadSheet, OfficeQA, ALFWorld)와 5개 추론 모델(Qwen 계열 3개, Gemma-4-31B, Gemini-3.5-Flash)에서 기존 스킬 진화 기법들(Trace2Skill, EvoSkill, SkillOpt)과 비교하여 일관된 성능 향상을 보임.
- 스킬 전이 및 스케일링 분석: 스킬 진화가 모델 스케일과 보완적임을 보였고, 다른 모델이 진화시킨 스킬의 전이 효과가 크며 때로는 자체 진화 스킬보다 우수하다는 것을 실증함.
- 소거실험을 통한 위키의 중요성 검증: 스킬 제안자에게 위키 접근을 허용하면 성능이 크게 향상되나(예: Gemini-3.5-Flash 평균 48.7% → 63.7%), 학습 롤아웃 단계에서 Inference Agent에게 위키를 열어주면 오히려 성능이 떨어짐(63.7% → 60.9%).
접근 방법
- WikiSkill은 작업공간을 Raw Layer(불변 실행 트레이스), Wiki Layer(패턴 문서·진화 로그·스킬 영향 추적기), Skills Layer(파일시스템 기반 SKILL.md·PURPOSE.md)로 나눈다.
- 반복 루프는 네 단계로 구성된다: (1) Inference Agent가 현재 활성 스킬을 시스템 프롬프트에 완전 주입하여 훈련 데이터에 대한 롤아웃을 수행하고 불변 트레이스를 raw/에 기록한다(학습 롤아웃 동안 Inference Agent는 위키 접근 금지).
- (2) Wiki Maintainer가 샘플된 트레이스(Tsample, 최대 8개: 최대 5개의 실패·최대 3개의 성공)를 읽어 루트 원인 분석을 수행하고 wiki/patterns/에 새 패턴 생성이나 패치, index.md·logs.md 갱신을 수행한다.
- (3) Skill Proposer는 ReAct 스타일의 다중 턴 에이전트로서 wiki 인덱스와 skill-impact.md, 훈련 결과 요약을 먼저 읽고 필요한 패턴 페이지와 raw 트레이스를 read_file 도구로 온디맨드 조회하여 단일 스킬에 대한 생성 또는 패치 제안을 만든다.
- 제안은 원자적(하나의 스킬 대상)이다.
- (4) Gating & Rollback가 제안된 스킬을 적용한 후보 스킬셋을 검증 분할에 대해 평가하여 검증 점수가 이전 최고치보다 높으면 수용하고 그렇지 않으면 스킬만 롤백한다.
- 위키는 결코 롤백되지 않고 누적된다.
- 구현상 스킬은 SKILL.md와 PURPOSE.md를 포함하는 디렉터리 형태이며, 실험에서는 스킬을 Inference Agent의 시스템 프롬프트에 전부 주입(Full-injection)해 스킬 검색 실패의 영향을 배제한다.
- 샘플링·토큰 제한(각 로그 최대 15,000자)과 ReAct 턴 수(논문 실행에서 약 10–20)를 명시하며, 실험에서는 배치 크기 B를 훈련 전체로 두어(풀 배치) WikiSkill의 옵티마이저 LLM 호출 수는 1 + T_ReAct로 상수화하였다.
주요 결과
- 전반적 성능: 다섯 모델 평균에서 WikiSkill이 모든 비교 방법 중 최고 평균 성능을 달성함(표 1). 모델별로 WikiSkill은 Qwen-3.5-4B/9B/27B에서 각각 평균 +3.3, +5.1, +10.0(또는 +12.3, +17.5, +23.9라고 본문에 표기된 Qwen 계열 스케일별 증가치도 제시됨) 포인트 향상을 보고함.
- 구체적 수치(모델·벤치마크 예시): Qwen-3.5-9B에 대해 WikiSkill 평균 정확도 47.4%로, Qwen-3.6-27B의 노스킬 39.4%보다 높아(47.4% vs 39.4%) 스킬로 모델 스케일 차이를 보완할 수 있음을 보임. Gemini-3.5-Flash에서 LiveMath는 노스킬 33.0% → WikiSkill 72.6%로 대폭 향상되었고, SpreadSheet는 50.5% → 76.6%로 향상되었음 (표 1).
- 전이 실험: Table 2에서 다른 모델이 진화시킨 스킬의 전이 성능을 평가한 결과, 예컨대 Qwen-3.6-27B에서 진화된 SpreadSheet 스킬은 Qwen-3.5-9B의 SpreadSheet 성능을 24.3%(노스킬)에서 50.5%로 높였으며(자체 진화 스킬 대비 우수: 33.6%), ALFWorld에서 Qwen-3.5-9B가 Qwen-3.6-27B가 진화한 스킬을 쓰면 70.2%에 도달하여 자체 스킬(63.4%)보다 높음.
- 위키의 중요성: 소거실험(Table 3)에서 Skill Proposer에게만 위키 접근을 허용하면(기본 설정) 평균 성능이 48.7% → 63.7%로 크게 향상되며, 반대로 Inference Agent에게도 위키 접근을 허용하면 평균이 63.7% → 60.9%로 하락한다.
- 스킬·위키 동태 통계: Table 4에 따르면 모델별로 제안/수용된 스킬 생성 수와 편집 수, 평균 스킬 길이(예: Qwen 계열의 스킬 평균 길이 약 118.9–128.6행, Gemma·Gemini는 더 짧음) 및 벤치마크별 패턴 수(SpreadSheet가 가장 많은 패턴과 긴 스킬을 생산함) 등을 보고함.
한계
- 저자가 명시한 한계: (1) 스킬 검색·트리거(대규모 스킬 라이브러리에서 관련 스킬을 골라내는 문제)를 평가하지 않음(실험에서 스킬을 시스템 프롬프트로 전부 주입하여 검색 문제를 배제). (2) 검증 게이팅이 ‘검증 점수 개선’이라는 엄격한 기준만 허용하므로 중립적(벌크적으로 성능 변화가 없는) 제안은 수용되지 않아 장기적 이득을 고려하지 못할 수 있음. (3) 위키를 자동으로 정리(Pruning)하는 메커니즘을 제공하지 않아 장기간 축적 시 관리 비용이 발생할 수 있음. (4) 매우 긴 수백 단계·수시간에 걸친 장기 작업(long-horizon tasks)은 본 벤치마크에 포함되지 않아 해당 설정에서의 온라인 적응성은 검증되지 않음.
- 본문에서 확인되는 제약·실험적 범위: 검증 분할이 작아 게이팅 결정에 노이즈가 있을 수 있으며(저자도 이를 인정), 실험은 배치 크기 B를 훈련 전체로 설정한 풀배치 모드로 진행되어 다른 배치 설정에서의 비용·성능 트레이드오프는 추가 확인이 필요함. 또한 일부 전이 상황에서는 소스 스킬이 저수준 작업회피(작은 모델용 워크어라운드)를 인코딩해 강한 모델에 부정적 전이를 일으킬 수 있음.
개발자 관점
- 재현을 위해 필수 요소: 작업공간을 raw/, wiki/, skills/로 분리하고 wiki에는 patterns/, logs.md, skill-impact.md를 구현하여 제안·수용 이력을 기록해야 함.
- Wiki Maintainer와 Skill Proposer는 명확한 프롬프트 규약을 따름: Maintainer는 샘플된 최대 8개 트레이스(최대 5 실패·3 성공)를 받아 루트원인 분석과 패턴 페이지 패치·생성을 수행해야 하며, Proposer는 ReAct 멀티턴 에이전트로 wiki/index.md 및 skill-impact.md를 먼저 읽고 read_file로 필요한 트레이스를 온디맨드 조회해야 함. Proposer는 제안 제출 전에 최소 4개 트레이스를 읽도록 요구함(프롬프트에 명시).
- 운영·비용 관점: 본문 설정(풀배치)에서는 각 반복당 LLM 호출 수가 1 + T_ReAct(약 10–20)로 상수화되어 호출 횟수는 Ntrain에 무관하지만 ReAct 내부 턴과 각 읽기·패치의 비용이 크므로 비용 산정 시 단일 반복의 LLM 비용을 상세히 계산해야 함. 반대로 미니배치 운영 시 다른 기법들과 호출 복잡도가 달라질 수 있음(Trace2Skill·EvoSkill·SkillOpt는 Ntrain/ B에 비례).
- 설계 권고: 훈련 롤아웃 단계에서는 Inference Agent에게 위키 접근을 금지해(본 논문 실험 결과 기반) 롤아웃이 스킬 실행에서 발생하는 실패·성공 신호를 보존하게 하라. 스킬은 SKILL.md와 PURPOSE.md를 페어로 관리하여 스킬→위키 연결고리를 명확히 하라.
- 전이·호환성 검증: 다른 모델에서 진화된 스킬을 배포하기 전에는 타깃 모델에서 부정적 전이(예: 저수준 워크어라운드가 강한 모델의 엔드투엔드 스크립트 실행을 방해하는 사례)를 점검하고, 스킬의 ‘적용 조건(When to Apply / When NOT to Apply)’을 명시해 모델별 실행 능력 차이를 완화하라. 또한 위키에 대한 자동 정리(pruning)·정렬·중복 합병 정책을 마련해야 장기간 운영에서 유지비를 낮출 수 있다.
근거 범위: 이 분석은 제공된 논문 PDF 본문(페이지 1–24, 부록 포함)에 근거해 작성되었다. 표·숫자·실험 설정(샘플링 예산, 배치 설정, ReAct 턴 범위 등)은 본문에 직접 명시된 내용만 사용했고, 구현의 세부 하이퍼파라미터(예: 정확한 온톨로지·LLM 모델 파라미터 값)나 내부 로그의 전체 내용 등 PDF에서 확인되지 않는 부분은 추정하지 않았다.