機械学習システムにおける「技術的負債」とその回避策

#はじめに
空前のAIブームだった2017年、Yahooニュースでは毎日のように『〇〇が△△のAIを開発』のような見出しが目立ちました。2018年は『AIの運用』の時代になるとも言われています。
しかし、AI（機械学習）を載せたシステムの開発・テスト・運用の方法は2018年4月現在、まだ確立されていない分野です。

今回は、技術的負債という観点から、機械学習システム特有の課題点とその回避策のヒントまとめたGoogleの論文
Machine Learning: The High Interest Credit Card of Technical Debt (2014)
を翻訳します。Google翻訳+軽い手作業ですのでご留意を。

ちなみにタイトル**『機械学習：技術的負債の高金利クレジットカード』**の意味は、機械学習システムがまるで高金利のクレジットカードのように、気づかないうちに技術的負債を蓄積してしまうことを比喩した表現です。

#目次

1. 機械学習と複雑系
2. 複雑なモデルのシステム境界への侵食
   1. 「もつれ」
   2. 隠れたフィードバックループ
   3. 宣言されていない利用者
3. コード依存性を超えるデータ依存性コスト
   1. 不安定なデータ依存関係
   2. 十分に活用されていないデータ依存性
   3. データ依存の静的分析の難しさ
   4. 修正の連鎖
4. システムレベルのスパゲッティ
   1. グルーコード
   2. パイプラインジャングル
   3. 死んだ実験コードパス
   4. 設定の負債
5. 外部データの変更を扱う
   1. 動的システムにおける固定値
   2. 相関がもはや相関しなったとき
   3. 監視とテスト
6. 結論
7. リファレンス

要旨

機械学習は、複雑なシステムを構築するための非常に強力なツールキットを素早く提供します。本稿では、これらの短期間による成果が、自由をもたらしてくれると考えることは危険であると主張します。機械学習を適用する際、システムレベルで大規模な継続的なメンテナンスコストが発生する状況は、容易に起こりうることを、技術的負債の枠組みを使用して説明します。本稿の目標は、機械学習の特定のリスク要因や、可能な場合は回避またはリファクタリングすべき設計パターンを解説しています。これらは、境界浸食、絡み合い、隠されたフィードバックループ、宣言されていない消費者、データの依存関係、外界の変化、およびシステムレベルのアンチパターンの多様性を含んでいます。

#1. 機械学習と複雑系
実世界のソフトウェアエンジニアは、新しい製品やサービスの開発において期限に迫られるという課題に直面することが多く、実行のスピードとエンジニアリングの品質とのジレンマにつながる可能性があります。 技術的負債の概念は、そのような決定のコストを定量化する方法として、1992年にWard Cunninghamによって最初に導入されました。 財政負債の発生と同様に、技術的な負債を取る戦略的な理由があることがよくあります。 すべての債務が必ずしも悪いわけではありませんが、技術的負債は複合化する傾向があります。 コストを削減し、システムの脆弱性を減らし、革新率を低下させます。

テクニカル・デットを支払う従来の方法には、リファクタリング、ユニット・テストの適用範囲の拡大、デッド・コードの削除、依存性の削減、APIの強化、ドキュメンテーションの改善などがあります。これらの活動の目的は、新しい機能を追加することではなく、将来の改善を簡単に追加し、保守コストを削減し、バグの可能性を減らすことです。

　本稿の基本的な論点の1つは、機械学習パッケージは基本的なコードの複雑さの問題を通常のコード同様持っていますが、システムレベルの複雑さがより大きな隠れた負債を生み出すということです。したがって、これらのライブラリを、リファクタリングする、単体テストを増やす、などの対処は、時間をかけたとしても、必ずしもシステムレベルで負債に対処するわけではありません。

本稿では、隠れた技術的負債が急速に蓄積する可能性のある領域として、機械学習コードと大規模システムとの、システムレベルの相互作用に焦点を当てます 。システムレベルでは、機械学習モデルが抽象境界を侵食する可能性があります。その場合、分離させたシステムで、意図しない密結合を生じるような方法で入力信号を再使用することが魅力的かもしれません。機械学習パッケージは、しばしばブラックボックスとして扱われることがあり、その結果、「グルーコード」または校正層が大量になります。外的な世界の変化は、モデルや入力信号が意図しない行動を起こし、メンテナンス費用や負債の負担を増大させる可能性があります。システム全体が意図したとおりに動作していることを監視することさえも、設計をしなければ困難な場合があります。

