Multi-Head Latent Control: LLM 에이전트가 답변, 도구 호출, 상위 모델 전환을 스스로 판단하게 하는 방법
도입
대규모 언어 모델이 에이전트로 배포되면서, 문제는 단순한 다음 토큰 예측을 넘어섰다. 실제 서비스에서는 현재 모델이 이 요청을 해결할 수 있는지, 더 강한 모델로 넘겨야 하는지, 사용자에게 추가 정보를 요청해야 하는지, 외부 도구를 호출해야 하는지, 혹은 답변을 삼가야 하는지를 판단해야 한다. 논문 Multi-Head Latent Control은 이러한 결정을 모델 생성 과정의 은닉 상태에서 직접 읽어내는 접근을 제안한다.
핵심 내용
- 입력 기반 라우팅을 넘어 latent 상태 활용: 기존 방식은 프롬프트 수준 라우팅, 외부 오케스트레이션, 작업별 미세조정에 의존하는 경우가 많다. 이런 방식은 주로 입력 신호를 사용하며, 모델 백본이 바뀌면 유지보수 비용이 커진다. 이 논문은 고정된 LLM 또는 VLM의 hidden-state trajectory에 제어 결정에 필요한 정보가 담겨 있는지 탐구한다.
- 두 개의 헤드로 역할 분리: Capability Head는 현재 모델이 해당 인스턴스를 풀 수 있는지, 아니면 더 강한 협력 모델에 넘겨야 하는지를 예측한다. Resolution Head는 명확화 요청, 도구 사용, 기권, 직접 답변 중 어떤 처리 방식이 적절한지를 예측한다.
- 기본 모델은 수정하지 않음: 두 헤드는 동일한 고정 LLM 백본에서 나온 latent trace만으로 학습된다. 따라서 전체 모델을 다시 훈련하는 방식이 아니라, 배포 후 덧붙일 수 있는 가벼운 제어 계층에 가깝다.
- 부분 생성에서 조기 handoff 가능: 생성이 끝나기 전에 실패 가능성을 감지하면, 작은 모델이 불필요하게 토큰을 소비하기 전에 큰 모델로 넘길 수 있다.
- 보고된 성능과 비용 효과: 작은 모델과 큰 모델을 함께 쓰는 라우팅 실행에서, 논문은 AndroidWorld에서 큰 모델 사용량을 최대 90.7% 줄이고, 여러 벤치마크 평균으로 27%–53% 줄이면서 큰 모델 성능의 대부분을 유지했다고 보고한다. 도구 사용 판단에서도 최대 +158%의 상대 점수 향상과 65.5% 적은 필수 도구 호출 누락이 보고됐다.
의미와 영향
이 연구의 의미는 에이전트 제어를 순수한 외부 규칙 문제가 아니라, 모델 내부 생성 동역학에서 나온 신호로 다룬다는 점에 있다. 작은 모델이 자신의 한계를 더 빨리 감지할 수 있다면, 비싼 큰 모델 호출을 어려운 사례에 집중할 수 있다. 또한 도구가 필요한 상황을 더 정확히 감지하면, 근거 없는 직접 답변을 줄이는 데도 도움이 될 수 있다.
다만 실제 도입에는 검증해야 할 부분이 남아 있다. 서로 다른 모델 계열에서도 제어 헤드가 안정적으로 작동하는지, latent trace를 어떻게 수집하고 라벨링할지, 잘못된 라우팅의 위험을 어떻게 평가할지가 중요하다. 특히 기권, 도구 호출, 모델 전환은 사용자 경험과 안전성에 직접 연결되므로 평균 성능만으로 판단하기 어렵다.
그럼에도 Multi-Head Latent Control은 LLM 에이전트가 답변뿐 아니라 “다음에 무엇을 해야 하는가”에 대한 신호를 함께 내도록 만드는 흥미로운 인터페이스를 제시한다.
댓글
로그인 상태 확인 중…
댓글 불러오는 중…