어제 저는 대형 모델이 미세 조정 (fine-tuning) 없이도 자신의 절차적 기술 (procedural skill) 중 일부를 소형 모델로 전이할 수 있는지 테스트하는 아이디어를 게시했습니다.

그 아이디어의 요약은 다음과 같습니다:
소형 모델들은 종종 지식이 완전히 결여된 것은 아닙니다. 그들은 구문 (syntax)을 알고, 라이브러리 (libraries)를 압니다. 보통 기본적인 수준에서 작업 내용을 이해합니다. 문제는 그들의 출력이 얕다는 점입니다. 그들은 계획 (planning), 계층 구조 (hierarchy), 분해 (decomposition), 시각적 구조 (visual structure), 그리고 더 큰 모델들이 더 자연스럽게 적용하는 듯한 단계별 규율 (step-by-step discipline)을 건너뜁니다.

그래서 저는 이러한 차이가 눈에 보이는 테스트를 원했습니다.
그것이 제가 Three.js를 사용한 이유입니다.
일반적인 코드 작업의 경우, 모델은 때때로 장황한 설명이나 익숙한 패턴 뒤에 약점을 숨길 수 있습니다. 하지만 Three.js를 사용하면 렌더링 (render)이 실제 구조를 드러냅니다. 만약 모델이 기하학 (geometry), 카메라 (camera), 조명 (lighting), 비율 (proportions), 계층 구조 (hierarchy), 그리고 구도 (composition)를 계획하지 않는다면, 결과물은 즉시 나빠 보입니다.

실험은 두 가지 도메인 (domain)을 기반으로 했습니다.
첫 번째 도메인은 복잡한 캐릭터 장면이었습니다: 여러 명의 식별 가능한 캐릭터, 애니메이션 (animation), 조명 (lighting), 무대 구성 (stage composition), 그리고 영화적 연출 (cinematic presentation)이 포함된 스릴러 스타일의 안무 (choreography) 장면입니다.
두 번째 도메인은 완전히 달랐습니다: 식별 가능한 실루엣을 가진 로우 폴리 (low-poly) BMPT-72 포탑입니다.
두 가지 모두 Three.js를 사용하지만, 같은 종류의 작업은 아닙니다. 하나는 캐릭터, 포징 (posing), 안무 (choreography), 환경 (environment), 그리고 스테이징 (staging)에 관한 것입니다. 다른 하나는 기계적 형태, 포탑 구조, 무기, 실루엣, 그리고 객체 비율에 관한 것입니다.

아이디어는 장면 자체를 전이하는 것이 아니었습니다. 아이디어는 프로세스 (process)를 전이하는 것이었습니다.

간소화된 프로토콜은 다음과 같습니다:
A = 더 큰 모델, B = 더 작은 모델, P1 = 소스 프롬프트 (source prompt), P2 = 타겟 프롬프트 (target prompt), S = 절차적 스캐폴드 (procedural scaffold)

먼저:
A + P1 -> D1A, A + P2 -> D2A, B + P1 -> D1B, B + P2 -> D2B

그다음, 더 큰 모델은 첫 번째 도메인에서 더 작은 모델이 보인 약점을 바탕으로 스캐폴드 (scaffold)를 생성합니다:
A + P1 + D1B의 코드/렌더링 -> S

중요한 규칙은 S를 생성하는 모델이 P2를 보지 않고, D2A를 보지 않으며, 타겟 도메인 테스트가 무엇인지 알지 못해야 한다는 것입니다.

그다음 더 작은 모델을 다시 실행합니다:
B + S + P1 -> D1B_S, B + S + P2 -> D2B_S

진정한 질문은 다음과 같습니다:
D2B_S가 D2B보다 D2A에 더 가까워졌는가?

다시 말해, 스캐폴드 (scaffold)가 정답을 보여주지 않고도 다른 작업에서 더 작은 모델을 개선했는가 하는 점입니다.

저는 첫 번째 수동 테스트를 수행했고 그 결과물을 영상에 담았습니다.
이것은 아직 공식적인 벤치마크 (benchmark)는 아닙니다. 단지 이 효과가 나중에 자동화할 수 있을 만큼 충분히 실재하는지 확인하기 위한 첫 번째 건전성 검사 (sanity check)일 뿐입니다.

결과는 실제로 꽤 명확했습니다.
이미 훨씬 강력한 모델인 DeepSeek V4 Pro의 경우, 스캐폴드 (scaffold)가 도움이 되긴 했지만 주로 다듬기 (polish) 수준이었습니다. 조명, 표현력, 장면 장식, 그리고 전반적인 아트 디렉션 (art direction)을 개선했습니다. 하지만 베이스라인 (baseline) 자체가 이미 구조적으로 괜찮았기 때문에 차이가 엄청나지는 않았습니다.

그 부분은 저에게도 납득이 갑니다. 더 큰 모델은 이미 더 깊은 내부 계획 능력을 갖추고 있습니다. 스캐폴드 (scaffold)가 모델에게 새로운 뇌를 제공하는 것은 아닙니다. 그것은 주로 모델이 더 명시적이고 일관되게 행동하도록 밀어붙이는 역할을 합니다.

훨씬 더 큰 차이는 Qwen 27B와 Q3_K_M으로 양자화 (quantized)된 35B A3 모델에서 나타났습니다.
스캐폴드 (scaffold)가 없을 때, Qwen의 출력물은 종종 소형 모델 특유의 실패 모드 (failure mode)를 보였습니다: 어두운 장면에 물체를 던져 넣거나, 취약한 환경, 낮은 대비, 얕은 계층 구조, 그리고 기술적으로는 프롬프트의 일부를 충족하지만 실제로 읽기 쉬운 장면을 형성하지 못하는 원시적인 형태들이 나타났습니다.
스캐폴드 (scaffold)를 사용하자, 동일한 모델이 다르게 행동하기 시작했습니다.