実際に、一部の著名なはすでに「機械学習」の業務におけるこの問題にすでに取り組んでいます。 技術的負債の払い戻しは、学術ML会議で報告された研究成果よりも魅力的ではないかもしれません。しかし、それは長期的なシステムの健全性にとって重要であり、アルゴリズムの進歩および他の最先端の改善を可能にします 。

#2.複雑なモデルのシステム境界への侵食
伝統的なソフトウェアエンジニアリングによれば、カプセル化とモジュール設計を使用した強い抽象化境界は、単なる変更と改善を容易にする保守可能なコードを作成するのに役立ちます。 厳密な抽象化境界は、与えられたコンポーネント[4]からの情報入力と出力の不変量と論理的一貫性を表現するのに役立ちます。
　残念なことに、システムに特定の意図された動作を遵守させることによって、機械学習システムの厳格な抽象境界を強制することは困難です 。 実際、機械学習システムを使用する重要な理由の一つは外部データを活用することであるため、外部データに依存することなく、ソフトウェアロジックで目的の動作を効果的に実装できないということです。 抽象的な行動インバリアントをデータのクォークから分離する方法はほとんどありません。 結果として生じる境界の侵食は、技術的負債の大幅な増加を引き起こす可可能性があります。 このセクションでは、このいくつかの問題を検討します。

##2.1　もつれ（Entanglement）
　抽象的な観点から、機械学習パッケージは、データソースを混合するためのツールです。混合する中で、機械学習モデルは「もつれ」を生み、修正の切り離しを効率的に行うことを不可能にします。

具体例

　変数x1... xnを使うモデルのシステムがあるとします。x1の値の入力分布を変更すると、残りのn-1個の変数の重要度、重み、または用途がすべて変更されることがあります。これは、モデルがバッチスタイルで完全に再学習されているか、オンラインで適応されているかどうかにかかわらず該当します。新しい変数xn + 1を追加した際も、同様の影響がある可能性があります。変数xjの削除も同様です。入力は真に独立していません。

　機械学習では「何かを変えればすべてが変わる 」と言えます。ここではこれをCACE（Changing Anything Changes Everything）の原則と呼んでいます。このような変更の正味の結果は、予測の振る舞いが分布の部分ごとに、微妙にまたは劇的に変化する可能性があることです。

ハイパーパラメータにも同じ原則が適用されます。正則化の強さ、学習設定、訓練におけるサンプリング方法、収束閾値、および本質的に可能性のある調整の変化は、同様に幅広く影響を及ぼす可能性があります。
###負債を緩和するアプローチ

1.モデルを分離しアンサンブルする

１つの問題緩和アプローチとして、モデルを分離しアンサンブルすることが挙げられます。このアプローチは、[8]のような、別個のモデルを維持するコストが強制的なモジュール性の利点よりも上回る状況で有用である。しかし、多くの大規模な設定では、そのような戦略はスケーラブルではないことが判明する可能性があります。そして、与えられたモデルの中で、「もつれ」の問題がまだ存在するかもしれません。

2.予測の振る舞いに深い洞察を得る方法を開発する

　もう1つの問題緩和アプローチは、モデルの予測の振る舞いに深い洞察を得る方法を開発することです。 [6]では、高次元の視覚化ツールを使用して、研究者が多くの次元やスライシングに及ぼす影響をすばやく確認できる方法が提案されました。スライス単位で動作するメトリックも非常に有用です。

3.より高度な正則化を用いて堅牢なモデルにする

　第3の可能性は、より高度な正則化を用いて、予測性能の変化がトレーニングで使用される目的関数のコストを大きくする[5]。 他のアプローチと同様に、この種のアプローチは有用かもしれませんが、保証とはかけ離れており、もつれの減少によって負債が減少するよりもシステムの複雑さが増して負債が増える可能性があります。

　上記の緩和戦略は役に立つかもしれませんが、このもつれの問題は、使用されている特定の学習アルゴリズムにかかわらず、機械学習の本質的なものです。 実際には、このことは、機械学習システムの最初のバージョンを出荷するのは簡単ですが、それ以降の改善を行うことは予期せず困難であることを意味します。 MLシステムのバージョン1.0の締め切り圧力に対して注意深く検討する必要があります。

##2.2隠れたフィードバックループ
現実のシステムに対するもう一つの心配は、隠れたフィードバックループにあります。

具体例

