Jev에게 '다음 글자'만 물어 챗봇으로 만든 실험, jevchat 공개

jevchat은 Jev를 채팅 모델처럼 굴리는 실험용 오픈소스 도구다. 문장을 한 번에 생성하는 대신, 매 단계마다 Jev에게 "지금까지의 사용자 질문과 작성된 답변을 볼 때 다음에 올 기호는 무엇인가"를 묻는다. 후보군에는 알파벳 기호들과 함께 '생성 중단' 옵션이 들어가고, Jev가 각 후보에 매긴 확률을 정규화한 분포에서 샘플러가 다음 기호를 뽑아 답변 끝에 붙인다. 이 과정을 STOP이 뽑힐 때까지 반복하는 것이 전부다.

저장소는 kyle-pena-nlp/jevchat이며, 만든 사람은 이 프로젝트를 재미를 위한 것이라고 설명한다. 비용은 다소 비현실적이고 결과물은 상당히 웃기다는 것이 저자의 평가다. Claude를 활용한 가속 실험이기도 해서, 저자가 샘플링 알고리즘과 전략을 설명하면 Claude가 이를 구현하는 방식으로 진행됐다.

바꿔 끼울 수 있는 축은 두 가지다. 다음 기호에 대한 분포를 어떻게 얻을지 정하는 전략(-s/--strategy)과, 그 분포가 무엇을 대상으로 할지 정하는 알파벳(-a/--alphabet)이다. 기본값인 choice는 전체 알파벳을 놓고 한 번에 질문한다. bisect는 알파벳을 정렬한 뒤 앞/뒤를 가르는 예·아니오 질문으로 그룹이 작아질 때까지 좁혀가고, 각 분할을 양방향으로 묻는다. buckets은 알파벳을 여러 질문으로 쪼개고 각 질문에 OTHER 탈출구를 두는데, 255개를 넘는 심볼을 다룰 수 있는 유일한 전략이다. refine은 buckets에 이어 승자들만 대상으로 한 질문과 재점수화된 nucleus를 덧붙이며, 정답 기호에 실리는 확률을 두 배로, 해석 가능한 어휘량을 약 19배로 늘린다고 설명한다.

후보를 제시하는 방식도 두 갈래다. symbol 프레젠테이션은 'a', 'i', ' the'처럼 기호 자체를 후보로 주고, Jev가 머릿속에서 답변에 이어 붙인 결과를 상상해 판단해야 한다. hypothesis는 '...the capital of France is Para'처럼 이어 붙인 완성 문자열을 후보로 준다. 이어 붙이기가 이미 끝난 상태라 Jev는 완성된 문자열만 순위 매기면 되고, 저자는 이를 프로젝트에서 가장 큰 개선이라고 꼽는다. 문자 알파벳 기준으로 top-1이 약 3배, 정답 기호에 떨어지는 확률 질량이 2배가 되면서도 입력 토큰은 symbol 방식보다 적다.

빔 탐색도 지원한다. -b 3처럼 후보 답변 여러 개를 동시에 살려두고 진행할 수 있는데, 살아 있는 빔마다 단계당 한 번의 점수 호출 비용이 든다. 빔 폭이 1을 넘으면 temperature, top_p, top_k는 더 이상 적용되지 않고 빔은 확률로만 순위가 매겨진다.

실행은 poetry run jevchat으로 대화형 챗을 열거나, ask, alphabets, bench 서브커맨드를 쓰는 식이다. API 키는 pyproject.toml 옆의 .env에 넣으며 JEV_API_KEY와 TYPESAFE_API_KEY를 모두 받는다. .env에 적힌 값이 환경변수로 내보낸 값보다 우선하므로 파일만 고치면 키를 바꿀 수 있다. 답변은 생성되는 즉시 패널에 나타나고, 초당 심볼 수와 초당 문자 수, API 호출당 밀리초, 경과 시간, 마지막 단계에서 Jev가 높게 평가한 상위 기호들이 함께 표시돼 샘플러가 어떤 분포에서 뽑고 있는지 눈으로 확인할 수 있다.

중단 동작도 세심하다. Ctrl-C를 한 번 누르면 진행 중이던 요청이 돌아온 시점에 생성을 멈추고 부분 답변을 남기며, 두 번째 누르면 즉시 중단한다. 대화형 모드에서는 이 부분 답변이 대화 기록에 그대로 남고, ask는 취소 시 종료 코드 130으로 끝난다. /help, /alphabet, /temp, /stop-bias 같은 채팅 명령도 제공된다.

배경에는 순수한 호기심이 있다. Jev가 선택지의 위치에 따라 판단이 흔들리는 편향을 상쇄하려고 후보 순서를 섞는 옵션을 두고, 섞은 순서 여러 개를 한 요청에 병렬로 보내 평균을 내는 ensemble 모드까지 넣었다. 순서 섞기를 끄면 최악의 모드가 된다는 설명도 붙어 있다.

개발자 입장에서 눈여겨볼 지점은 테스트 구조다. 158개의 테스트가 전부 오프라인으로 돌아가며, 생성 루프에는 스크립트로 짠 가짜 클라이언트를, HTTP 계층에는 httpx.MockTransport를 쓴다. API 키도 네트워크도 필요 없고, 실제 API를 때리는 것은 bench 서브커맨드뿐이다. 외부 모델 API에 의존하는 생성 파이프라인을 어떻게 격리해서 검증할지에 대한 참고 사례가 된다.

한계는 저자 스스로 인정한다. 애초에 재미를 위한 실험이라 비용 효율이 좋지 않고, 결과물의 품질을 기대할 물건도 아니다. 알파벳이 255개를 넘으면 buckets 전략을 써야 하고, 빔 폭을 1보다 크게 두는 순간 샘플링 파라미터가 무력화된다는 점도 설계상의 제약이다.