書き起こし
素起こしまたは整文。フィラー、言い直し、繰り返し、言い間違い、聞き取れない区間の扱いを明文化したルールに沿って行います。
- 非流暢性を含む素起こし
- 読みやすさを優先した整文
- 聞き取り不能・発話重複の明示
- 非音声イベントのタグ
音声・対話
日本語音声に対する書き起こし、タイムスタンプ付与、話者ダイアライゼーション、意図・スロット付与、感情や方言のタグ付け。暗黙の慣習ではなく、明文化したルールに沿って作成します。
同じ日本語音声を、ルールなしで二人に書き起こさせると、3行に1行くらいは食い違います。何を話したかではなく、どう書くかで、です。
日本語には分かち書きがなく、4つの文字体系があり、音と慣用的な表記のあいだに大きな隔たりがあります。ですから音声がテキストになった瞬間に、誰かが何十もの選択をしています。有難うございます を漢字で書くかかなで書くか、3人 と書くか三人と書くか、文頭の えーっと を残すか落とすか、語の途中の言い直しをそのまま書くか整えるか。
どの選択も、単独では間違いではありません。間違いなのは、コーパス全体で不揃いに選ぶことです。一貫しない正解を学習したASRモデルは、同じ音が複数の文字列に対応すると学び、その差はそのまま誤り率に吸収されます。日本語の音声データで最も効く品質の梃子は、明文化され、実際に守られている正規化ルールです。
ですから音声のプロジェクトは、必ずその文書の合意から始めます。すでにお持ちの場合は、当社のものを押しつけず、お客様のルールを採用します。
要点
タスク種別
通常は書き起こしが基盤の層になり、それ以外は同じタイムライン上に重ねていきます。
素起こしまたは整文。フィラー、言い直し、繰り返し、言い間違い、聞き取れない区間の扱いを明文化したルールに沿って行います。
セグメント、発話、単語単位のタイムスタンプ。既存の書き起こしがある場合は、それに対する強制アライメント。
発話が重なる箇所やチャネルの切り替わりを含めて、誰が話しているか。実際の通話録音で最も壊れやすい部分です。
その発話が何をしようとしていて、どんな値を含んでいるか。音声アシスタントや通話分析のために、書き起こしの上に重ねます。
感情、センチメント、韻律的な強調、話し方、地域差。印象ではなく、定義したカテゴリに照らして採点します。
日本語固有の論点
力量のある書き起こし担当者どうしの食い違いは、この4つでおおむね説明がつきます。
ありがとう、有難う、アリガトウ は同じ語です。各担当者の判断に委ねれば、コーパスには3つとも入り、モデルはそれらを別の正解として扱います。
当社の対応 ルールに頻出語の表記を列挙し、それ以外の既定ルールを定め、納品前に自動チェックが表記の揺れを検出します。
日本語の助数詞は数えるものによって読みが変わり(一本、一杯、一人)、数字は 3 とも 三 とも 参 とも書けます。表記が揃わないと、できあがったモデルの数値の正確さは測定不能になります。
当社の対応 数字のルールで、文脈ごとにアラビア数字か漢数字かを決め、助数詞と単位の書き方を定めます。日付、金額、時刻、電話番号の実例も添えます。
あの、えーっと、まあ、そのー は自然発話の日本語に頻出します。残せば書き起こしはノイズが増え、落とせば非流暢性を扱うモデルにとって素起こしデータの意味がなくなります。
当社の対応 素起こしと整文をそれぞれ別に定義し、フィラーの一覧と表記を固定します。判断がファイルごとにぶれず、プロジェクトの設定になります。
コールセンターの日本語は尊敬語・謙譲語が濃く、速度を求められる作業では取り違えやすい表現がいくつもあります。いたします と いただきます、よろしいでしょうか と よろしかったでしょうか など。
当社の対応 対象音声に特有の敬語のパターンをレビュアーに事前共有し、敬語の誤りはレビュー工程で一つの名前のついたカテゴリとして扱います。一般的な正確さに埋もれさせません。
プロセス
誰かが1ファイルを通して書き起こす前に、ルールの文書を作成します。改訂はバージョン管理された変更としてのみ行います。
代表的なサンプルを聴きます。きれいな音声だけでなく、最も条件の悪い音声も含めて聴き、実際に何が難しいのかを特定します。
表記、数字、フィラー、非音声イベント、発話重複、聞き取り不能区間、話者の役割、タイミングの粒度を、お客様の承認する文書で固定します。
複数の担当者が同じファイルを独立に作業します。分かれた箇所はルールが曖昧だった箇所なので、そこを鋭くします。
全ファイルを別の担当者が二度目に聴取します。サンプルはブラインドで再書き起こしし、実測の正確さの値を出します。
書き起こし、タイミング、ラベルに、ルールのバージョン、QAレポート、推測で埋めずに使用不能として扱ったファイルの一覧を添えて納品します。
納品
お客様の音声を、そのまま扱います。コーデックやサンプリングレートが達成できる水準を制約する場合は、事後ではなくプロジェクト開始前にお伝えします。
| レイヤー | 標準出力 | その他の対応形式 |
|---|---|---|
| 書き起こし | セグメント単位のタイムスタンプ付きJSON | プレーンテキスト、SRT、VTT |
| 単語単位のタイミング | JSON | CTM、TextGrid |
| 話者ラベル | RTTMまたは話者ターンのJSON | チャネル別の書き起こし |
| 意図とスロット | JSONL、1行1発話 | CSV、CoNLL形式のスパン |
| パラ言語ラベル | 時間区間付きJSONL | CSV、ELANのアノテーションファイル |
品質
日本語音声に対する正確さは、主張するものではなく計測するものです。しかも、易しいファイルではなく難しいファイルで計測します。
よくあるご質問
初めて日本語音声のバッチをお送りいただく前に、よくいただくご質問。
はい。音質が良い場合は、たいていそのほうが費用対効果に優れます。ただし注意点があります。機械の書き起こしを修正する作業は、画面にすでにある内容を受け入れる方向に人を引っ張ります。そのため学習データについては、ゼロから書き起こすか、サンプルにブラインドの検査を行い、修正工程が実際にどれだけ拾えているかを計測します。
方言を話されたとおりに書き起こすのか、標準的な日本語に正規化するのかを事前に合意します。この判断でデータセットの性格が丸ごと変わるからです。方言が対象に含まれる場合は変種をタグ付けし、どの変種なら確実に体制を組めて、どれが難しいかは率直にお伝えします。
電話帯域の通話音声、背景ノイズ、発話の重なりを含む、実際の録音を扱います。形式より大事なのは、代表的なサンプルを最初にお送りいただくことです。きれいな音声で範囲を決めて、ノイズの多い音声で納品する。これが音声プロジェクトの失敗の典型です。
はい。NDAとデータ処理契約のもと、ロールベースのアクセス制御を敷いた隔離環境で作業し、保持と削除の条件は契約で合意します。録音に個人情報が含まれる場合は、マスキング対象としてマークすることも、お客様側でマスキング済みの音声を扱うこともできます。全体像はセキュリティのページをご覧ください。
はい。発話の重なりは自動ダイアライゼーションが最も失敗しやすい箇所であり、人が入る主な理由の一つです。当社のルールでは、重なった発話をどう区切り、誰に帰属させるかを定義しているため、ファイルごとに判断がぶれることはありません。
音声・音響
仕様書よりも、代表的なサンプルのほうが多くを語ります。ルールの草案、書き起こしたサンプル、そして見込まれる誤り率についての率直な見解をお返しします。
データをご共有いただく前にNDAを締結します。パイロットの要件定義は無料です。