　明らかなフィードバックループは意図されて起こります。例えば、ウェブサイト上のニュース見出しのクリックスルー率（CTR）を予測するシステムは、ユーザのクリックをトレーニングラベルとして利用する場合、次に作ったモデルは、以前のモデルの予測に依存する可能性が高い。これは、システムのパフォーマンスを分析する際に問題につながりますが、これらは、機械学習の研究者（データサイエンティスト）が自然に発見ことができる明らかな課題です[2]。

　隠れたループの例を挙げます。このCTRモデルで使用されている入力機能の1つに、特定のユーザーが過去1週間にクリックしたニュース見出しの数を報告するxweek変数であるとします。 CTRモデルが改善されれば、すべてのユーザーにはより良いレコメンドが与えられ、多くのユーザーがより多くの見出しをクリックする可能性が高くなります。しかし、この効果の結果は、xweek変数の値が完全に更新されるまでの少なくとも1週間は完全に表示されません。

　さらに、データがバッチモードで遅れて更新、またはオンラインアップデートでストリーミング形式で更新された場合、モデルが再学習してxweek変数の扱いを調整するタイミングが遅れることがあります。そのような設定では、システムはゆっくりと1週間以上の時間軸で動作を変化させます。迅速な実験では目に見えない段階的な変化は、提案された変化の影響を分析することを非常に困難にし、単純な改善にも余計なコストがかかります。

負債を緩和するアプローチ

可能であれば、隠れたフィードバックループを慎重に探し、削除することをお勧めします。

2.3宣言されていない使用者

　多くの場合、機械学習モデルからの予測は、実行時にまたは後で他のシステムによって使用される可能性のある場所に吐き出されることで、多種多様な別なシステムにアクセス可能にされる。より古典的なソフトウェアエンジニアリングでは、これらの問題を視認性債務[7]と呼びます。アクセス制御がなければ、これらの別のシステムの一部は、「宣言されていない使用者」であり、システムの別のコンポーネントへの入力として所定の予測モデルの出力を使用する可能性があります。宣告されていない使用者は余計なコストがかかり、最悪の場合はシステムに危険をもたらします。

　宣言されていない使用者へのコストは、突然、機械学習モデルAの結果を他のシステムに密に結合させたときにで発生します。 Aへの変更は、これらの他の部分に影響を与える可能性が高く、時にその影響は、意図しない、わかりにくい、有害なものです。その結果、Aに修正を加えることが困難になってしまうという影響があります。宣言されていない使用者の危険は、追加の隠れたフィードバックループを生み出す可能性もあります。

具体例

　具体例を示します。二ュース見出しに対するCTRの機械学習予測システムで、見出しに使用されるフォントのサイズを「インテリジェントに」決定する別の機能があると想像してください。このフォントサイズモジュールが入力値としてCTRを使用することで、CTRをフォントサイズの決定要因として含め、フォントサイズがクリックするユーザーの傾向に影響を与える場合、新しい隠れたフィードバックループが追加されます。そのようなシステムが見出しのサイズを徐々に無限に大きくするケースを想像するのは簡単です。

発見が難しいパターン

宣告されていない使用者は、システムが特別にガードするように設計されていない限り、検出するのが難しい場合があります。ガードする機能がなく、締切に迫られていればなおさら、エンジニアは、間違った情報を掴んでしまう可能性があります。

#3.コード依存性を超えるデータ依存性コスト
　[7]では、古典的なソフトウェアエンジニアリングにおいてコードの複雑さは、依存関係の債務や、技術的負債の主要な要因とされています。本稿では、機械学習システムにおけるデータ依存性は、コードの複雑性同様の負債の要因であると主張する。さらに、コード依存性は、静的解析、リンケージグラフなどを介して比較的容易に識別することができるが、データ依存性が類似の解析ツールを有することははるかに一般的ではない。したがって、解くのが困難な大きなデータ依存関係を構築することは、不適切な場合があります。

##3.1　不安定なデータ依存関係
動くもの急いで作ることを目的とし、他のシステムで生成された値を変数として使用することは便利なことがあります。しかし、入力変数の中には、不安定なものもあります。例えば、時間の経過とともに定性的に挙動が変化するもの。これは、入力信号が時間の経過とともに更新される別の機械学習モデル自体から来るとき、TF / IDFスコア、意味論的マッピングを計算するためのデータ依存ルックアップテーブルから来たときに、暗黙的に起こり得ます。また、入力値の変更権限所有者が、モデルの変更権限所有者とは別の場合に、明示的に発生する可能性があり、このような場合、機械学習システムにどう影響するか関係なく、入力信号の変更と改善が定期的に実施される可能性があります。上記のCACE原則で述べたように、 入力信号に対する「改善」は、診断と対処にコストがかかる、時には有害な、任意の有害な影響を及ぼすことがあります。

