강화 학습 음성 입력: 음성 스택의 GRPO, DPO, 온-폴리시 디스틸레이션

음성 제품에서 진짜 아픈 오류는 평균적인 오류가 아니에요. 모델이 패키지명을 바꿔버리거나, 딱딱한 Slack 답장을 쓰거나, 텍스트를 커밋하기 전 너무 오래 망설이는 그 몇몇 순간들이에요. 강화 학습 음성 입력은 그런 순간들을 겨냥하는 포스트 트레이닝 루프를 통칭하는 우리 표현이에요.

지도 학습 손실이 더 이상 효과를 내지 못하는 이유

지도 학습은 필수예요. 모델에게 과제를 가르치죠 — 오디오 입력, 컨텍스트 입력, 텍스트 출력. 하지만 어느 순간이 되면 쉬운 예제에서는 손실이 계속 좋아지는데 제품은 더 이상 눈에 띄게 좋아지지 않아요. 남아 있는 문제들은 단순한 라벨 형태가 아니라 선호 형태로 굳어 있어요.

기술 받아쓰기를 생각해 봐요. 지도 학습 쌍은 "react query"가 때로는 @tanstack/react-query를 의미한다는 걸 가르칠 수 있어요. 하지만 제품의 질문은 조건부예요. 모델이 발화된 구절을 그대로 보존해야 할까요, 임포트 경로로 다시 써야 할까요, 아니면 커서가 고객 이메일 안에 있으니 평이한 영어로 두어야 할까요? 정답은 컨텍스트와, 사용자가 교정을 얼마나 견디느냐에 따라 달라져요.

구체적인 패턴 하나를 보면, 깨끗하게 낭독한 음성에 대한 내부 벤치마크는 세 번의 연속된 지도 학습 반복에서 1퍼센트포인트도 안 되게 개선됐지만, 실제 워크플로의 도그푸드 편집률은 4퍼센트포인트 이상 변했어요. 그 격차가 바로 선호 형태의 실패의 증거예요. 모델은 기술적으로는 골드 트랜스크립트에 더 가까워졌지만, 사용자가 실제로 문서에 커밋하고 싶었던 것과는 더 멀어진 거예요.

바로 거기서 음성 인식과 텍스트 렌더링을 위한 RL이 유용해져요. 엔터티를 보존하고, 빠르게 도착하고, 목적지 형식과 일치하는 출력에 보상을 주고, 자신만만한 재작성에는 페널티를 줄 수 있어요. 보상은 "더 똑똑해지기"가 아니에요. 보상은 "받아쓰기 후 편집을 덜 하기"예요.

GRPO vs DPO vs PPO

우리는 포스트 트레이닝 도구를 세 계열로 나눠요. PPO는 유연하고 역사적으로도 중요하며, Proximal Policy Optimization처럼 정책 그래디언트 계열의 긴 계보를 갖고 있어요. DPO는 쌍대 선호 데이터가 있고 더 단순한 목적함수를 원할 때 매력적이에요. 깔끔한 정식화를 보려면 Direct Preference Optimization 논문을 보세요.

GRPO 스타일 학습은 그룹화된 후보군에 유용해요. 같은 발화와 컨텍스트에 대해 여러 출력을 생성하고, 보상 함수로 랭킹한 뒤, 더 나은 그룹 행동을 향해 업데이트하는 거예요. Loqua에게는 그룹 비교가 많은 음성 오류에 잘 맞아요. "이 트랜스크립트가 맞나요?"만 묻지 않아요. 현재 앱, 레이턴시 예산, 편집 의도에 비추어 어떤 출력이 최선인지를 물어요.

방법을 레이어에 어떻게 매칭했는가

실제로는 스택의 각 레이어가 다른 포스트 트레이닝 도구를 받아요. 텍스트 렌더러는 DPO와 그룹 최적화의 자연스러운 거처예요. 결정이 국소적이고 옆에 나란히 놓고 비교하기 쉽기 때문이에요. 인스트럭션 플래너는 의도 분류와 포맷 계획을 살짝 움직이기 위해 더 가벼운 쌍대 업데이트를 사용해요. 어쿠스틱 프론트엔드는 대체로 RL 밖에 둬요. 선호 신호가 프레임 단위 오디오와 너무 멀어서 별로 도움이 안 되거든요. 그쪽은 데이터 큐레이션과 지도 학습 정제에서 더 많은 걸 얻어요. 실용적인 선택일 뿐이고 이념이 아니에요. 실패 모드를 가장 명확하게 드러내는 가장 작은 루프를 골라요.

