Tool call과 Memory
Kanana-2 SLM 개발기에서 tool call이 post-training의 주요 도메인으로 채택된 점에 주목, 학습 단계별 성능 표에서 병합 구간에 tool이 가장 크게 하락하는 현상과, 그 성능이 하나의 metric으로만 보고된 아쉬움, 그리고 이어지는 memory 연구에 대해 고민해보고자 한다. 파이프라인 전반에 대한 정리는 앞선 포스트 참고.
Motivation
7월 28일 공개된 Kanana-2 경량 모델의 개발기에서 이전 세대와 달라진 지점이 하나 분명하게 드러난다.
최근 온디바이스 환경에서도 Tool Call에 대한 필요성이 대두되고 있는 만큼, 지난 SLM 시리즈와 다르게 SFT 단계부터 Tool Call을 위한 다양한 소스의 데이터를 학습에 사용하였습니다.
tool call이 사후학습 파이프라인의 주요 도메인으로 채택됐다고 이해된다. 3B의 post-training은 instruction following, math, code, tool, chat, knowledge 여섯 개 도메인으로 나뉘어 각각 RL, 그 결과를 SCE 방식으로 병합, calibration한다. tool use가 math나 code와 주요 reasoning task와 같은 층위라는 의미로, 온디바이스 모델의 존재 이유가 대체로 “기기 안에서 뭔가를 실제로 수행하는 것”이기 때문에 합리적이고 필수적인 선택이라고 본다. 다만 tool-call task 자체의 난이도나 위상을 두고 판단하기는 애매한데, 벤치마크 레벨에서는 다 풀린 문제처럼 보이기도 하지만, 실제 유저 경험 수준에서의 만족도가 align되지 않았다는 문제 제기식 벤치마크가 우후죽순 쏟아지는 추세이기 때문이다. 어쨌든 연구자 입장에서 모델이 더 잘 해주었으면 하는 관심의 범주에는 항상 속하고 있는 것으로 보이고, 개인적으로는 관심 task이므로… 측정 측면에서 주의해볼 지점이 있는 것 같아 정리해보고자 한다.
병합 단계에서의 tool 성능 하락
| Stage | IF | Math | Code | Tool | Chat | Knowledge | Avg. (Macro) |
|---|---|---|---|---|---|---|---|
| SFT | 44.93 | 47.64 | 62.56 | 71.51 | 40.73 | 39.63 | 46.18 |
| Merge | 62.39 | 56.18 | 61.61 | 65.84 | 46.17 | 41.46 | 50.95 |
| Calibration | 62.56 | 57.05 | 61.31 | 71.94 | 47.58 | 40.74 | 51.52 |
개발기에 실린 3B의 학습 단계별 성능 표는 그 자체로 살펴볼 게 많은데, 병합 단계에서 instruction following은 45에서 62로 크게 오르고 math도 48에서 56으로 오른다. 평균은 46에서 51로 올라간다.
반면 tool은 71.51에서 65.84로 떨어진다. code도 62.56에서 61.61로 소폭 내려가지만, 하락 폭은 tool이 압도적으로 크다. calibration이 71.94로 되돌려놓긴 하지만, 전체 파이프라인에서 tool call은 SFT 직후 값을 겨우 회복하는 데 그친다. 대부분의 도메인이 병합으로 gain을 얻는 동안 tool은 잃은 것을 되찾느라 두 단계를 쓴 셈이다.
도메인별 expert를 합칠 때 tool call 능력이 유독 취약하다는 관찰인데, 개발기는 이 현상을 따로 해설하지 않는다. tool 능력이 다른 능력들과 표현 공간에서 충돌하는 것인지, 아니면 tool 데이터가 출력 형식에 민감해서 가중치 평균에 특히 약한 것인지는 표만으로 판별할 수 없다. (후자라면 형식 준수는 회복이 쉽고 실제 도구 선택 능력은 손실이 남아 있을 가능성도 있어, 집계 점수만으로는 구분이 안 된다.) 다만 개인적으로 추정하기로는 형식적인 측면의 누수가 있지 않았을까 싶다. 최신 tool-call 연구들에서도 실제 reasoning capacity가 성능면에서 보호되는 것이 형식적 제약 준수라는 결과도 보고된 바 있기에, scale-up된 모델들의 역량도 이와 일정 수준 align될 수 있다는 추정이다.
측정 축 정의: Live vs Multi-Turn
개인적으로 더 살펴보고 싶은 지점은, 표에서도, 다른 모델과 비교한 bar chart에서도 tool call은 단일 metric으로 보고되고 있다는 점이다.
같은 계열 30B 모델 카드를 확인해보면 tool call benchmark BFCL 기준 성격이 다른 두 축으로 score가 나뉜다.
- Live: 한 번의 요청에 대해 적절한 함수와 인자를 골라내는 능력. 6개 live 벤치마크 평균.
- Multi-Turn: 대화가 이어지는 동안 여러 번 호출하고, 결과를 받아 다음 행동을 정하고, 실패하면 복구하는 능력. 4개 multi-turn 벤치마크 평균.
| Model | Live | Multi-Turn |
|---|---|---|
| kanana-2-30b-a3b-instruct-2601 | 76.66 | 38.63 |
| Qwen3-30B-A3B-Instruct-2507 | 73.93 | 38.77 |
| kanana-2-30b-a3b-thinking-2601 | 75.9 | 43.7 |
| Qwen3-30B-A3B-Thinking-2507 | 82.9 | 53.6 |
4종의 모델 모두 multi-turn에서 크게 하락하고, instruct 계열은 절반 수준으로, thinking 계열도 35% 이상 하락한다. single-turn tool-call은 사실상 saturate 됐다고 볼 수 있고, sequential하게 이어지는 tool use에서의 challenge가 남았다고 해석된다.
현재 kanana slm에서 보고된 Tool 71.94는 어느 쪽인지 알 수 없는데, live 계열 위주라면 30B의 76.66과 비슷한 종류의 성취이고, multi-turn이 상당 비중 섞여 있다면 3B 모델치고 꽤 괄목할만한 수치일지도. (알 수는 없겠지만)
참고로 1월 릴리스 당시 보도는 이 모델군이 Qwen 대비 multi-turn tool call에서 우위라고 전했는데, Live(76.66 vs. 73.93) 한정이었던 것 같고 Multi-Turn은 38.63 대 38.77로 노이즈 범위 안에서 근소하게 진다.
현실적 어려움: Multi-Session Multi-Turn Dialogue
BFCL의 multi-turn은 단일 세션에서 평가하는 task로 대화가 시작되고, 여러 턴이 오가고, 대화가 종료된다. 그 안의 모든 정보는 context에 전부 들어 있고, 따라서 기억의 문제가 아니라 계획과 복구의 문제로 환원할 수 있을 것이다.
사실 현실의 문제는 multi-turn에서 그치는 게 아니라, 그 multi-turn 발화가 묶은 multi-session dialogue 환경이라는 지점이 실제 사용자 경험에서의 주요한 challenge로 지적된다. 온디바이스 personal assistant라면 더욱이, 매번 세션이 끊기고, long-horizon으로 구성되는 것이 일반으로, 과거의 session에서의 tool args를 반영하는 능력은 BFCL multi-turn이 재는 대상조차 아니라는 점. 그래서 최신 agent에게 요구되는 memory 등의 모듈이 이 challenge 해결의 한 가지 축이 된다.
Personal Insight
Kanana-2 의 개발기에는 사전학습과 사후학습 어디에도 카카오 사용자 데이터를 쓰지 않았다는 것을 강조하는데, 당연히도, 프라이버시 관점에서 옳은 그리고 필수적인 결정이지만, 동시에 이 결정은 personalization의 위치를 모델 밖으로 강제한다. 사용자에 대한 지식은 모델 파라미터 안에 존재할 수 없기 때문에 남는 자리는 추론 시점의 메모리뿐으로, 무엇을 저장하고, 무엇을 꺼내오고, 그걸 어떻게 도구 호출 결정에 반영할 것인지는 학습 문제가 아니라 메모리 설계 문제가 된다. 이 문제가 이론적 관심 수준이 아니라 이미 배포된 제품의 제약 조건이라는 의미로, 올해 출시된 카나나 인 카카오톡(이전 포스트) 역시 같은 모델을 활용하며 같은 문제를 풀고 있을 것으로 추측된다.
최근 산업계에서 continual learning이 주요 키워드로 떠오르는 시점이라, 이것이 상용 서비스 레벨로 구현된다면 memory라는 개념 자체가 사장될지도 모른다는 의문도 함께 갖고 있다. 지금의 외부 메모리는 프라이버시 같은 산업적인 사유로 데이터를 모델 밖에서 관리해야 해서 존재하는 것인데, context engineering으로 감당하는 방식의 한계 역시 명확하기 때문이다. 다만 memory가 과도기 기술인지 본질적인 모듈인지는 continual learning이 상용 레벨에 도달하는 속도가 판정할 문제고, 적어도 지금 배포된 제품의 제약 조건 아래에서 개인화가 놓일 자리는 추론 시점의 memory뿐이다. 차기 연구 방향에 고민이 많은 시점에, memory module 자체의 효용과 방향성을 여기서부터 따져보려고 한다.