2015年の始めにCondé Nast(訳注:ファッション誌を中心とする多国籍出版企業)は、自社の22ブランドにわたって作成されたコンテンツに関わるメタデータ改善を目的として、自然言語処理およびコンテンツ分析のエンジンを開発した。新システムによって、クリック率が30％向上したという。Condé Nast USでテクノロジマネージャを務めるソフトウェアエンジニアのAntonio Rau氏は先頃、このプロジェクトの背景となった動機、システムのアーキテクチャ、HALと命名されたNLP・アズ・ア・サービスの進化について、2部形式のブログ記事"Natural Language Processing and Content Analysis at Condé Nast"で公開した。この記事によると、システムの目標は、それまでの単純な分類やタグ付けを、"世界レベルの編集者が入力した知識を自動的に'リバース・エンジニアリング'"可能なシステムで置き換えることにあった。
映画2001: A Space OdysseyのHAL-9000にちなんで名付けられたHALは、Copilotと呼ばれる同社独自のコンテンツ管理システム(CMS)と統合されている。Javaで構築されたHALは、JVM上およびJVM外の両方で、事前トレーニングないしカスタムトレーニングされたモデルを使用して、一連の分析を実行する。
HALの処理エンジンは並列化可能な直接循環グラフ上に構築されており、コンテンツ分析とアノテーションを実行する。これによって、コンテンツのさまざまな側面が分析され，特徴の抽出が行われる。例えば、コンテンツ分析によって既知の人物を抽出し、応答として、その個人に関わるリソースへのリンクを注釈として付けることができる。その他の機能には、トピックとカテゴリ、あるいはロケーションとニュース記事といったものがあり、いずれも付加的な関連情報としてアノテーションされる。
分析の結果はUberのMichelangeloにヒントを得た方法でキュレート(curate)され、トレーニングモデルの改善に用いられる他、不活性なままのコンテンツに対してHALを繰り返し呼び出すためにも使用される。
InfoQはRau氏にコンタクトを取り、HALの開発について話を聞いた。
InfoQ: ブログ記事には、"数年前、2015年に、次のレベルへと踏み出す決意をした"、とありますが、方法論を変えようと考えた理由は何ですか？それまでは、編集者が手作業で自身の記事にタグ付けしていたのですよね？
Antonino Rau: 主な動機は、さまざまなユースケースで編集者が作り上げていたもの対して、(トピックやエンティティなどを)自動理解を可能にすることでした。このようなコンテンツインテリジェンスは、セグメントやレコメンデーションなどのフィーチャを構築する上で、ユーザ行動と交点を持つことになります。確かにこれまでは、編集者が手作業でタグ付けしていました。現在でも、自動タグを削除したり、管理用語から手作業でタグ付けしたりする場合もあります。
InfoQ: HALでは、自然言語処理システムを独自開発する方法を選択しましたが，サードパーティは選択肢としてなかったのでしょうか？あったとすれば，なぜ自社開発を選んだのでしょう？
Rau: そうですね，当時はサードパーティも検討したのですが，独自開発とオープンソースを併用することに決めました。当初、HALが必要なのは英語のみだったので，トレーニング済みのモデルがオープンソースでたくさんありました。ですから私たちとしては，OSSモデルのサポートしていない機能を、ひとつの言語だけでサポートするカスタムモデルを構築すればよく，非常に簡単だったのです。最近になって，2018年11月にCondéは，Condé Nast USとCondé Nast Internationalを世界的なプラットフォームで統合する決定をしました。そのため，新たに8つの言語をサポートすることが必要になったのです。現在では，世界中のCondéのマーケットにおいて，すべての言語でHALを利用可能にする作業をスピードアップするために，サードパーティモデルをHALに統合する調査をしています。HALのよいところは，それが改変防止層としても機能することです。複数のベンダを統合しても，そのフレームワークのおかげで，OSS，カスタム，ベンダの各モデルやアナライザが混在しても運用が容易な上に，共通的に抽象化および標準化されたアウトプットを得ることができるのです。
InfoQ: Javaを選択したのはなぜですか？
Rau: NLPモデルの運用は，CPUとメモリを大量に消費する、というのが理由のひとつです。もうひとつは，当社のベンチマークの結果として，機能とパフォーマンスの面で最高であったOSSモデルがJavaで利用可能なものだったからです。そして最後に，CPUおよびメモリ集中型のアプリに対する堅牢性という観点から，最良の選択だと考えたからでもあります。
InfoQ: HALの設計，特に直接巡回グラフは，抽象化による汎用性の実現という面で印象的なものですが，このアプローチに決定するまでには，多くのイテレーションがあったのでしょうか？他に検討したアプローチはありますか？
Rau: 最初はアノテーションモデルを使用した，直接的な"パイプとフィルタ"によるアプローチでした。ブログ記事でも述べたように，文献の上ではごく一般的なものです。しかし後になって，JVM外のアナライザの使用を増やせば，アノテーションを相互に渡すアナライザのグラフの構築が可能になり，処理の高速化と並列化が実現できる、ということに気付いたのです。
InfoQ: 社外で使用するために。オープンソースとして開発したものはありますか？
Rau: 現時点ではありません。将来的には開発したいですね。
InfoQ: Copilotという社内CMSの利用についての話がありましたが，CMSが独自開発であることはHALを開発する上で役に立ったのでしょうか，あるいは、他のCMSでも可能だったと思いますか？
Rau: Copilotには、Formation PlatformというAPIセットが背景にあります。自動エンリッチメントはコンテンツタイプとコンテンツモデルの一部としてAPIを使って実現されるものである、という意識から，HALのあるべき場所はパイプラインの内部である、と考えていました。しかしながら、その逆も真であって，HALのコンポーネントのひとつであり，Entity-linkerのインスタンスであるCopilot-linkerがレストランや人々、あるいは会場といったCopilotのコンテントタイプを毎日抽出する作業を通じて、編集者はシステムに入力すべき知識を学ぶのです。従って、こういったエンティティを記事から自動的に抽出し、提案するという作業は、その両方に関連しています。つまり、Condé Nastを含む出版社一般のコンテキストにおいて、コンテント分析とNLPは、CMSと極めて相乗的であると言えるのです。CMSがプロプライエタリであれば、それを内部フローの一部にするのは簡単ですから、下流におけるこのエンリッチメントでの利用を合理化するのも難しくありません。ただし、OSS CMSであっても適切な場所に利用可能な拡張ポイントがあれば可能だ、という意見があるかも知れません。
InfoQ: HALを通過するデータ量はどの程度ですか？
Rau: 1ヶ月で約3,000万リクエストです。変更されたテキストの全リビジョンの他、Condéからではないコンテンツを処理する場合もあります。
InfoQ: クリックスルー率以外にはどのような指標を測定しましたか、その指標に対して、HALによる改善はあったのでしょうか？
Rau: HAL Topics FeatureはData Scienceチームの予測モデルの中でもっとも予測的な機能で、オーディエンスターゲティングと消費者購読傾向の両方で使用されています。