負債を緩和するアプローチ

　不安定なデータ依存性のための1つの共通の問題緩和アプローチは、所与の入力データのバージョン化されたコピーを作成することである。たとえば、トピッククラスタへの単語のセマンティックマッピングを時間の経過とともに変更するのではなく、このマッピングのフリーズバージョンを作成し、更新バージョンが完全に検証されるまで使用してもよいでしょう。しかし、バージョニングは、潜在的な陳腐化などの独自のコストを伴います。そして、同じデータの複数のバージョンを時間の経過とともに維持するという要件は、それ自体が技術的負債の一因となっています。

3.2十分に活用されていないデータ依存性

　コードにおける十分に活用されていない依存関係とは、ほとんどが不要なパッケージのことです[7]。同様に、データにおける十分に活用されていない依存性とは、入力特徴量に精度の点で価値がほとんどない特徴量が含まれまれていることを示します。十分に活用されていない依存関係は、システムが不必要に変更に脆弱になるため、コストがかかる。十分に活用されていない依存関係は、いくつかの点で機械学習モデルに影響を与える可能性があります。

####レガシーな特徴量
　モデル構築の初期段階において、すべての変数がその開発のでモデルに含まれているということは一般的に起こりえます。多くの場合、時間が経つにつれて変数の大部分または完全に冗長になるが、これは検出されません。
####まとめられた特徴量
　締め切り圧力ため、多くの変数を正しく分離せずに、それぞれの特徴量をまとめて運用してしまう可能性があります。この形式のプロセスは、ほとんど価値を持たない特徴量を隠してしまいます。
####є- 特徴量
　機械学習の研究者として、モデルの精度を改善することは嬉しいことです。精度の向上が非常に小さい場合や複雑さのオーバーヘッドが高い場合でも、精度を向上させる新しい特徴量をモデルに追加することができます。

　これらのすべてのケースで、精度をほとんど損なうことなく、モデルから特徴量を削除することができます。しかし、それをしない場合、モデルは多分その特徴量にいくつかの重みを割り当て、システムは時には壊滅的に、これらの不要な機能の変更に脆弱です。

具体例

たとえば、チームの合併後、古い製品番号体系から新しい製品番号への移行を容易にするために、両方の体系が機能としてシステムに残されているとします。新製品には新しい番号しか付いていませんが、古い製品には古い番号も付いている可能性があります。機械学習アルゴリズムは、古い番号への依存を残していたとします。 1年後、誰かが善意でコードをクリーンアップして、古い数値でデータベースを埋めることをやめます。もう他の誰も古い番号を使用していないため、この変更は回帰テストでは検出されません。この日、機械学習システムの保守担当者にとっては良い一日にはならないでしょう。

負債を緩和するアプローチ

十分に活用されていない依存関係に対する一般的な緩和アプローチは、個々の機能を特定のモデルから削除する効果を定期的に評価し、可能な限りこの評価に基づいてモデルから削減することです。
より広く言えば、十分に活用されていない従属クリーンアップの長期的な利益に関する文化的意識を構築することが重要な場合があります。

##3.3データ依存の静的分析の難しさ
データ依存債務の重要な問題の1つは、静的分析を実行することの難しさです。コンパイラとビルドシステムは、通常、コードに対してこのような機能を提供しますが、データ依存性を追跡するには追加のツールが必要になることがあります。これがなければ、システム内のデータの使用を手動で追跡することが難しい場合があります。多くのエンジニアがいるチームでは、または複数の対話チームがある場合、すべての機能がすべての機能を把握しているわけではなく、個々の人間がその機能が使用された最後の場所をすべて知ることは困難です。

具体例

例えば、辞書のバージョンを変更する必要があるとします。大企業では、辞書のすべての利用者を見つけることさえ容易ではないかもしれません。あるいは、効率のために、特定の信号がもはや計算されないと仮定しよう。信号の以前の利用者はすべてそれで済んでいますか？コードベースの現在のバージョンで参照されていない場合でも、それを使用する古いバイナリを持つプロダクションインスタンスはありますか？自動ツールを使用しなければ、安全に変更することは困難です。

負債を緩和するアプローチ

　著しく有用な自動特徴量管理ツールが[6]で説明されており、データソースと特徴量に注釈を付けることができます。自動検査を実行して、すべての依存関係に適切な注釈が付いていることを確認し、依存関係ツリーを完全に解決することができます。このアプローチにより、Googleのチームは定期的に四半期ごとに何千もの機能関連コードを安全に削除し、バージョンやその他の問題を自動検証しています。システムは、多くの場合、新しいモデルで廃止予定または壊れた機能を誤って使用することを防ぎました。