텍스트 렌더링을 위한 온-폴리시 디스틸레이션

온-폴리시 디스틸레이션이 중요한 이유는 텍스트 렌더러가 자신이 실제로 방문하는 상태로부터 배워야 하기 때문이에요. 전통적인 오프라인 디스틸레이션은 더 작은 학생이 추론 시점에 결코 도달하지 못하는, 깨끗한 교사 출력 위에서 훈련될 수 있어요. 스트리밍 받아쓰기 제품에서는 그 미스매치가 눈에 보여요. 학생이 살짝 잘못된 부분 경로를 한번 잡고 나면, 이후 토큰들이 어색해져요.

우리의 텍스트 렌더링 학습은 온-폴리시 디스틸레이션 아이디어를 사용해요. 학생이 후보 연속(continuation)을 생성하게 하고, 더 강한 평가자와 과제 보상으로 그 연속들을 점수화한 뒤, 단절된 골드 경로가 아니라 학생 자신의 궤적 위에서 학습하는 거예요. on-policy distillation과 관련 메모리 정책 최적화 연구의 최근 문헌이 이 문제를 다룰 유용한 언어를 제공해 줘요.

구체적으로 학습 스텝은 이렇게 생겼어요. 실제 도그푸드 발화와 화면 컨텍스트를 가져와요. 학생이 스트리밍 제약 아래에서 세 개에서 다섯 개의 후보 연속을 생성해요. 더 큰 평가자가 엔터티 보존, 레이턴시, 목적지 적합성, 자연스러움 축에서 각 후보를 점수화해요. 그리고 학생은 평가자의 선택에서 현재 얼마나 떨어져 있는지로 가중치를 주어 더 높은 점수의 궤적을 선호하도록 업데이트돼요. 학생은 오프라인 골드 경로를 절대 보지 못해요 — 자기 자신의 행동만, 랭킹된 채로 봐요.

우리가 신경 쓰는 교훈은 단순해요. 모델이 살게 될 곳에서 모델을 훈련시키세요. 음성 입력의 경우 모델은 부분 발화, 가시적 컨텍스트, 불확실한 식별자, 사용자 편집 안에 살아요. 아름다운 오프라인 트랜스크립트만으로는 부족해요.

보상 설계: 레이턴시, 정확도, 자연스러움

보상은 네 부분으로 구성돼요. 정확도는 엔터티 보존, 지원 조건에서의 낮은 WER, 올바른 편집 의도에 보상을 줘요. 레이턴시는 단순히 이른 토큰이 아니라 이른 유용한 텍스트에 보상을 줘요. 자연스러움은 간결한 Slack 답장과 깔끔한 기술 산문을 포함해서, 사용자처럼 읽히는 텍스트에 보상을 줘요. 안전성은 불확실성이 높을 때 보수적으로 행동하는 데 보상을 줘요.

음성 시스템의 보상 설계는 잘못하기 쉬워요. 레이턴시에 과한 가중치를 주면 모델이 너무 일찍 커밋해요. 포매팅에 과한 가중치를 주면 캐주얼한 메모도 템플릿으로 바꿔버려요. 엔터티 보존에 과한 가중치를 주면 정리되어야 할 발화 조각을 그대로 두기도 해요. 보상 가중치는 각 학습 실행 전후의 실제 도그푸딩 편집을 비교해서 튜닝해요.

• 레이턴시 보상: 첫 사용 가능한 텍스트까지의 시간과 안정된 커밋까지의 시간.
• 엔터티 보상: 기술 명칭, 파일 경로, 명령어, 혼합 언어 구간.
• 목적지 보상: Slack, GitHub, Cursor, VS Code, 이메일, 노트 각각에 맞는 올바른 형태.
• 교정 보상: 사용자의 백스페이스 횟수가 줄고, 삽입 후 수동 재작성이 줄어드는 것.

