轉寫
逐字或可讀式轉寫，依循一份涵蓋填充詞、重來、重複、發音錯誤與聽不清楚片段的書面慣例。
- 含不流暢現象的逐字轉寫
- 重可讀性的整理式轉寫
- 聽不清楚與重疊語音標記
- 非語音事件標記
語音與對話
日文語音與音訊資料標註
針對日文音訊的轉寫、時間戳記、語者分段、意圖與語意槽標註，以及情緒或方言標記——依據書面慣例作業，而不是靠沒寫下來的習慣。
兩位轉寫人員拿到同一段日文音訊、卻沒有慣例可循時，大約每三行就會出現一次分歧。分歧的不是「說了什麼」，而是「該怎麼寫」。
逐字稿是一連串決策，不是錄音的複本
日文沒有詞間空格、有四套文字系統，而且一個詞怎麼唸與慣例上怎麼寫之間差距很大。因此音訊一旦變成文字，就有人做了幾十個選擇：有難うございます要寫漢字還是假名、3人要寫成 3人 還是三人、句首的えーっと要保留還是刪掉、講到一半重來的句子要照實轉寫還是修順。
這些選擇單獨看都不算錯。錯的是在整個語料庫裡做得前後不一致，因為以不一致的目標訓練出來的 ASR 模型，會學到同一個聲音對應到好幾個字串，而它的錯誤率就把這個差異吸收掉了。日文語音資料中最大的單一品質槓桿，就是一份寫下來、而且真的被落實的正規化慣例。
所以每一個語音專案，我們都從議定那份文件開始——若貴團隊已經有一份，我們採用您的，而不是強加我們的。
重點速覽
- 任務類型
- 逐字與可讀式轉寫、時間戳記、語者分段、意圖與語意槽標註、情緒與韻律、方言標記。
- 可處理音訊
- 客服中心錄音、會議、訪談、廣播、車內與裝置語音、自然對話。
- 慣例
- 文字選擇、填充詞、數字、笑聲與聽不清楚的片段，都在轉寫開始前先定義好。
- 典型輸出
- 含逐詞或逐段時間軸的 JSON；亦支援 SRT、VTT、CTM 與 TextGrid。
- 審查
- 每個檔案都經第二輪聆聽複查，並對樣本進行盲重轉寫。
任務類型
我們標註什麼
轉寫通常是基礎層；其餘各項都疊加在同一條時間軸上。
時間軸與對齊
段落、語句或詞層級的時間戳記；若已有逐字稿，亦可執行強制對齊。
- 語句邊界
- 詞層級時間軸
- 強制對齊品質檢查
- 靜音與重疊區段
語者標註
誰在說話——跨越重疊語音與聲道切換，這也是真實通話錄音上最常出錯的部分。
- 語者分段與語者 ID
- 角色標籤（客服／顧客）
- 重疊語音處理
- 語者屬性標記
意圖與語意槽標註
這句話想達成什麼、又帶有哪些值，疊加在逐字稿之上，供語音助理與通話分析使用。
- 意圖分類
- 語意槽與實體範圍
- 對話行為標籤
- 通話結果與處理狀態
副語言標註
情緒、情感、韻律重音、說話風格與地區腔調，依既定類別評分，而非憑印象。
- 情緒與情感
- 說話風格與禮貌程度
- 地區腔調與口音
- 音訊品質與環境標記
日文特有事項
一份日文慣例必須做出的決策
以下四項，涵蓋了兩位稱職轉寫人員之間大部分的分歧。
同一個詞的文字選擇
表記ゆれありがとう、有難う與アリガトウ是同一個詞。若交由各個轉寫人員自行決定，語料庫裡三種都會出現，而模型會把它們當成不同的目標。
我們的處理方式 慣例會列出常用詞必須採用的寫法，其餘則設一條預設規則，並在交付前以自動檢查標出變體。
數詞與量詞
数詞・助数詞日文的量詞會隨所數名詞改變讀法——一本、一杯、一人——而同一個數字可以寫成 3、三或参。寫得不一致，最終模型的數字正確率就變得無從量測。
我們的處理方式 數字政策依情境固定使用阿拉伯數字或漢字，並規定量詞與單位的轉寫方式，附上日期、金額、時間與電話號碼的實作範例。
填充詞與不流暢現象
フィラーあの、えーっと、まあ與そのー在自然日文中隨處可見。保留它們會讓逐字稿更雜；刪掉它們則會讓逐字資料無法用於處理不流暢現象的模型。
我們的處理方式 逐字版與整理版分別定義，各自有固定的填充詞清單與寫法，讓這項選擇成為專案設定，而不是逐檔判斷。
禮貌與敬語形式
敬語客服中心的日文充滿尊敬語與謙讓語，其中好幾組在趕工的轉寫人員耳中經常聽錯——いたします與いただきます、よろしいでしょうか與よろしかったでしょうか。
我們的處理方式 審查者會針對貴團隊音訊類型特有的敬語型態接受說明，敬語錯誤在審查中是具名的類別，不會被併入一般的正確率裡。
流程
一個語音專案怎麼進行
慣例文件在任何人轉寫完整檔案之前就先寫好，之後只透過版本化的變更修訂。
-
01
取樣與界定範圍
我們會聆聽具代表性的樣本——包含貴團隊最差的音訊，而不只是最乾淨的——並找出真正困難的地方。
-
02
撰寫慣例
文字寫法、數字、填充詞、非語音事件、重疊語音、聽不清楚片段、語者角色與時間軸精細度，全都在一份由您核可的文件中固定下來。
-
03
以試辦校準
數位轉寫人員各自獨立處理相同檔案。凡是出現分歧之處，就代表慣例有模糊地帶，並據以磨得更精確。
-
04
轉寫與審查
每個檔案都由另一個人做第二輪聆聽複查；並對樣本進行盲重轉寫，以產出經量測的正確率數據。
-
05
交付與呈報
逐字稿、時間軸與標籤會連同慣例版本、品質報告，以及被標記為無法使用（而非靠猜測填補）的檔案清單一併交付。
交付
輸入與輸出格式
我們直接處理貴團隊現有的音訊。若編碼格式或取樣率限制了可達成的結果，我們會在專案開始前就說明，而不是事後才講。
| 層級 | 預設輸出 | 亦可提供 |
|---|---|---|
| 逐字稿 | 含分段時間軸的 JSON | 純文字、SRT、VTT |
| 詞層級時間軸 | JSON | CTM、TextGrid |
| 語者標籤 | RTTM 或 JSON 語者輪次 | 分聲道逐字稿 |
| 意圖與語意槽 | JSONL，每行一句 | CSV、CoNLL 範圍格式 |
| 副語言標籤 | 含時間範圍的 JSONL | CSV、ELAN 標註檔 |
品質
針對這類工作的控管措施
日文音訊的正確率是量測出來的，不是宣稱出來的——而且量的是困難的檔案，不是容易的那些。
- 由第二位轉寫人員對樣本進行盲重轉寫，產出每一批次經量測的錯誤率。
- 交付前自動檢查文字變體、數字格式與填充詞寫法是否符合慣例。
- 時間軸對照音訊本身驗證，而不只是對照相鄰的段落。
- 確實無法轉寫的檔案會被標記並照實回報，絕不會用看似合理的猜測填上。
- 語者標籤會就整個檔案通盤檢查，讓中途身分對調的情況能被抓出來。
- 品質抽樣中刻意納入困難音訊，讓呈報的數據反映整個語料庫，而不是其中最好的部分。
常見問題
關於語音與音訊
團隊在寄出第一批日文音訊前會問的問題。
可以，而且對乾淨的音訊來說，這通常更划算。但要留意：修正機器逐字稿會讓人偏向接受畫面上已有的文字，因此對訓練資料而言，我們要嘛從零轉寫，要嘛對樣本做一次盲檢查，量測修正這一關實際上抓出了多少問題。
我們會事先議定方言是照說話原樣轉寫，還是正規化成標準日文，因為這個決定會徹底改變整份資料集。若方言在範圍內，我們會標記腔調類別；對於哪些腔調我們能穩定配置人力、哪些不能，我們也會坦白說明。
我們處理真實的錄音，包含電話頻寬的通話音訊、背景噪音與說話重疊。比格式更重要的是：請一開始就提供具代表性的樣本——用乾淨音訊界定範圍、卻拿吵雜音訊交付，正是語音專案出事的典型原因。
可以，在簽署保密協議與資料處理協議的前提下，於具備角色權限控管的隔離環境中作業，並依合約議定保存與刪除條款。若錄音含有個人資料，我們也能標記出來以供遮蔽，或處理您在寄送前已遮蔽過的音訊。完整說明請見資訊安全頁面。
可以。重疊正是自動語者分段最常失敗的地方，也是需要交給人來做的主要理由之一。我們的慣例明訂重疊語音如何切分與歸屬，讓處理方式保持一致，而不是逐檔臨場決定。