3.4 修正の連鎖

　問題Aを解決するaは存在しているが、わずかに異なる問題A 'の解決策が必要な場合がある。 この場合、モデルaの出力を入力とし、小さな修正を学習するモデルa '（a）を学習することが魅力的です。これは、補正モデルが非常に小さく、しばしば完全に独立したチームによって実行される可能性があるため、高速かつ低コストでうまくいく可能性があります。また、最初のバージョンを簡単かつ迅速に作成できます。　しかし、この修正モデルはaにシステム依存関係を作成し、将来そのモデルの改善を分析するのに相当にコストがかかります。修正モデルが連鎖接続されている場合は、問題Aのモデルが「aの上で学習された」などのように、状況はさらに悪化します。これは、わずかに異なるテスト分布への出力の補正など、密接に関連する問題の場合にも簡単に発生します。

修正の連鎖が改善する状況を作り出すことは全くありません。
実際の精度はシステムレベルの障害につながります。さらに、このようなシステムはデッドロックを生成する可能性があり、結合されたMLシステムは局所的に最適ではなく、コンポーネントモデルを個別に改善することはできない。現時点では、最初は魅力的と思われた独立した開発が進展の大きな障害になっています。

負債を緩和するアプローチ

　緩和アプローチとしては、モデルがさまざまなユースケースを区別するのに役立つ変数を追加することによって、同じモデル内で修正を直接学習することです。これは無料の解決策ではなく、さまざまな関連問題の解決策はCACEを介して引き続き行われていますが、更新を行いその影響を評価する方が簡単かもしれません。

#4.システムレベルのスパゲッティ
残念なことに、機械学習方法を組み込んだシステムでは、高負債の設計パターンに終わることがよくあります。このセクションでは、機械学習システムに現れる可能性のある、回避またはリファクタリングすべきいくつかのシステム設計の反パターン[3]を検討する。
##4.1グルーコード

※グルーコードとは、コンピュータプログラミングにおいてプログラムの要求仕様の実現には一切寄与しないが、もともと互換性がない部分同士を結合するためだけに働くコードである。（Wikipedia）

　機械学習の研究者は、汎用ソリューションを自己完結型パッケージとして開発する傾向があります。mloss.orgや社内コード、独自のパッケージ、クラウドベースのプラットフォームなど、オープンソースパッケージとして幅広く利用できます。自己完結型ソリューションを使用すると、多くの場合、汎用コードとのデータのやりとりを行うために大量のサポートコードが書き込まれるグルーコードシステム設計パターンが発生します。

　このグルーコード設計パターンは、システムを特定のパッケージの特徴に固定する傾向があるため、長期的には高価になる可能性があります。 汎用ソリューションは、多くの問題を解決するために1つの学習システムを提供することを目指していますが、多くの実用的なソフトウェアシステムは、多くの実験的ソリューションが求められている1つの大規模問題に適用するように高度に設計されています。一般的なシステムでは、アルゴリズムを交換することが可能ですが、成熟したシステムにとって最も利益をもたらす、問題空間の構築をリファクタリングすることは非常に頻繁です。グルーコードパターンは、主として設計されたコンポーネントではなく、コードを暗黙的にサポートコードに埋め込みます。結果として、グルーコードパターンはしばしば、他の機械学習手法を実験的に高価にし、より良いものに革新することに継続的な税金を課すことになります。

負債を緩和するアプローチ

　グルーコードは、より広範なシステムアーキテクチャ内で特定のアルゴリズムを再実装することを選択することによって削減することができます。最初は、これは高い費用を支払うように思えるかもしれません。例えば、Rやmatlabですでに利用可能なC ++やJavaのマシンラーニングパッケージを実装することは、労力を浪費するようです。しかし、結果として得られるシステムでは、システム全体に統合するためのグルーコードの大幅な削減、テストの容易化、保守の容易化、および代替アプローチをプラグインして経験的にテストできるように設計する必要があります。問題固有の機械学習コードは、一般的なパッケージではサポートが困難な問題固有の知識で調整することもできます。
　学問界には、多くの機械学習システムで、実際に「機械学習」を行っているコードはほんの一部だと知っているのは驚く人もいるかもしれません。成熟したシステムが（最大で）5％の機械学習コードと（少なくとも）95％のグルーコードであることを認識すると、不器用なAPIの再利用ではなく再実装がはるかに優れた戦略に見えます。

