huggingface.co의 「Jupyter Agents: training LLMs to reason with notebooks」는 노트북 안에서 코드 실행을 핵심 도구로 둡니다.
첫 기준선은 쉬운 분할 44.4%, 어려운 분할 2.1%였고, 단순화 뒤 쉬운 분할은 59.7%까지 올랐습니다.
실무에서는 벤치마크 분리, 스캐폴딩 축소, 중복 제거를 먼저 봐야 합니다.
huggingface.co의 「Jupyter Agents: training LLMs to reason with notebooks」는 주피터 노트북 안에서 코드 실행을 에이전트의 핵심 도구로 삼는 실험을 설명합니다. Hugging Face는 큰 모델만 보지 않고, 작은 모델이 데이터 과학 작업에서 어디까지 버티는지 함께 확인합니다.
Hugging Face는 왜 주피터 노트북 안에 에이전트를 넣었나?
Hugging Face는 노트북을 단순한 문서가 아니라 실행 환경으로 봅니다. 코드 셀과 마크다운 셀이 함께 있으니, 추론과 실행을 같은 화면에서 이어 갈 수 있습니다. 원문은 이 구성을 데이터 분석과 데이터 과학 작업을 풀기 위한 에이전트로 설명합니다.
이 글의 목표는 세 단계로 정리됩니다. 먼저 고품질 학습 데이터를 만듭니다. 그다음 작은 모델을 미세 조정합니다.
마지막으로 벤치마크에서 성능 변화를 확인합니다.
평가 기준으로는 Adyen과 함께 만든 DABStep를 사용합니다. 이 벤치마크는 실제 데이터 과학 질문을 주고 답하게 만듭니다. 원문은 여기서부터 작은 모델의 한계를 정면으로 봅니다.
기준선과 정제 효과는 숫자로 얼마나 갈렸나?
원문이 밝힌 숫자는 시작점, 데이터 정제, 스캐폴딩 변화로 나뉩니다. 아래 표는 원문에서 확인된 값만 정리한 것입니다.
| 항목 | 원문 값 | 무엇을 재는가 |
|---|---|---|
| 하드 작업의 기본 상태 최고 모델 | Claude 4 Sonnet | 기본 상태에서 하드 작업이 얼마나 어려운지 |
| 첫 작은 모델 | Qwen3-4B-Thinking-2507 | 작은 모델 기준선의 출발점 |
| 쉬운 작업 기준선 정확도 | 44.4% | 첫 모델의 쉬운 분할 성능 |
| 어려운 작업 기준선 정확도 | 2.1% | 첫 모델의 어려운 분할 성능 |
| 단순화한 스캐폴딩의 길이 | 약 200줄의 코드 | 모델 주변 제어 코드를 얼마나 줄였는지 |
| 외부 의존성 | 없음 | 실행 구조를 얼마나 단순화했는지 |
| 쉬운 분할 개선 후 정확도 | 59.7% | 스캐폴딩 단순화 뒤의 쉬운 분할 성능 |
| 원시 노트북 규모 변화 | 약 2TB → 약 250GB | 중복 제거로 줄인 저장량 |
| 원시 노트북 중복률 | 약 90% | 학습 데이터가 중복으로 얼마나 오염됐는지 |
| 점수화 모델과 척도 | Qwen3-32B, 1에서 5까지 | 노트북의 설명성, 완성도, 교육적 가치를 평가한 기준 |
| 제거 비율 | 약 70% | 품질 필터가 걸러 낸 비중 |
the best out-of-the-box model is Claude 4 Sonnet which reaches not even 20% accuracy on the hard tasks
Stripped it down to ~200 lines of code. No external dependencies.
Results: accuracy jumped from 44.4% → 59.7% (easy split)
더 많은 도구보다 더 얇은 스캐폴딩이 나았나?
보통은 에이전트가 복잡할수록 더 잘 풀 것이라 생각하기 쉽습니다. 그러나 원문은 반대 방향의 신호를 보여 줍니다. smolagents와 Qwen-Agent처럼 도구와 프롬프트가 많은 구조를 그대로 따르지 않고, 필요한 최소 기능만 남겼습니다.
원문은 스캐폴딩을 약 200줄로 줄이고 외부 의존성을 없앴다고 밝힙니다. 그 결과 쉬운 분할 정확도는 44.4%에서 59.7%로 올랐습니다. 즉, 제어 구조가 많을수록 좋은 것이 아니라, 모델이 해야 할 일이 또렷해야 할 때가 있습니다.
또한 원시 노트북의 약 90%가 중복이었습니다. 데이터가 많아 보여도 같은 예제가 반복되면 학습 신호가 흐려집니다. 원문은 이 중복을 먼저 걷어 내지 않으면 훈련이 왜곡될 수 있다고 보여 줍니다.
내 시스템에서는 무엇을 먼저 줄이고 무엇을 남겨야 하나?
1) 평가를 먼저 나눕니다
쉬운 작업과 어려운 작업을 따로 측정해야 합니다. 한쪽 수치만 보면 작은 모델의 실제 한계를 놓치기 쉽습니다. 원문처럼 기준선을 먼저 세우면 개선 폭도 더 정확히 보입니다.
2) 에이전트 루프를 최소화합니다
코드 실행과 final_answer처럼 꼭 필요한 도구만 남깁니다. 원문은 이런 단순한 루프가 더 잘 맞았다고 설명합니다. 스캐폴딩을 줄인 뒤에야 성능 변화가 분명해집니다.
3) 학습 데이터는 점수화합니다
노트북을 모두 넣지 않고, 설명성, 완성도, 교육적 가치로 거릅니다. 원문은 Qwen3-32B로 각 노트북을 1에서 5까지 매기고, 약 70%를 제거했습니다. 데이터 수보다 재현 가능한 기준이 먼저입니다.
내일 적용할 체크리스트는 단순합니다. 중복률, 도구 수, 종료 조건, 평가 분리를 먼저 확인합니다. 이 네 가지를 점검하면 모델 문제와 데이터 문제를 더 빨리 가를 수 있습니다.
자주 묻는 질문
Q. 작은 모델로도 노트북 에이전트를 만들 수 있나요? A. 가능합니다. 원문은 Qwen3-4B-Thinking-2507을 첫 기준선으로 삼고, 쉬운 분할에서 59.7%까지 올렸습니다.
Q. 왜 노트북 코퍼스를 2TB에서 250GB로 줄였나요? A. 중복이 약 90%였기 때문입니다. 비슷한 노트북이 너무 많으면 학습이 한쪽으로 치우칩니다.
Q. 스캐폴딩을 줄이면 항상 성능이 오르나요? A. 항상 오르지는 않습니다. 다만 이 글에서는 약 200줄과 외부 의존성 제거 뒤 쉬운 분할이 개선됐습니다.
원문: 「Jupyter Agents: training LLMs to reason with notebooks」