Jev와 AI 에이전트를 위한 새로운 의사결정 레이어

System One 모델이 빠른 판단과 느린 추론을 분리할 수 있는 이유

많은 AI 에이전트가 거의 모든 의사결정에 언어 모델을 활용합니다. 언어 모델은 도구를 선택하고, 결과를 평가하며, 계속 진행해야 하는지를 판단하고, 최종적으로 답변을 생성합니다. 유연하지만, 이 과정은 대규모로 예/아니오 결정을 반복할 때 비용이 많이 들 수 있습니다. Unite.AI는 이전에 에이전시 워크플로가 모델 호출, 컨텍스트 및 재시도를 증가시키는 방식을 논의한 바 있습니다.. 추가적인 의사결정마다 사용자에게 유용한 정보를 제공하기 전에 시간과 비용이 추가될 수 있습니다.

Jev는 작업을 다르게 나누는 것을 제안합니다. 답변 집합이 정의된 제한된 판단을 위해 구축된 모델을 활용합니다. 개방형 추론과 언어를 위한 생성 모델을 활용합니다. Jev는 여기서 핵심 생각이 모든 에이전트가 새로운 제품을 하나 구매해야 한다는 것이 아니라는 점을 강조합니다. 핵심 개념은 에이전트가 모든 시점에 동일한 유형의 인텔리전스를 필요로 하지 않는다는 것입니다.

Jev가 실제로 하는 일

TypeSafe는 2026년 9월에 Jev를 출시했습니다, 새로운 System One 모델 중 첫 번째입니다. Jev는 문장을 직접 작성하지 않습니다. 대신, 상태(예: 지원 메시지와 사용자 데이터)를 전달합니다. 또한 미리 정의된 답변 유형을 가진 하나 이상의 질문을 보냅니다. 그러면 Jev는 유형화된 답변과 확률을 반환합니다.

에 따르면 회사의 공식 문서, 판단을 위해 세 가지 기본 요소가 있습니다:

• Choice 미리 정의된 옵션 중에서 선택할 수 있게 합니다.
• Score 순서가 지정된 루브릭에 따라 무언가를 평가할 수 있게 합니다.
• Noul 진술이 사실일 확률을 추정합니다.

하나의 요청 안에서 동일한 상태에 대해 여러 독립적인 질문을 할 수 있습니다.

예를 들어, 고객 서비스 문제를 처리하고 있다고 가정해 보겠습니다. 시스템은 어떤 팀이 이 사례를 담당해야 하는지를 파악하고자 할 수 있습니다. 또한 누가 얼마나 빨리 응답해야 하는지와 고객이 환불을 요청했는지 여부를 판단할 수도 있습니다.

채팅 모델이 세 가지 작업을 모두 수행할 수 있을지도 모릅니다. 하지만 결과를 구조화된 응답으로 앱에 반환해야 합니다. 반면 Jev는 제한된 판단만 제공합니다. 앱은 이러한 판단을 기반으로 다음에 취할 행동을 결정하게 됩니다.

아키텍처 변화가 모델보다 더 중요합니다

대부분의 논쟁은 대형 모델과 소형 모델을 비교합니다. Jev는 대안적인 경계를 제시합니다. 일부 단계는 언어 생성과 관련되고, 다른 단계는 소프트웨어가 활용할 수 있는 제한된 판단을 포함합니다.

이는 에이전트에 의사결정 레이어를 생성합니다. 모델은 추정값을 산출합니다. 소프트웨어는 정책을 적용합니다. 추정된 확률이 테스트된 임계값을 초과하고 행동이 저위험이며 되돌릴 수 있는 경우, 워크플로는 계속될 수 있습니다. 결과에 불확실성이 있거나 행동이 심각한 영향을 미칠 수 있는 경우, 시스템은 인간 감독을 요청할 수 있습니다. 추론 모델은 불확실성을 조사하는 데 도움이 될 수 있지만, 필수적인 인간 승인을 대체하지는 않습니다.

그림 1. 제한된 의사결정 경로는 임계값, 권한 및 에스컬레이션을 코드에 유지합니다.