##4.2パイプラインジャングル
　グルーコードの特殊なケースとして、パイプラインのジャングルがデータ準備の中に現れることがよくあります。新しいデータがが追加されると、これらは有機的に増加することがあります。これらを考慮しないML準拠のフォーマットでデータを扱うシステムは、しばしば結合、およびサンプリングステップごとに中間ファイルを出力するジャングルになることがあります。これらのパイプラインを管理し、エラーを検出し、障害から復旧することはすべて困難でコストがかかる[1]。このようなパイプラインをテストするには、しばしば高価なエンドツーエンドの統合テストが必要です。このすべてがシステムの技術的負債を増やし、さらなる革新をより高価にします。

負債を緩和するアプローチ

パイプラインのジャングルは、データ収集と特徴量作成を全体として考えることによってのみ避けることができます。パイプラインのジャングルを廃止し、地面から再設計するクリーンスレートアプローチ、これは実際にはエンジニアリングの努力の大きな投資ですが、継続的なコストを大幅に削減し、革新のスピードを上げることができます。

グルーコードとパイプラインのジャングルは、「研究者」と「エンジニア」の役割が過度に分離されている可能性がある症状として現れることがあります。機械学習パッケージが象牙の塔（※）で開発されると、実際にそれらを実際に使用するチームにとって、それはブラックボックスにに見えるかもしれません。 Googleでは、エンジニアと研究者が同じチームに組み込まれたハイブリッド研究アプローチ（実際には同じ人物であることが多い）は、この摩擦源を大幅に削減するのに役立っています[10]。それでも完全に統合されたチーム構造が不可能な場合は、緊密で積極的なコラボレーションを行うことが有益です。
※象牙の塔：芸術至上主義の人々が俗世間を離れて楽しむ静寂・孤高の境地。

##4.3死んだ実験コードパス
グルーコードまたはパイプラインジャングルに対する一般的な反応は、これらの実験的コードパスを主なコード内の条件分岐として実装することにより、アルゴリズムの比較や調整などの実験を行いやすいと言われています。個々の変更については、この方法で実験するコストは比較的低く、周囲のインフラストラクチャのどれも再加工する必要はありません。しかし、時間の経過とともに、これらの蓄積されたコードパスは、増加する負債を生み出す可能性があります。実験的なコードパスとの下位互換性を維持することは、より実質的な変更を行うための負担です。さらに、時代遅れの実験コードパスは予測できない方法で相互に作用し、どの組み合わせがすぐに互換性がないかを追跡することで、システムの複雑さが指数関数的に上昇します。ここでの危険の有名な例は、Knight Capitalのシステムが、時代遅れの実験的コードパスによる予期せぬ挙動のために45分で4億6,500万ドルを失うことでした[9]。

負債を緩和するアプローチ

　伝統的なソフトウェアのデッドフラグの場合[7]と同様に、各実験ブランチを定期的に再検査して何がリッピングできるかを確認することは有益です。可能なブランチのごく一部だけが実際に使用されます。一度テストして放棄した可能性があります。
死んだ実験的コードパスは、より根本的な問題の症状です。健全な機械学習システムでは、実験コードは複数のモジュールにうず巻を残さずに、十分に分離されている必要があります。これには、コードAPIの再考が必要な場合があります。私たちの経験では、実験したいものの種類は時間とともに変化します。効率的に前進するために、いくつかの部分の再設計および書き換えが周期的に必要とされることがあります。

　現実の逸話として、Googleの重要な機械学習システムの最近のクリーンアップ作業では、数万行の未使用の実験的コードパスを取り除くことが可能であることが判明しました。
より厳しいAPIを使用した後続のリライトにより、新しいアルゴリズムを使用した実験が可能になりました。劇的に削減された労力と生産リスクと最小限の増分システム複雑性で実行されます。
##4.4設定の負債
　債務が累積する可能性のあるもう1つの領域は、機械学習システムの構成です。任意の大規模システムには、どの機能が使用されているか、データの選択方法、さまざまなアルゴリズム固有の学習設定、潜在的な前処理または後処理、検証方法など、幅広い設定可能なオプションがあります。多くのエンジニアは、生産コードの抽象化と単体テストについて熟考していますが、後の考察として構成（および構成の拡張）を扱う可能性があります。実際、構成の検証やテストは重要ではないと見なされることさえあります。設定はその性質上、現実の厄介さが美しいアルゴリズムに侵入する場所になる傾向があります。

具体例

