텍스트를 쓰지 않고 고르기만 하는 모델, Strands Decider 2B가 에이전트에서 맡는 역할

TL;DR

• Strands Decider 2B는 글을 생성하지 못하는 20억 파라미터의 결정 모델이다. 주어진 선택지 중 하나를 고르거나 점수를 매기고, 각 판단에 신뢰도 값을 붙인다. 코딩이나 요약, 챗봇에는 쓸 수 없다.
• 구조는 Qwen3.5-2B의 언어 생성 헤드를 떼고 선택지를 채점하는 포인터 헤드로 바꾼 것이다. 헤드의 규모는 100만 파라미터 남짓이며 몸통은 rank 16 LoRA로 미세조정했다. 공개 버전은 19번째 반복이다.
• 성능은 JevBench 공개 세트에서 2B급 33개 중 3위이고, 2B를 살짝 넘는 모델을 뺀 30개 중에서는 1위다. 로컬 판단 지연은 RTX 3090에서 중앙값 약 115ms, M3 맥북에서 작은 작업 기준 약 153ms다.
• 활용 예로는 모델 라우팅과 도구 선택, 평가, 가드레일, 정책 분류, LLM과 섞은 하이브리드 에이전트가 거론된다. 도구 호출 직전에 인자가 사용자 발언에 근거하는지 확인해 성급한 호출을 막는 예제도 있다.
• 이 예제의 질문과 임계값은 손으로 고른 시연이며 권고가 아니다. 글의 성능 수치는 자사 측정이라는 점도 함께 읽어야 한다.

생성하지 않는 대신 빠르고 항상 답하는 모델

Strands 팀은 TypeSafe AI의 Jev 출시 이후 주목받는 결정 모델, 또는 시스템 1 모델이라는 새 분류에 Decider를 올려놓는다. 이 모델은 임의의 글을 쓰지 않는다. 문자열이 커피머신에 관한 것인지 예 또는 아니오로 답하고 문구의 언어를 영어와 줄루어, 네덜란드어 중에서 고르며 리뷰 문장이 얼마나 긍정적인지 0에서 1 사이 점수로 매긴다.

이 제약은 교환 조건이다. 유연성을 포기한 대가로 같은 크기에서 더 빠르고 더 유능해지며 주어진 선택지 안에서 반드시 답을 내고 아주 낮은 지연으로 돌릴 수 있다. 반대로 모든 출력을 한 번의 병렬 패스로 만들기 때문에 복잡한 문제는 추론 모델보다 훨씬 못 푼다. 글도 코딩, 챗봇, 문서 요약처럼 흔한 LLM 작업에는 맞지 않는다고 분명히 선을 긋는다.

여기에 결정 모델만의 성질이 둘 더 있다. 하나는 모든 판단에 “이 예, 아니오를 얼마나 믿어도 되는가”에 해당하는 신뢰도 점수가 붙는다는 점이다. 글은 이것이 프런티어 LLM 추론 API에서는 얻을 수 없는 값이라고 말한다. 다른 하나는 같은 입력에 대해 여러 질문을 묻는 비용이 낮다는 점이다. 저자들은 이 조합이 Strands 하니스 SDK로 만드는 에이전트 워크플로에 잘 맞는다고 본다.

LLM 몸통에 포인터 헤드를 붙인 구조

구조의 핵심은 사전학습된 LLM의 몸통을 가져오되 언어 생성 헤드를 제거하는 것이다. 몸통은 Qwen3.5-2B이고 생성 헤드 자리에는 선택지를 채점하는 포인터 헤드가 들어간다. 이 헤드는 각 선택지 위치의 은닉 상태를 <answer> 위치의 은닉 상태와 비교해 점수를 낸다. 포인터 헤드의 규모는 100만 파라미터를 겨우 넘는다. 몸통은 rank 16 LoRA 어댑터로 미세조정했다.

이 아키텍처는 두 번째 주요 버전이다. 첫 버전은 슬롯 헤드를 썼는데 성능이 눈에 띄게 나빴다고 한다. 지금 공개한 모델은 내부 반복을 거친 v19이고 버전마다 무엇을 바꿨는지가 저장소에 기록돼 있다. 저자들은 학습 데이터와 스크립트까지 모두 공개해 시행착오를 따라갈 수 있게 했다고 강조한다.

정확도, 보정, 지연으로 보는 성능

성능 목표는 정확도와 보정, 지연 세 가지다. 정확도는 JevBench 공개 세트로 재고 보정은 같은 세트에서 Brier 점수로 잰다. 결과는 2B급 33개 모델 중 3위이고 2B를 간신히 넘는 모델을 제외한 30개 중 1위다. 이 순위는 저자들이 “우리가 아는 범위”에서 비교한 값이며 독립 검증이 아니다. 글의 그림은 아키텍처가 바뀔 때마다 두 지표가 개선된 궤적을 보여 준다.