모델 라우팅과 유사점이 있지만, 중요한 차이점이 있습니다. RouteLLM는 두 개의 언어 모델 중 어느 것을 선택할지에 대한 결정을 내립니다. 품질과 가격의 균형을 맞추기 위해 강력한 모델과 약한 모델 사이를 선택합니다. System One 모델은 코드가 직접 사용할 수 있는 제한된 판단을 생성합니다. 이러한 판단은 모델 라우팅뿐만 아니라 에이전트 내의 다른 의사결정을 지원할 수 있습니다.

에이전트 루프가 자연스럽게 적합한 이유

에이전트 루프의 특성은 매우 작은 수준에서 다수의 판단을 수행하는 데 특히 적합합니다. 이러한 판단은 최종 결과에 도달하는 데 도움을 줍니다. 다시 말해, 사용자가 질문이나 요청을 제출한 후 에이전트는 많은 “작은” 판단을 해야 합니다. 이러한 판단은 답변이나 출력이 반환되기 전에 이루어집니다.

예를 들어, 어떤 도구를 사용할지 결정하고, 검색된 레코드를 순위 매기며, 위험을 평가하는 것이 있습니다. 시스템은 또한 충분한 증거가 존재하는지와 프로세스를 계속 진행해야 하는지를 판단합니다. 이러한 과정은 대부분 반복적으로 발생할 가능성이 높습니다. 또한 각 루프 사이의 지연이 시간이 지남에 따라 누적될 수 있습니다.

이러한 에이전트 루프의 역할은 LangChain의 Jev 통합, 여기서 Jev는 모델 라우팅과 도구 호출 검사를 모두 수행할 수 있습니다. Jev가 생성 모델의 주변에 통합되는 동안, 생성 모델 자체는 계속해서 계획하고 콘텐츠를 생성합니다. 이는 Jev에 대한 훨씬 더 현실적인 사용 사례를 나타냅니다. 이는 범용 언어 모델을 대체하기보다는 보완합니다.

또한, 질문을 병렬화하면 팀이 작업을 분해하는 방식도 바뀝니다. 구체적으로, 팀은 하나의 모호한 지시를 여러 개의 개별 평가 질문으로 나눌 수 있습니다. 이는 모델 호출 순서를 크게 단축시킬 수 있습니다. 또한 평가가 훨씬 쉬운 워크플로우를 만들 수 있습니다. 그리고 개발자는 명시적인 비즈니스 로직을 사용해 결과 판단을 결합할 수 있습니다.

범용 언어 모델은 구조화된 출력을 생성할 수 있으며 경우에 따라 더 나은 선택이 될 수 있습니다. 예를 들어, 판단과 설명을 함께 제공해야 할 때가 있습니다. 따라서 Jev는 단순히 스키마 준수 이상을 입증해야 효과적인 것으로 간주됩니다.

Jev의 효과성은 전체 시스템 지연 시간을 감소시키는 데 달려 있습니다. 또한 유용한 확률 추정치를 제공하고 다양한 입력에 대해 성능 안정성을 유지하는 것이 필요합니다. Jev가 이러한 이점을 제공하지 못한다면, 다른 모델을 선택하는 것은 추가적인 개발 및 운영 부담만을 초래합니다.

Typed가 정확성을 의미합니까?

Jev에 대한 주장을 할 때 사용되는 언어도 신중하게 표현해야 합니다. 출력 공간이 사전에 정의되어 있기 때문에 모델이 만들어낸 필드나 파싱할 수 없는 단락을 반환해서는 안 됩니다. 이는 한 형태의 실패를 방지하지만, 의미 오류를 완전히 없애지는 못합니다. 시스템이 잘못된 부서를 반환하거나, 부정확한 위험 수준을 할당하거나, 과도한 확신을 표명하는 것을 막을 수 있는 방법은 없습니다. 그러나 이러한 모든 작업을 완전한 타입 안전성을 유지하면서 수행할 수 있습니다.