　次の例を考えてみましょう。変数Aは9月14日から9月17日に間違って記録されました。変数Bは10月7日より前のデータでは使用できません。ロギングフォーマットが変更されたため、変数Cを計算するために使用されるコードは11月1日の前後のデータに対して変更する必要があります。変数Dは本番では使用できないため、実際の設定でモデルにクエリを実行するときは、代わりのフィーチャD 'とD "を使用する必要があります。変数Zを使用する場合、ルックアップテーブルのためにトレーニング用のジョブに余分なメモリを割り当てる必要があります。そうしないと、非効率的にトレーニングが行われます。変数Qは、待ち時間制約のために変数Rの使用を排除する。

　この厄介さは、設定を正しく修正するのが難しく、推論が難しくなります。しかし、構成ミスはコストがかかり、時間の大幅な損失、コンピューティングリソースの浪費、または生産上の問題につながります。

負債を緩和するアプローチ

　また、積極的に開発されている成熟したシステムでは、構成行の数は、実際に機械学習を行うコードの行数をはるかに超える可能性があります。各ラインは間違いの可能性があり、設定はその本来の性質から、あまりうまくテストされていません。
構成不変量に関する表明はミスを防ぐために重要ですが、どのような表明が役立つかについては注意深い考えが必要です。
もう1つの有用なツールは、2つの構成の視覚的な並列の差異（差分）を提示する機能です。設定には小さな変更を加えてコピーアンドペーストすることが多いため、このような差異は重要な変更を強調します。設定の変更はコード変更と同じレベルの深刻さで扱われるべきであり、慎重にコードを変更し、仲間動詞で慎重にコードレビューされるべきです。

#5.外部データの変更を扱う

　機械学習システムが持っている魅力のひとつに、外部データと直接対話して結果を返すことがあります。私の経験から、外部データはめったに安定していないと言えます。実際、外部データの変化する性質は、機械学習システムにおける技術的負債の源泉の1つです。

##5.1 動的システムにおける固定値
　いくつかのアクションを実行するために、特定のモデルでしきい値などの固定値を選択する必要があります。真偽を予測したり、電子メールを迷惑メールとしてマークしたり、機械学習の古典的なアプローチとして、精度やリコールなどの特定の評価値で適当なトレードオフを得るために、可能なしきい値のセットからしきい値を選択することです。しかしながら、このようなしきい値は手動で設定されることが多い。したがって、モデルが新しいデータを更新する場合、古い手動で設定されたしきい値は正しくない可能性があります。多くのモデルで多数のしきい値を手動で更新するのは時間がかかり、脆弱です。この種の問題のための有用な緩和アプローチは、[8]に示されており、しきい値は、検証データに対する単純な評価によって学習されます。

##5.2 相関がもはや相関しなくなったとき
　機械学習システムは、多くの場合、相関した特徴量の影響を区別するのが困難な場合があります。これは重大な問題のようには見えないかもしれません。2つの特徴が常に相関しているが、ただ1つのみが実際に因果関係である場合、両者に信用を帰し、それらの観察された共起に依拠することは可能でしょう。しかし、外部データにおいて突然相関が無くなった場合、予測動作が大幅に変化する可能性があります。相関効果を分離するML戦略の全範囲は、私たちの範囲外です。いくつかの優れた提案と参考文献が[2]で与えられている。本稿の目的上、非因果関係は隠れた負債のもう一つの原因であることに留意する。

##5.3 監視とテスト
　重要な問題は、何を監視するかです。機械学習システムの目的が時間の経過とともに適応することを前提とすると、有用な不変量を確立することは困難です。 2つの合理的な出発点を提供しています。

アプローチ１：予測バイアス

意図したとおりに動作しているシステムでは、予測ラベルの分布が観測ラベルの分布と等しいはずです。これは、包括的なテストではありません。入力特徴量に関係なくラベル発生の平均値を単純に予測するヌルモデルが満たすことができるため、包括的なテストではありません。しかし、それは驚くほど有用な診断であり、このような指標の変化は、しばしば注意を必要とする問題点を示してくれる。この方法は、外部データのふるまいが突然変化するケースを検出するのに役立ち、過去のデータから作成されたトレーニング分布は現在の現実を反映しなくなることを示します。さまざまな次元による予測バイアスのスライスは、問題を迅速に分離し、自動アラートにも使用できます。

アプローチ2：　アクション制限

現実世界で行動を起こすために使用されるシステムでは、サニティチェックとしてアクション制限を設定し、実施することが有用な場合があります。これらの制限は、不具合が発動しないように十分に広くなければなりません。システムが特定のアクションの制限に達すると、自動アラートが発生し、手動による介入または調査が開始されます。

