Golden Gate Claude 이후로 저는 "steering (조종)"에 매료되었습니다. 이는 모델의 추론 과정(mid-flight) 중에 모델의 활성화 값(activations)을 직접 조작함으로써 LLM의 출력을 유도할 수 있다는 아이디어입니다.

DeepSeek V4 Flash

저는 antirez의 최근 프로젝트인 DwarfStar 4에 영감을 받아 이 글을 쓰게 되었습니다. DwarfStar 4는 DeepSeek-V4-Flash만 실행할 수 있도록 경량화된 llama.cpp의 버전입니다. 이 모델의 특별한 점은 무엇일까요? 아마도 많은 엔지니어들이 기다려온 것일지도 모릅니다. 즉, 최소한 프런티어 모델(frontier model)의 에이전트 기반 코딩(agentic coding) 하위 수준과 경쟁할 수 있을 만큼 성능이 좋은 로컬 모델입니다.

steering을 수행하려면 로컬 모델이 필요하기 때문에, 이제 많은 엔지니어가 처음으로 이를 시도해 보는 것이 실질적으로 가능해졌습니다. 실제로 antirez는 DwarfStar 4에 steering을 일급 시민(first-class citizen)으로 포함시켰습니다. 현재는 매우 초보적인 수준이지만(기본적으로 프롬프팅을 통해 재현할 수 있는 장난스러운 "verbosity (말투의 장황함)" 예시 수준입니다), 초기 릴리스가 나온 지 불과 8일밖에 되지 않았습니다. 저는 이 프로젝트를 면밀히 지켜볼 계획입니다.

steering의 작동 원리

steering의 기본 아이디어는 모델의 내부 뇌 상태(internal brain state)에서 특정 개념(예: "간결하게 응답하라")을 추출한 다음, 추론(inference) 중에 해당 개념을 형성하는 수치적 활성화 값(numerical activations)을 증폭시키는 것입니다.

이를 수행하는 한 가지 방법은 모델에 동일한 100개의 프롬프트 세트를 두 번 입력하는 것입니다. 한 번은 일반적인 프롬프트로, 다른 한 번은 "respond tersely (간결하게 응답하라)"라는 문구를 추가하여 입력합니다. 그런 다음 각 프롬프트 쌍에 대해 모델의 활성화 값(activations) 차이를 측정합니다(하나의 활성화 행렬에서 다른 행렬을 뺌으로써). 이것이 바로 여러분의 "steering vector (조종 벡터)"가 됩니다. 이론적으로, 어떤 프롬프트에 대해서든 동일한 활성화 레이어(activation layer)에 이를 더함으로써 동일한 효과(모델이 간결하게 응답하는 효과)를 얻을 수 있습니다.

이보다 더 정교한 또 다른 방법은 모델의 활성화(activations)로부터 "특징(features)"(함께 나타나는 것으로 보이는 행동 패턴)을 추출하도록 두 번째 모델을 학습시키는 것입니다. 그런 다음 이러한 특징들을 개별 개념(concepts)으로 다시 매핑하려고 시도하고, 동일한 방식으로 이를 증폭시킬 수 있습니다. 이것은 Anthropic이 sparse autoencoders(희소 오토인코더)를 통해 수행하고 있는 것과 거의 유사합니다. 이는 단순한(naive) 접근 방식과 원리는 같지만, (시간, 연산량(compute), 전문 지식 측면에서 훨씬 더 많은 비용이 드는 대가로) 더 깊은 패턴을 포착할 수 있게 해줍니다.

Steering이 흥미로운 이유

Steering(조종)은 마치 치트키처럼 들립니다. 모델을 학습 데이터의 분포 중 "똑똑한" 쪽으로 밀어붙이려고 애써서 학습 세트(training set)를 구성하는 대신, 모델의 뇌 속에 있는 "똑똑함" 다이얼을 찾아내어 오른쪽 끝까지 돌려버리면 안 될까요?

또한 이는 모델이 말하는 방식을 조정하는 더 우아한 방법처럼 보입니다. 프롬프트(prompt)를 만지작거리는 대신(예: "당신은 반드시 ~해야 합니다"와 같은 수식어를 추가하거나 제거하는 것), "간결함/장황함(succinctness/verbosity)" 또는 "성실함/속도(conscientiousness/speed)"와 같은 슬라이더 제어판을 두고 이를 직접 움직일 수는 없을까요?

마지막으로, 이것은 그저 멋집니다. Golden Gate Claude가 모든 문장을 원치 않게 Golden Gate Bridge로 다시 끌어다 놓는 것을 지켜보는 것은 Oliver Sacks의 신경학적 일화만큼이나 매혹적이면서도 불안한 일입니다. 만약 당신의 마음이 이와 유사한 방식으로 조정된다면 어떨까요? 그것이 여전히 당신일까요?

Steering이 사용되지 않는 이유