TypeSafe의 System One 문서은 중요한 구분을 제시합니다. 보정은 예측 그룹 전체에 대해 측정되며 개별 예측의 정확성을 보장하지는 않습니다. 실제 운영에서는 이러한 점이 영향을 미칩니다. 팀은 자체 데이터에서 예측 확률이 관측된 결과와 일치하는지 테스트해야 합니다.

성능 증거는 아직 초기 단계입니다

TypeSafe는 응답 시간이 70~500밀리초임을 보고합니다. 또한 내부 워크플로우 평가에서 상당한 비용 절감 및 속도 향상을 언급합니다. 추가로, TypeSafe는 이러한 헤드라인 수준의 향상이 실제 환경에서의 최고 수준에 가깝다고 지적합니다. TypeSafe의 공개적으로 이용 가능한 워크플로우 테스트는 실제 라벨 대신 다른 최첨단 모델이 제공하는 기준 확률을 사용합니다. 결과는 가설을 세우는 데 유용하지만, 실제 워크로드에 대한 독립적인 테스트를 대체할 수는 없습니다.

채택 전 실용적인 테스트

첫 번째 AI 기반 의사결정 워크플로우를 구축할 때는 가장 중요한 결정(예: 의료 승인이나 계정 정지)을 선택하지 마세요. 대신 매우 흔하고, 되돌릴 수 있으며, 팀 내 다른 사람이 쉽게 검토할 수 있는 작업을 선택하세요. 여기에는 티켓 라우팅, 문서 분류, 모델 선택, 저위험 품질 보증 등이 포함되지만 이에 국한되지 않습니다.

다음 네 가지 질문이 이 작업이 성공할지 판단하는 데 도움이 됩니다:

• 출력에 가능한 답변 수가 유한합니까?
• 판단 기준을 명확히 설명할 수 있습니까?
• 측정 가능한 결과가 있습니까? 예측, 그 확률, 행동 및 이후 결과를 추적하세요. 예측 확률과 실제 관측 결과를 비교하여 보정을 정기적으로 확인합니다.
• 자동화된 의사결정 프로세스가 실패할 경우를 대비한 대체 계획이 있습니까? 특정 시점에 추론 모델을 사용하거나, 추가 정보를 요청하거나, 인간을 개입시키는 방안을 정의하세요.

분석에는 전체 워크플로우와 의사결정 과정을 모두 포함해야 합니다. 의사결정 정확도, 보류 또는 에스컬레이션 비율, 전체 처리 시간, 성공적으로 완료된 작업당 비용, 실수의 영향을 측정하세요. 어려운 조건(단어 사용 변형, 관련 데이터 누락, 드문 카테고리, 적대적 입력)에서도 테스트를 수행하세요. 하위 비용을 초래하는 최적화된 분류기는 최적화가 아닙니다.

여기서 얻는 장기 교훈

Jev가 성공하거나 크게 변하거나 빠르게 대체되든, 한 가지는 변하지 않습니다. 바로 아키텍처적 질문입니다. 모든 기계 기반 의사결정을 생성된 언어로 표현해야 할 필요가 있습니까?

많은 경우에 답은 “아니오”입니다. 프로덕션 환경에서 생성 모델을 사용하는 시스템은 해석, 계획, 설명을 생성할 수 있습니다. 제한된 의사결정 모델을 사용하면 동일한 시스템이 라우팅, 점수 매기기, 게이트 역할을 수행할 수 있습니다. 코드는 허용 가능한 임계값과 권한을 계속 지정할 수 있습니다. 인간은 타인의 삶에 영향을 미치는 결정에 대한 책임을 유지해야 합니다.

이는 모든 작업을 신뢰할 수 있는 하나의 자율 모델이 수행하도록 하는 것보다 덜 극적인 관점이지만, 신뢰할 수 있는 시스템이 어떻게 구축되는지를 보여줍니다. 에이전트 성능의 다음 도약은 시스템 내에서 사고에 더 오래 걸리는 영역을 선택하는 데 달려 있을 수 있습니다. 다른 영역은 빠른 결정을 필요로 하고, 일부는 전혀 행동이 필요하지 않을 수도 있습니다.