サンボーの日記
サンボーです。会議の録音を文字起こしにかけたら、自分の発話が全部「ご視聴ありがとうございました」って一文に化けてました。57分の会議も40分の会議も同じ症状で、8月18日にも似た事故があったんですけど、今回は原因がまるで別でした。
まず録音の失敗を疑ったんですが、音量を測ったら無音じゃなくて有音区間は71%あったんです。会議の中身をよく覚えてる90秒だけ切り出して同じモデルにかけ直したら、今度は完璧に文字起こしできました。
違いは冒頭にあって、相手が入室するまでの約4分間、音声がほぼ無音だったんです。この無音区間でモデルが幻聴を起こして、直前の出力を次の判断材料として引き継ぐ設定のせいで、その幻聴が最後まで連鎖してました。引き継ぎ設定を1行オフにしたら、13行しかなかった文字起こしが782行に戻ったんです。
実務の記録
会議の録音を文字起こしにかけたところ、自分側の発話がすべて「ご視聴ありがとうございました」という一文に置き換わっていました。57分の会議と40分の会議、どちらも同じ症状でした。8月18日にも似た事故が起きていましたが、今回は原因がまったく別でした。
まず疑ったのは録音の失敗です。しかし音量を測ると無音ではなく、有音区間は71%ありました。会議の中身をよく覚えている90秒だけを切り出して同じモデルにかけ直すと、今度は完璧に文字起こしできました。録音そのものは壊れていなかったことになります。
違いは冒頭にありました。会議の最初、相手が入室するまでの約4分間、音声はほぼ無音でした。この無音区間で文字起こしモデルが幻聴を起こし、それらしい文章を生成していました。原因はモデルの精度そのものではなく、直前の出力を次の区間の判断材料として引き継ぐ「前文脈の引き継ぎ」という設定でした。冒頭で生まれた幻聴の一文が、次の区間の判断材料として使われ続け、最後まで連鎖していたのです。
引き継ぎの設定を1行オフにして同じ音声を処理し直すと、13行しかなかった文字起こしが782行に戻りました。冒頭の4分間だけが特殊な状態で、そこに依存する処理は冒頭から壊れると全滅する、という構造がはっきりしました。
今回の教訓は3つです。1つ目は、出力の量が入力の量に見合っているかを検品すること。2つ目は、生成系の不調は「最初の数分間だけ空白」であっても、その空白が全体に連鎖しうると疑うこと。3つ目は、失敗を録音側だと決めつけず、短い区間だけ切り出して処理側を切り分けるテストをすること。この3つで、原因の特定にかかる時間がかなり短くなりました。
今日の学び
出力の量が入力の量に見合っているかを検品することと、冒頭だけの空白でもその状態が全体に連鎖しうると疑うことが必要です。失敗を録音側だと決めつけず、短い区間だけ切り出して処理側を切り分けるテストをすると、原因の特定にかかる時間がかなり短くなります。
自社でやるなら
まず変えること
文字起こし・議事録の自動化では、出力の行数・文字数が録音の長さに見合っているかを、毎回の検品項目に入れてみてください。
形骸化させない仕掛け
文字起こしが極端に短い・内容が単調な結果になったときは、録音全体を疑う前に、内容を覚えている数十秒〜90秒程度だけを切り出して同じ処理にかけ直し、処理側の問題かどうかを切り分けてみてください。
振り返りの周期
『前文脈を引き継ぐ』『直前の出力を次の判断材料にする』といった設定を使っている自動処理は、冒頭など特定区間だけ状態が悪いと、そこから最後まで連鎖して壊れる可能性があると想定して点検してみてください。
コピペで使えるプロンプト
文字起こしの異常を録音側か処理側かで切り分けるプロンプト
文字起こしの結果が録音の長さに対して極端に短い、または同じ文章の繰り返しになっています。録音の音量・有音区間の割合を確認したうえで、内容を覚えている30〜90秒程度だけを切り出して同じ処理にかけ直し、結果が正常に戻るかどうかで、原因が録音側にあるのか、処理側（前文脈の引き継ぎなど直前の出力に依存する設定）にあるのかを切り分けて教えてください。