그렇다면 왜 우리는 Steering을 더 많이 사용하지 않을까요? 왜 ChatGPT와 Claude Code에는 모델의 뇌를 실시간으로 조정할 수 있는 Steering 패널이 이미 존재하지 않을까요? 한 가지 이유는 Steering이 AI 연구 분야에서 불행히도 일종의 "중산층(middle class)" 아이디어이기 때문입니다.

대형 AI 연구소들에게 Steering은 격이 맞지 않는 일입니다. 그들은 추론 (inference) 중간에 어색한 뇌 수술을 할 필요 없이 모델을 직접 조작할 수 있기 때문입니다. Anthropic은 이 분야를 연구하고 있지만, (제가 알기로는) 주로 해석 가능성 (interpretability) 및 안전성 (safety) 관점에서 접근하고 있습니다. 그들이 모델이 특정 방식으로 행동하기를 원할 때, 그들은 Steering으로 씨름하는 대신 그냥 모델을 학습 (train) 시킵니다.

또한 Steering은 API를 통해 LLM을 사용하는 당신이나 저와 같은 일반적인 AI 사용자들에게는 손이 닿지 않는 영역이기도 합니다. 따라서 모델을 Steering 하는 데 필요한 모델 가중치 (weights)나 활성화 값 (activations)에 접근할 수 없습니다. 예를 들어, GPT-5.5에 대한 Steering 벡터 (steering vectors)를 식별하거나 노출할 수 있는 곳은 OpenAI뿐입니다. 우리는 오픈 웨이트 (open-weights) 모델에 대해서는 이를 수행할 수 있지만, 아주 최근까지도 (이에 대해서는 나중에 더 자세히 다루겠습니다) 이를 시도할 만큼 강력한 오픈 모델은 없었습니다.

게다가 Steering의 가장 기본적인 응용 방식들은 단순히 모델에게 프롬프팅 (prompting)을 하는 것에 비해 경쟁력이 떨어집니다. 모델의 뇌를 직접 조작할 수 있다는 것은 꽤 인상적으로 들립니다. 하지만 모델의 뇌를 직접 조작하는 또 다른 방법이 무엇인지 아십니까? 바로 프롬프트 토큰 (prompt tokens)입니다. Steering을 통해 활성화 값 (activations)에 대해 상당히 세밀한 제어를 할 수 있지만, 프롬프트의 언어를 미세하게 조정함으로써 이미 극도로 세밀한 제어를 할 수 있습니다. 다시 말해, 단순히 요청할 수 있는데도 모델이 더 장황하게 말하도록 Steering 하는 수고를 들일 이유는 별로 없다는 것입니다.

프롬프트로 불가능한 것을 Steering 하기

Steering이 정말 유용해질 수 있는 한 가지 방법은 프롬프트로 요청할 수 없는 개념을 식별할 수 있는 경우입니다. "지능 (intelligence)"은 어떨까요? 예전에는 지능을 프롬프트로 요청할 수 있었습니다. 4o 시대의 프롬프팅이 항상 "당신은 전문가입니다"로 시작했던 이유가 바로 이것입니다. 하지만 현재 세대의 모델들은 그것이 성격에 내재되어(baked into) 있기 때문에, 이를 프롬프트로 요청하는 것은 아무런 효과가 없습니다. 어쩌면 그것을 위해 Steering을 하는 것은 여전히 효과가 있을까요?

궁극적으로 이것은 경험적인 문제이지만, 저는 우리가 "지능 (intelligence)" Steering 벡터를 찾아낼 수 있을지에 대해 회의적입니다. 달리 말하면, "지능"만큼 어려운 개념을 구성하는 Steering 벡터는 모델의 전체 가중치(weights) 집합과 거의 공존(coextensive)할 수도 있으며, 따라서 이를 식별하는 것은 "똑똑한 모델을 학습시키는 것"이라는 문제로 귀결될 수 있습니다.

충분히 정교한 Steering 방식은 결국 실제 모델을 대체하는 결과로 이어집니다. 만약 제가 GPT-2를 가져와서 각 레이어(layer)마다 활성화 값(activations)을 동일한 아키텍처를 가진 훨씬 더 강력한 모델의 활성화 값으로 교체한다면, 훨씬 더 나은 결과를 얻을 것입니다. 하지만 그 시점에서 당신은 GPT-2를 더 똑똑하게 만드는 것이 아니라, 단지 더 강력한 모델과 대화하고 있는 것뿐입니다. 지능은 모델이 아니라 Steering에 있는 것입니다. 이에 대해 더 자세히 알고 싶다면, 저의 포스트 AI interpretability has the same problems as philosophy of mind를 참조하세요.

데이터 압축으로서의 Steering

Steering이 유용할 수 있는 또 다른 방법은, 표현하는 데 엄청난 양의 토큰(tokens)이 필요한 개념을 우리가 어떻게든 Steering 할 수 있는 경우입니다. 따라서 Steering은 모델의 컨텍스트 윈도우(context window)의 큰 부분을 절약해 줄 것입니다. 직관적으로, 우리는 이것을 개념을 모델의 작업 기억(working memory)에서 암묵적 기억(implicit memory)으로 이동시키는 방법으로 생각할 수 있습니다.