반사실 쌍은 우리가 모으는 가장 유용한 선호 데이터예요. 사용자가 받아쓰기 후 수락한 모든 편집에 대해, 받아쓰기된 텍스트를 거절된 후보로, 편집된 텍스트를 선호된 후보로 두는 쌍을 만들 수 있어요. 그 데이터는 밀도가 높고, 실제 사용과 자연스럽게 정렬되어 있으며, 합성 선호 아티팩트가 없어요. 우리는 그걸 실시간 온라인 RL 신호가 아니라 느리지만 신호 강도가 높은 피드백 루프로 다뤄요.

실제 프로덕션에서의 모습

프로덕션에서 RL은 눈에 보이는 기능으로 나타나지 않아요. 짜증나는 순간이 줄어드는 모습으로 나타나요. Git 커밋 메시지가 간결한 명령형이 돼요. 고객 이메일이 더 따뜻한 톤을 유지해요. 파이썬 주석이 커서 근처에 보이는 식별자를 정확히 그대로 보존해요. 긴 발화는 빠르게 스트리밍을 시작하지만, 위험한 엔터티 구간은 컨텍스트가 확보될 때까지 미뤄요.

작고 구체적인 예시 하나. 터미널 창에서 최근 git diff가 보이는 상태로 "fix the bug where retry exhausts the queue"를 받아쓰면 커밋 제목으로 fix: drain retry queue before exhausting backoff window가 나와요. 같은 발화를 커서가 Slack 스레드에 있을 때 하면 "Fixing the bug where retry exhausts the queue — should land this afternoon."이 나와요. 같은 음성, 같은 화자, 두 개의 서로 다른 목적지 적합 출력. 인스트럭션 플래너가 목적지 계획을 골랐고, 목적지 보상으로 포스트 트레이닝된 텍스트 렌더러가 올바른 형태를 만들어냈어요.

포스트 트레이닝 경계도 좁게 유지해요. 코어 인식기, 인스트럭션 플래너, 텍스트 렌더러는 Loqua의 받아쓰기 표면에 맞춰 사내에서 학습돼요. RLHF, DPO, GRPO 스타일 그룹핑, 온-폴리시 디스틸레이션에 대한 공개 연구는 우리의 평가 어휘에 영감을 주지만, 프로덕션 스택은 우리만의 데이터, 런타임 제약, 프라이버시 경계에 맞춰 튜닝돼요.

실패 모드와 디버깅

RL은 나쁜 보상 함수를 더 잘 드러내요. 흔한 실패 모드는 장황함 편향, 조기 커밋, 스타일 드리프트, 그리고 쉬운 포매팅 단서 주변에서의 보상 해킹이에요. 어블레이션으로 디버깅해요 — 레이턴시 보상을 제거해 보고, 엔터티 보상을 동결해 보고, 화면 컨텍스트가 없는 후보들을 비교해 보고, 실제 도그푸딩 발화를 옛 체크포인트와 새 체크포인트에 다시 흘려봐요.

RL 실행에 대한 머지 전 체크리스트는 짧고 의도적이에요. 교정률이 보류해 둔 선호 세트만이 아니라 실제 도그푸드 데이터에서도 내려갔는가? 첫 사용 가능한 텍스트까지의 p95 시간이 예산 안에 머물렀는가? 영어, 중국어, 코드 식별자 슬라이스 전반에서 엔터티 보존이 유지되거나 개선됐는가? 텍스트 렌더러가 부탁하지도 않은 글머리 기호나 끝맺음 인사를 그만뒀는가? 답이 하나라도 아니오라면 그 체크포인트는 출시 대신 튜닝으로 돌아가요.

가장 중요한 규율은 사람이 읽을 수 있는 오류 분류 체계를 유지하는 거예요. 나쁜 출력은 청취, 엔터티, 의도, 목적지, 톤, 레이턴시, 프라이버시 경계 실패 중 하나로 라벨링되어야 해요. 그 분류 체계가 없으면 강화 학습 음성 입력은 숫자만 좋아지면서 제품 체감은 더 나빠지는 숫자 더미가 돼요.