#6.結論
本稿では、機械学習システムが技術的な負債を創り出すことができる項目を、驚くほど多くの点で示しています。これは、機械学習が悪いと言うわけではなく、全ての技術的な負債を無くすべきものであるということでもありません。短期間ですばやく動く利点のために中程度の技術的負債を取ることは合理的かもしれませんが、迅速に管理不能にならないようにこれを認識し、説明しなければなりません。おそらく最も重要な洞察は、技術的負債はエンジニアと研究者の両方が認識しなければならない問題であるということです。システムの複雑さの大幅な増加を犠牲にして、わずかな正確さの利点を提供する研究ソリューションはめったに賢明ではありません。 1つまたは2つの一見無害なデータ依存性の追加さえも、さらなる進展を遅らせる可能性がある。
　技術的負債の払い戻しは、新しい定理を証明するほどエキサイティングではありませんが、一貫して強力な革新のための重要な作業です。複雑な機械学習システムのための包括的で洗練されたソリューションを開発することは、非常に有益な作業です。

　（謝辞）本稿では、革新的なML研究と強力なエンジニアリング実践の両方を重視する文化の中で日常的に学んだ重要な教訓を多く借りています。多くの同僚がここで私たちの思考を形作るのを助け、蓄積された人類の知恵の恩恵を誇張することはできません。 Luis Cobo、Sharat Chikkerur、Jean-Francois Crespo、Jeff Dean、Dan Dennison、Philip Henderson、Arnar Mar Hrafnkelsson、Ankur Jain、Joe Kovac、Jeremy Kubica、H. Brendan McMahan、Satyaki Mahalanabis、 Lan Nie、Michael Pohl、Abdul Salem、Sajid Siddiqi、Ricky Shan、Alan Skelly、Cory Williams、and Andrew Youngが含まれます。

リファレンス

[1] R. Ananthanarayanan, V. Basker, S. Das, A. Gupta, H. Jiang, T. Qiu, A. Reznichenko,
D. Ryabkov, M. Singh, and S. Venkataraman. Photon: Fault-tolerant and scalable joining of
continuous data streams. In SIGMOD ’13: Proceedings of the 2013 international conference
on Management of data, pages 577–588, New York, NY, USA, 2013.
[2] L. Bottou, J. Peters, J. Qui˜nonero Candela, D. X. Charles, D. M. Chickering, E. Portugaly,
D. Ray, P. Simard, and E. Snelson. Counterfactual reasoning and learning systems: The example
of computational advertising. Journal of Machine Learning Research, 14(Nov), 2013.
[3] W. J. Brown, H. W. McCormick, T. J. Mowbray, and R. C. Malveau. Antipatterns: refactoring
software, architectures, and projects in crisis. 1998.
[4] M. Fowler. Refactoring: improving the design of existing code. Pearson Education India, 1999.
[5] A. Lavoie, M. E. Otey, N. Ratliff, and D. Sculley. History dependent domain adaptation. In
Domain Adaptation Workshop at NIPS ’11, 2011.
[6] H. B. McMahan, G. Holt, D. Sculley, M. Young, D. Ebner, J. Grady, L. Nie, T. Phillips,
E. Davydov, D. Golovin, S. Chikkerur, D. Liu, M.Wattenberg, A. M. Hrafnkelsson, T. Boulos,
and J. Kubica. Ad click prediction: a view from the trenches. In The 19th ACM SIGKDD
International Conference on Knowledge Discovery and Data Mining, KDD 2013, Chicago, IL,
USA, August 11-14, 2013, 2013.
[7] J. D.Morgenthaler, M. Gridnev, R. Sauciuc, and S. Bhansali. Searching for build debt: Experiences
managing technical debt at google. In Proceedings of the Third International Workshop
on Managing Technical Debt, 2012.
[8] D. Sculley, M. E. Otey, M. Pohl, B. Spitznagel, J. Hainsworth, and Y. Zhou. Detecting adversarial
advertisements in the wild. In Proceedings of the 17th ACM SIGKDD International
Conference on Knowledge Discovery and Data Mining, San Diego, CA, USA, August 21-24,
2011, 2011.
[9] Securities and E. Commission. SEC Charges Knight Capital With Violations of Market Access
Rule, 2013.
[10] A. Spector, P. Norvig, and S. Petrov. Google’s hybrid approach to research. Communications
of the ACM, 55 Issue 7, 2012.