지연은 넓게 쓰이는 하드웨어에서 중앙값 약 115ms다. 작업 크기에 따라 거의 선형으로 늘어난다. 이 그래프는 로컬 RTX 3090에서 모델 v18로 잰 것이고 M3 맥북에서는 작은 작업 중앙값이 약 153ms로 크게 뒤지지 않는다. 지연의 바닥값을 낮출 여지가 많다고 하지만 아직 이루지 못한 목표다.

저장소 README는 신뢰도 점수의 쓰임새를 더 구체적으로 밝힌다. 본 적 없는 짧은 분류 과제에서 신뢰도 0.9 이상의 답은 약 95%가 맞았고 그 아래에서는 확인하거나 사람에게 물으라고 권한다. 이 수치는 특정 평가 결과의 요약이므로 자기 업무에서 같은 비율이 나온다는 보증은 아니다. 신뢰도를 행동 기준으로 삼으려면 결국 자신의 데이터로 보정 상태를 확인해야 한다.

왜 2B이고 어디에 쓰는가

2B를 고른 이유는 두 가지다. 가진 하드웨어에서 돌리고 직접 학습까지 해 볼 수 있어서 실험하기 쉽고 위험이 낮다. 또 20억 파라미터는 의미 있는 일을 하기에 충분하면서 실험하기에 작은 적정선으로 보인다는 것이다. 근거로 JevBench의 쉬운 과제는 100% 정확히 푼다고 하며 이런 수준의 문제가 에이전트 개발자가 다루는 쉬운 문제와 잘 겹친다고 본다.

초기에 성공을 본 용도는 모델 라우팅, 도구 선택, 평가, 가드레일, 메모리, 컨텍스트 관리, 정책 분류다. 가장 어려운 결정은 LLM이 맡고 쉽고 반복적인 결정은 결정 모델이 맡는 하이브리드 에이전트도 시도되고 있다. 이렇게 나누면 비용과 지연이 줄어든다. 고정된 워크플로 언어와 결합한 하이브리드 워크플로, 게임과 미로 탐색 같은 실험도 언급된다. 이 목록은 저자들이 본 초기 사례이며 효과를 수치로 입증한 것은 아니다.

도구 호출 직전에 끼워 넣는 검증

설치는 pip install strands-decider로 하고 CLI의 ask 명령에 상태와 질문을 넘긴다. 예시에서 “결제 지급이 3일째 실패한다”는 문의에 담당 팀을 billing, sales, retail 중에서 고르게 하면 billing이 0.845로 가장 높고 전체 신뢰도는 0.768로 표시된다. 선택지 외에도 예 또는 아니오로 묻는 noul 질문과 척도형 점수 질문이 있고 여러 질문을 한 번에 묻는 편이 입력 상태를 한 번만 읽어 효율적이다.

Strands 에이전트 예제는 이 모델이 쓰이는 방식을 가장 잘 보여 준다. 날씨 도구가 있고 시스템 프롬프트가 일부러 성급하게 짜인 에이전트가 있다. 사용자가 장소 없이 날씨를 물으면 에이전트가 임의의 도시를 골라 도구를 호출한다. 호출이 실행되기 전에 Decider가 대화와 제안된 호출을 읽고 두 질문에 답한다. 인자 값이 사용자가 실제로 말한 사실에 근거하는가, 그리고 사용자에게 먼저 확인하기 전에 호출하는 것은 이른가.

Strands의 개입 시스템에서는 InterventionHandler의 before_tool_call 메서드가 도구 실행 전에 돌고 결과로 진행, 거부, 확인, 안내 가운데 하나의 동작을 돌려준다. 확인은 사람에게 묻는 것이고 안내는 호출을 막는 대신 피드백과 함께 모델에게 차례를 돌려준다. 결정 모델의 예측 몇 줄을 이 동작으로 바꾸면 에이전트는 엉뚱한 도시의 날씨를 보고하는 대신 어느 도시인지 되묻는다. 같은 구조에 Cedar 정책이나 다른 에이전트를 넣어도 동작한다.

저자들은 이 예제를 권고가 아닌 예시로 선을 긋는다. 질문도 임계값도 정책도 모두 손으로 골랐다. 핵심은 이만큼 싼 판단이라면 LLM 호출로는 넣을 수 없던 경로에도 끼울 수 있다는 점이다. Strands 팀은 결정 모델 통합 라이브러리를 준비 중이며 저장소 업데이트를 지켜보라고 안내한다.

참고 자료

Strands Agents Blog — Introducing Strands Decider 2B: a small, open source, decision model

strands-labs/strands-decider (GitHub) — README에서 사용법과 신뢰도 0.9 기준 설명을 대조했다. 평가 결과 문서와 학습 스크립트는 열어 보지 않았다.