예를 들어, "나의 특정 코드베이스에 대한 지식"이라는 개념을 식별할 수 있다면 어떨까요? GPT-5.5가 나의 코드베이스를 속독할 때, 그 과정에서 얻은 지식의 일부는 활성화 값(activations) 속에 묻혀 있어야 하지 않을까요? 어쩌면 우리는 그것을 매우 큰 Steering 벡터로 끌어낼 수 있을지도 모릅니다.

이것이 작동할 수 있다면 놀라운 일이겠지만, 저는 이것이 작동하기 어려울 것이라고 생각합니다. 저는 우리가 "지능"을 추출할 때와 동일한 문제에 직면할 것이라고 생각합니다. "내 코드베이스를 안다"는 개념은 아마도 모델의 전체 파인튜닝 (fine-tune)을 요구할 만큼 충분히 정교할 것이기 때문입니다. 하지만 적어도 가능해 보이기는 합니다.

결론

저는 스티어링 (steering)에 매료되어 있지만, 그렇다고 특별히 낙관적인 것은 아닙니다. 대부분의 이점은 프롬프트 (prompt)를 통해 더 효율적으로 재현될 수 있으며, 진정으로 야심 찬 스티어링 목표는 모델을 훈련 (training)하거나 파인튜닝 (fine-tuning)함으로써 더 효율적으로 재현될 수 있다고 생각합니다.

하지만 오픈 소스 (open-source) 커뮤니티는 아직 스티어링에 관한 작업을 많이 수행하지 않았으며, 이제 막 변화가 시작되려는 참일지도 모릅니다. 만약 제 생각이 틀렸고 이것이 실질적인 응용 분야를 갖게 된다면, 우리는 향후 6개월 내에 그 사실을 알게 될 것입니다.

DwarfStar 4와 같이 모델별로 맞춤 제작된 도구들이 결국 강화 가능한 기능들의 "라이브러리 (library)"를 포함하게 될지 지켜보는 것도 흥미로울 것입니다. 인기 있는 오픈 웨이트 (open-weights) 모델이 출시되면, 커뮤니티는 항상 일련의 래퍼 (wrapper)와 양자화 (quantized) 버전을 출시하기 위해 달려듭니다. 모델로부터 강화 가능한 기능을 추출하려는 움직임 또한 급증하는 것을 볼 수 있을까요?

모델에는 측정할 수 있는 다양한 활성화 값 (activations)이 있습니다 (어텐션 (attention) 이후, 각 레이어 사이 등). 기본적으로 원하는 것을 무엇이든 선택하거나, 여러 개를 시도하여 무엇이 가장 잘 작동하는지 확인할 수 있습니다.

↩ -
저는 최근 오픈 LLaMA 모델을 사용하여 이를 수행하는 것에 대한 정말 훌륭한 심층 분석 (deep dive) 글을 읽었습니다 (그리고 저도 몇 달 전에 직접 시도해 보았으나 결과는 엇갈렸습니다).

↩ -
대형 AI 연구소에 계신 독자분들께 사과드립니다. 만약 내부적으로 능력을 향상시키기 위해 스티어링을 시도했으나 효과가 없었다면 저에게 이메일을 보내주세요. 아무에게도 말하지 않겠다고 약속합니다.

↩ -
그리고 설령 그렇다 하더라도, 업계에서 "코드베이스 (codebase)를 기반으로 모델을 파인튜닝하라"는 시도의 결과는 대체로 성공적이지 못했습니다.

↩

이 포스트가 마음에 드셨다면, 제 새로운 포스트에 대한 이메일 업데이트를 구독하거나 Hacker News에 공유하는 것을 고려해 보세요.

이 포스트와 태그를 공유하는 관련 포스트의 미리보기입니다.

LLM이 생성한 기술은, 사후에 생성한다면 작동합니다

LLM "기술 (skills)"은 특정 작업을 위한 짧은 설명 프롬프트이며, 일반적으로 보조 스크립트와 함께 묶여 있습니다. 최근 한 논문에 따르면 기술은 LLM에 유용하지만,

LLM이 작성한 기술(LLM-authored skills)은 그렇지 않습니다. 초록(Abstract)에 따르면: 스스로 생성한 기술은 평균적으로 아무런 이득을 주지 못하며, 이는 모델이 소비함으로써 이득을 얻는 절차적 지식(procedural knowledge)을 신뢰할 수 있는 방식으로 직접 작성할 수 없음을 보여줍니다.

당장은 이 논문을 깊게 파고들고 싶지는 않습니다. 다만 논문에서 기술을 생성하기 위해 LLM을 사용하는 방식이 잘못되었으며, 여러분은 이렇게 해서는 안 된다는 점을 언급하고 싶을 뿐입니다. 논문에서 LLM이 기술을 생성하도록 프롬프트(prompt)를 구성하는 방식은 다음과 같습니다:

계속 읽기...