Jev-ish 발화 게이팅을 이용한 실시간 기록(Scribing)

모두와 마찬가지로, 저는 Jev에 관한 논의를 흥미롭게 지켜봐 왔습니다. 아이디어의 독창성에 대한 논쟁은 접어두고, 이 모든 것이 공개되었을 때 제가 가장 먼저 생각한 것은 '맙소사, 이것이 제 로컬 기록 장치(scribe)가 상담 중에 실시간 루프를 실행하는 데 정말 도움이 될 수 있겠구나'였습니다. 저는 선택한 하드웨어 구성으로 이 문제에 접근했습니다 (AI 코딩으로 인한 뇌 부패가 계속되면서 LLM에 점점 더 의존하고 있습니다). 결과적인 워크플로우는 다음과 같습니다: TEN-VAD를 사용하여 발화를 세그먼트화하고 Whisper와 호환되는 백엔드로 전송합니다 (Tauri 빌드는 parakeet.cpp와 0.6B 의료 파인튜닝을 사용합니다). CAM++ 스피커 임베딩을 사용하여 최선의 노력으로 화자 분리(diarization)를 제공합니다 (물론 형편없는 데스크톱 마이크와 에코가 심한 상담실 환경에서는 제한적입니다). 여기서 Jev-ish/SemIf 게이팅이 들어옵니다. 각 발화는 짧은 프롬프트와 함께 LLM에 제공되며, NOTE(문서화할 내용), ACT(취해야 할 조치), SKIP(필러 토크 등)으로 분류하라는 지침을 받습니다. Docker 배포 환경에서는 사용자 설정 가능한 보조 모델이 이 작업을 수행합니다 (저는 Qwen3.5 4B를 사용합니다). Tauri 빌드에서는 단일 주 모델이지만, 번들된 llama.cpp 서버의 두 번째 슬롯으로 들어갑니다 (실행 중인 메인 스레드의 프롬프트 캐시를 손상시키지 않도록 중요합니다). 초기 접근 방식은 상당히 간단했습니다: 하나의 디코딩 단계; 그런 다음 첫 토큰의 상위 로그 확률을 수집하고 SKIP/NOTE/ACT에 걸쳐 계산된 확률 질량을 구합니다 (토크나이저 분할을 고려하기 위한 일부 접두사 일치와 단어 하나 생성 폴백(fallback)을 사용). SKIP 발화는 버퍼링되어 즉시 메인 LLM으로 전송되지 않습니다 (메인 모델이 다음번에 깨어나면 이 자료를 흡수하여 아무것도 손실되지 않도록 합니다). NOTE나 ACT가 SKIP로 오분류되면, 45초/40단어의 디바운스(debounce)가 모든 놓쳤을 수 있는 자료와 함께 메인 LLM을 통과합니다. NOTE와 ACT는 처리 목적으로 메인 모델에 전달됩니다. 메인 모델은 실행 중인 노트 수정 기능을 포함하는 도구들에 접근할 수 있습니다.

프롬프트 캐싱(Prompt caching)은 필수적입니다. 그래야 메인 모델을 통과하는 후속 패스들이 큰 PP 지연 없이도 성능을 유지할 수 있기 때문입니다. 저는 4B 모델이 거의 SKIP하지 않는다는 것을 발견했습니다 (Jev와 3.8-Flash가 더 좋았지만, 자연어 발화의 4분의 3을 놓치긴 했습니다). 놀랍지 않게도(사후적으로는); 계산된 확률 질량만 사용하는 것은 기본 생성 엔드포인트에 프롬프트를 전달하고 출력에 따라 실행하는 것과 본질적으로 다르지 않았습니다 (약 81%의 정확도). 로그확률(logprobs)을 좀 더 살펴보니 어딘가 쓸만한 신호가 있는 것 같았습니다. GLM-5.3은 이를 알아내는 데 상당히 뛰어났습니다: NOTE가 선택되고, P(SKIP) ≥ 0.05이며, 발화가 ≤8 단어인 경우라면 본질적으로 항상 SKIP이었습니다. 이 휴리스틱을 사용하자... 여러 번의 실행에서 오탐지된 SKIP이 없었으며, 자연스러운 상담 상황에서의 SKIP 재현율(recall)이 0-50%에서 75-100%로 향상되었습니다. 로그확률 게이팅(logprob gating) + 휴리스틱 단계는 지연 시간 중립적이지만, 이 작업에는 더 신뢰성이 높았습니다. 그렇지 않았다면 Qwen3.5-4B 같은 일반적인 소형 LLM은 SKIP을 플래그 지정하지 않았고 때로는 지침을 완전히 따르지 않았습니다. 또한 OpenRouter를 통해 Jev로 평가를 진행했습니다 (약 40개의 수동 레이블링된 발화로 이루어진 상당히 비공식적인 테스트 세트였으며, 휴리스틱은 같은 세트로 조정되었으므로 확인하려면 별도의 홀드아웃 세트가 필요합니다); 자연스러운 주변 상담 녹음에서 격차는 예상했던 것보다 작았습니다 (둘 다 95%의 정확도이지만 각각 73ms 대 514ms였으며, Jev가 원격 엔드포인트이고 수반되는 모든 지연 시간을 고려해야 합니다). Jev는 명령어가 많은 합성 스크립트(~80% 대 100%)에서 우위를 점했습니다. 전반적인 의도는 메인 루프가 사소한 내용에 너무 매몰되지 않도록 방지하는 것이었고, 이 접근 방식이 그것을 달성한다고 생각합니다. 첫 토큰 로그확률 분류는 상당히 오래된 기법이지만; Jev를 사용하기 전까지 저는 스크라이브에서 원샷(one-shot) 분류에 대해 진지하게 생각해 본 적이 없습니다.

그리고 네, Jev의 핵심은 분류 작업을 주면 별도의 휴리스틱(heuristic)을 logprobs에 적용하여 분류기를 복구할 필요가 없을 정도로 성능이 좋다는 것입니다 (하지만 재미있게도 Jev조차 P(SKIP) 휴리스틱으로부터 정확도 향상을 얻었습니다). 어쨌든 재미있는 실험이었고 (그리고 일반적인 Jev의 의미 있는 내용을 말하기에는 너무 성능이 낮았습니다)! 이 결과물(아래 비디오)은 제 관점에서는 유용했습니다 (여기에 직접 시도해 볼 수 있습니다 ). 합성 상담 예시입니다. 실제 운영 환경에서는 성능이 이 정도가 아닙니다 (화자 중첩; 마이크/음향 문제 등). 주 모델: Qwen3.8-Flash-Next; 보조 모델: Qwen3.5-4B; STT: Parakeet 0.6B (Omi Med Finetune) /u/r-chop14가 제출했습니다 [링크] [댓글]