JEV는 거의 끝났다: CLM vs JEV

기술적인 사람들 입장에서는 우리한테는 간단한 개념을 가지고 제품화해서 돈을 엄청나게 벌어들이는 기획자들을 보면 좀 꼴보기 싫은 면이 있지.

우리 다들 어떤 식으로든 분류기(classifier)를 써봤지만, Jev가 나오기 전까지는 아무도 이걸 제대로 된 제품으로 만들 생각을 안 했거든. 솔직히 걔네가 일을 잘하긴 했어.

진짜 흥미로운 통찰이네, 시간 내서 답글 달아줘서 고맙다. 덕분에 생각할 거리가 생겼어. 나도 그런 사람이 안 되려고 노력은 하는데, 살다 보면 남들은 가진 걸 내가 못 가졌다는 사실을 무시하기 힘든 상황이 꼭 오더라고.

동의함. 그리고 신뢰도 점수가 Jev의 핵심임. 그게 자동화를 가능하게 만드는 요소니까.

나는 Jev 같은 분류기가 에이전트형 LLM이 사용하는 빌드나 네트워크 작업 같은 백그라운드 프로세스를 관리하는 데 쓰이는 것에 특히 관심이 많아. 백그라운드 프로세스에 더 많은 시간이나 반복 횟수를 할당할지, 아니면 제어권을 감독 LLM으로 넘길지 결정할 수 있다면 토큰을 엄청나게 아낄 수 있거든. 특히 반복 작업 사이에 KV 캐시 TTL이 계속 만료되어서 상태 확인 때마다 입력 토큰이 캐시에서 밀려나는 장기 실행 작업이나, LLM 속도가 느린 엣지 디바이스에서는 더더욱 그렇지...

나는 시스템 로그에 조치할 만한 중요한 내용이 있는지 확인하려고 LLM을 돌리는데, Jev 같은 분류기가 그런 역할을 맡아서 심각한 시스템 문제가 터지기 전에 미리 대응할 수 있게 해주면 딱 좋을 것 같아.

Jev의 초능력이 제로샷으로 넓은 지식을 갖는 거라는 생각 자체가 거꾸로 된 거야. 그 본질 자체가 파인튜닝을 갈구하고 있거든. 항상 옵션이랑 지시사항을 제대로 엔지니어링해서 성공할 수 있게 판을 깔아줘야 하잖아. 만약 그 정도를 할 수 있는 능력이 있다면, 차라리 작은 모델을 파인튜닝해서 더 잘 돌아가게 만드는 게 낫지. 나는 Qwen한테 체스 두라고 했다가 다음 프롬프트에서 플래피 버드 만들라고 시킬 수 있어. Jev로는 절대 못 할 짓이지. 이렇게 제약된 출력값을 가진 제로샷 광범위 지식은 안티패턴이야. 진짜 현실적인 문제를 해결하려는 사람이 왜 BERT나 다른 수십 가지 대안을 놔두고 굳이 Jev를 쓰려는지 도무지 이해가 안 가네.

왜냐하면 어떤 문제든 즉석에서 작동하기 때문임. 상태(state)에 배경 컨텍스트 + 관련 검색 데이터와 함께 완전히 임의의 데이터를 넣기만 하면 그냥 작동함.

상태 내 32k 공유 컨텍스트 + 질문당 32k 격리 컨텍스트.

이건 BERT 스타일 분류랑은 비교조차 안 됨. 이걸로 엄청나게 어려운 문제들도 해결할 수 있음.

왜 파인튜닝 안 함?

그냥 작동하는 모델이 가진 시스템 설계상의 의미 때문임.

알 수 없는 케이스를 처리하거나 데이터 파이프라인을 다시 작성할 때마다 파인튜닝 과정을 거쳐야 한다면 아이디어 반복에 큰 걸림돌이 됨.

앞으로 몇 달 안에 경쟁력 있는 오픈 소스 대안들이 나오길 기대하지만, 지금 이런 식으로 급조된 모델들은 비교 대상이 아님.