拓海先生、最近社内で「ML（機械学習）を使ったコーデックを導入すべきだ」という話が出ておりまして、正直何が違うのかよく分かりません。要するに今の圧縮と何が変わるんですか？
素晴らしい着眼点ですね！大丈夫、一緒に整理しましょう。端的に言うと、従来のDSP（Digital Signal Processing）ベースのコーデックと、機械学習（ML: Machine Learning）ベースのコーデックでは、出てくる映像の「劣化の種類」が違いますよ、という話です。
映像の劣化の種類が違う、ですか。例えばどんな違いが現場で問題になるのでしょうか。現場では結局画質が見苦しくなればクレームになりますから、投資に見合う値打ちがあるか知りたいのです。
良い質問です。要点を3つにまとめますね。1つ目、MLコーデックは人間の視覚に合わせた圧縮を行うため、従来の指標とズレることがある。2つ目、従来の客観指標はDSP向けに設計されており、ML特有のアーティファクトに弱い。3つ目、それを解くために新しいデータセットと評価モデルを用意した研究があるのです。
これって要するに、今使っている評価方法だとMLコーデックの良さや悪さを正確に測れない、ということですか？
その通りですよ。要するに既存の指標は“設計思想”が違うため、MLコーデックの主観評価（人間がどう感じるか）と相関が悪くなることがあるんです。だから研究者たちは、MLコーデックに合う新しいフルリファレンス評価モデルとデータセットを作ったのです。
なるほど。で、その新しい評価モデルは現場で使えるんですか。精度が良くても高価で導入に手間がかかるなら二の足を踏みます。
良い視点ですね。ここで大事なのは実務視点の3点です。導入の手間、計算資源、そして信頼性です。この研究は高い相関（PCCとSRCCが0.99）を示しており、評価の自動化によって開発サイクルを短縮できるため、長期的にはコスト削減につながりますよ。
計算資源というのは、サーバー代やGPUが必要になるということですね。うちの規模でどれくらいの投資が必要なのか、ざっくりでいいので判断基準を教えてください。
素晴らしい着眼点ですね！まず小さく試すのが現実的です。評価モデル自体は公開されており、クラウドの安価なGPUやCPUリソースでバッチ処理を回せます。現場判断での目安は、月次での評価自動化で工程短縮が見込めれば投資回収は比較的早いです。
もう一点。結局、主観テスト（人が評価するテスト）を省略していいのかが心配です。顧客満足に直結する部分ですから。
いい懸念です。要点は二つあります。評価モデルは主観テストを完全に置き換えるのではなく、開発サイクルでの一次評価を自動化するツールと考えること。最終的な意思決定の前に代表サンプルで主観評価を行えばリスクは抑えられますよ。
なるほど。最後に、私が会議で説明するための一言を教えてください。短く要点だけ伝えたいのです。
もちろんです。簡潔に言うと、「MLコーデックは従来指標で測りきれない品質の違いを生む。新しい評価モデルで開発効率を高め、最終判断は代表サンプルで主観評価する方針で進めましょう」です。大丈夫、一緒に準備すれば必ずできますよ。
よく分かりました。では私の言葉で整理します。新しい評価はML向けに作られた精度の高い自動評価で、開発スピードを上げるための実務ツールである。最終的な顧客判断だけはサンプリングで人が確認する、という認識で進めます。
