JEV(또는 유사 도구)가 하네스(harness) 환경에서 실제로 유용한가요?

게이트는 모델의 추론을 대체하는 게 아니라 보호하는 것임. 모델은 여전히 행동을 고민하고, 게이트는 실행 여부에 대해 '예', '아니오', '결정 불가'만 말할 뿐임. '결정 불가' 판정은 모델 혼자서는 줄 수 없는 안전장치임. 우리는 매일 되돌릴 수 없는 모든 작업에 이걸 돌리고 있고, 추론 체인은 그대로 유지됨.

핵심은 효율성 트레이드오프지, 무슨 비밀스러운 성능 향상 비법이 아님. 입력 데이터는 많은데 결정은 단순하다면 훨씬 비용 효율적으로 쓰라는 의도임.

자동 도구 분류기로 쓸 수 있는데, 이미 다른 LLM을 사용하는 경우임. 결과를 다시 LLM으로 돌려보내서 뭘 선택했는지 알게 할 수도 있음. 압축 과정에 쓰는 사람도 있는데, 개인적으로는 제한적으로 쓸 것 같음. 적절한 서브 에이전트를 선택하는 데도 쓸 수 있고. 결국 뭘 하느냐에 따라 다름.

지금까지 사람들이 효율성을 높이려고 시도하는 것들을 보면 스킬 선택/로드나 동적 모델 라우팅 같은 것들이 있음. 간단한 테스트에서는 브라우저 탐색에서 꽤 좋은 결과를 보여줌. 실제로는 탐색 흐름의 일부로 쓰는 게 더 낫다는 걸 알게 됐음. 분류기가 초기 탐색을 수행하고 확신이 낮을 때 다른 모델이 이어받는 식임. 다른 사람 말대로 마법은 아님. 제대로 쓰면 속도 향상과 토큰 비용 절감 효과를 얻을 수 있음.

매우 구체적이고 통제된 환경에서는 엄청난 효과를 낼 수 있음.

아니. JeV/Laya를 써서 특정 답변이 맞을 확률을 LLM에게 주는 거임. LLM에서 원하는 최종 결과가 아닐 가능성이 높음. 이건 모델에게 '느낌'이 아니라 경험적인 정보를 주는 것임.

Jev를 도입하거나 깊게 생각해 본 적은 없지만, 몇 가지 유용한 사례가 있을 것 같긴 함.

예를 들어 일반적인 에이전트가 이메일이나 중요/흥미/긴급 업데이트 같은 걸 주기적으로 확인한다고 치자.

그럼 Jev한테 먼저 확인하게 해서 예/아니오로만 답하게 하는 거지. 아니오면(대부분의 경우) 아무것도 안 하고, 예면 일반 에이전트가 정상적으로 확인하게 하는 거야.

이건 더 넓은 적용 사례를 시사하는데, Jev를 정찰병처럼 써서 "에이전트가 이 방향을 더 탐색할지 아니면 넘어갈지"를 먼저 확인하게 하는 거지.

긴 문서 목록에서 질문에 대한 답을 찾는다고 해보자. Jev를 먼저 보내서 각 문서마다 예/아니오로 답하게 하고, 에이전트는 '예'라고 한 문서만 탐색하게 하는 거야. 그런 식이지. 에이전트가 '아니오'인 문서에 대해 더 알 필요는 없으니까.

분리하는 건 맞다고 생각하고, 네가 말한 문제는 결정이 다시 전달되는 방식에서 오는 것 같아.

모델은 여전히 뭘 시도할지 결정해야 해. 결정론적 레이어는 그 시도가 허용되는지(권한, 제한, 필수 단계 등)를 결정하는 거고. 모델이 굳이 추론할 필요가 없는 것들이 바로 이런 거고, 그게 바로 밖으로 빼내는 이유지.

문제가 되는 건 레이어가 조용히 차단하거나 재작성할 때야. 모델은 이유도 모른 채 실패를 겪고, 다시 시도하거나 즉흥적으로 행동하게 되지. 만약 모든 판결이 이유(차단됨, 한도 초과 환불, 승인 필요 등)와 함께 툴 결과로 돌아온다면, 모델은 맥락을 유지하면서 그에 맞춰 계획을 세울 수 있어.

추적을 위해서는 모델의 의도와 레이어의 판결을 나란히 기록해 둬. 그게 바로 네가 말한 '왜'에 대한 체인인데, 그냥 두 군데로 나뉘어 있을 뿐이지.

2주 동안 오버엔지니어링 체크용으로 Jev를 써봤는데(Sol-5.6에서 6.1 버전 안녕!) 그냥 지워버렸어. 그 용도로는 별로임.