Thriller 장면에서는 더 읽기 쉬운 무대를 생성하였고, 캐릭터를 더 잘 분리했으며, 환경적 구조를 추가하고, 더 강한 조명을 사용하였으며, 장면에 더 많은 깊이감을 부여했습니다. 여전히 완벽하지는 않았지만, 어두운 공허 속에서 서로 연결되지 않은 원시적 형태들처럼 보이지는 않게 되었습니다.

포탑 (turret) 작업에서도 개선이 눈에 띄었습니다. 베이스라인 (baseline)은 일반적인 어두운 블록 형태의 차량에 가까웠습니다. 스캐폴드 (scaffold)를 적용한 버전은 더 명확한 차체, 더 나은 포탑 구조, 더 의도적인 무기 배치, 측면 디테일, 센서 같은 요소들, 그리고 더 읽기 쉬운 실루엣을 보여주었습니다.

35B Q3_K_M 결과 또한 흥미로웠습니다. 심한 양자화 (quantization)가 적용되었음에도 불구하고, 스캐폴드가 구조를 유지하는 데 도움을 주는 것으로 보였습니다. 프런티어 모델 (frontier model) 수준이 된 것은 아니지만, 베이스라인보다 구축 프로세스를 더 잘 따랐습니다.

저에게 가장 중요한 부분은 스캐폴드가 단순히 첫 번째 도메인을 복사하지 않았다는 점입니다.
그것은 Thriller의 디테일을 탱크에 넣지 않았습니다. 포탑에 인간의 팔다리를 추가하지 않았습니다. 캐릭터 장면과 기계적 객체를 혼동하지 않았습니다.
전이된 것은 더 추상적인 것이었습니다:
코딩 전 계획 세우기, 장면 계약 (scene contract) 정의하기, 레이어별로 구축하기, 피사체/환경/조명/카메라 분리하기, 실루엣 보존하기, 정체성 단서 추가하기, 단순한 원시 객체만 있는 상태 피하기, 최종 출력물 감사하기

이것이 바로 제가 테스트하려고 했던 바로 그 종류의 것입니다.
저의 현재 해석은 이것이 일반적인 "더 나은 프롬프트 (better prompt)"처럼 작동하기보다는, 외부적인 계획 스캐폴드 (planning scaffold)처럼 작동한다는 것입니다. 소형 모델들은 종종 작업의 일부를 수행할 만큼 충분한 지식을 가지고 있지만, 긴 생성 과정 전체에 걸쳐 전체 구조를 유지하지는 못합니다. 스캐폴드는 컨텍스트 (context) 내에서 모델에게 일시적인 계획 규율 (planning discipline)을 제공합니다.

이 효과는 또한 비대칭적인 것으로 보입니다.
더 큰 모델은 주로 다듬기 (polish) 측면에서 약간 개선되었습니다.
소형 모델들은 특히 구조와 가독성 측면에서 훨씬 더 많이 개선되었습니다.
이는 원래의 가설과 일치합니다: 소형 모델은 지식은 가지고 있을지 모르지만, 그것을 안정적으로 조직할 만큼의 절차적 제어력 (procedural control)은 부족할 수 있습니다.

다시 말하지만, 이것은 아직 증명된 것이 아닙니다.
다음 단계는 이를 적절한 블라인드 테스트 (blind test)로 전환하는 것입니다:
D2A = 대형 모델의 타겟 도메인 (target-domain) 출력
D2B = 소형 모델의 베이스라인 (baseline) 타겟 도메인 출력
D2B_S = 스캐폴드 (scaffold)를 사용한 소형 모델의 타겟 도메인 출력
그다음, 별도의 블라인드 평가자 (blind evaluator)가 어떤 모델이 어떤 출력을 생성했는지 알지 못하고 코드를 보지 않은 상태에서, 오직 렌더링된 이미지만을 비교해야 합니다.
핵심 지표는 다음과 같습니다:
Score(D2A, D2B_S) > Score(D2A, D2B)
만약 이것이 많은 프롬프트 (prompts)에 걸쳐 성립한다면, 스캐폴드는 단순히 하나의 예시를 개선하는 것이 아닙니다. 그것은 재사용 가능한 절차 (reusable procedure)를 전이 (transferring)하고 있는 것입니다.
현재로서는 이것을 예비적인 수동 결과 (preliminary manual result)라고만 부르겠습니다. 하지만 출력물들을 나란히 놓고 본 결과, 이 아이디어는 더 진지하게 테스트할 가치가 있다고 생각합니다.
지금까지의 주요 시사점은 다음과 같습니다:
하나의 Three.js 도메인에서 유도된 스캐폴드가 미세 조정 (fine-tuning) 없이, 그리고 타겟 도메인의 정답을 보지 않고도, 소형 모델이 다른 Three.js 도메인에서 더 나은 구조를 생성하도록 돕는 것으로 보입니다.
이것이 소형 모델이 대형 모델만큼 좋아진다는 것을 의미하지는 않습니다.
이는 대형 모델이 자신의 계획 규율 (planning discipline) 중 일부를 재사용 가능한 추론 시간 (inference-time) 구조로 외재화 (externalize)할 수 있음을 의미합니다.
그것이 제가 다음에 제대로 테스트하고 싶은 부분입니다.
submitted by /u/ConfidentDinner6648
[link] [comments]