|
何かを達成するのは簡単ではありませんし、落とし穴は常に存在します。 5月10日に江門ベンチャーが主催したオンライン講演で、包潔博士は人工知能プロジェクトにおける大小の落とし穴を検討し、非常に直感に反すると思われる10の典型的な落とし穴を選びました。 これは正直な真実の集まりですが、ご安心ください。最後には、20年間の試行錯誤から得た洞察をいくつかお見せします。お互いに学び合いましょう。 著者紹介 宝潔博士は、WenYin InteractiveのCEOです。学界と産業界で20年の経験を有し、アイオワ州立大学で人工知能の博士号を取得し、RPIでポスドク研究を修了しました。MITの客員研究員、W3C OWL（Web Ontology Language）ワーキンググループのメンバー、サムスンの米国R＆Dセンターの研究員、そしてサムスンの第2世代質問応答システムSVoiceの中核設計者を務めました。主な研究分野は、機械学習、ニューラルネットワーク、データマイニング、自然言語処理、形式推論、セマンティックウェブ、オントロジーエンジニアリングなど、人工知能の多くの分野を網羅しており、関連分野で70本以上の論文を発表しています。中国情報処理学会言語・知識コンピューティング委員会の委員、中国コンピュータ連盟誌の編集委員、W3C諮問委員会の代表を務めています。 2010 年以降、金融インテリジェンスの研究と応用に注力し、XBRL セマンティック モデル、ナレッジ グラフに基づくファンダメンタル分析、金融質問応答エンジン、財務レポートの自動抽出、自動監視などの成果を上げています。 以下はスピーチの原文です。 鮑傑博士：今日のテーマは「AIプロジェクトを確実に失敗させる10の方法」です。この10の方法に従えば、プロジェクトは確実に失敗しますよ。（笑） 私がこのトピックについて議論できるのは、私自身が多くのプロジェクトを失敗してきたからです。以下のリストにあるプロジェクトの半分以上は、最終的に失敗しました。 私は疑問に思い始めました。なぜほとんどのプロジェクトは最終的に失敗するのだろうか？ ポスドク研究員として初めてRPI（レンスター工科大学）に着任した時など、非常に辛い時期を何度も経験しました。この大学にはアメリカで最高のナレッジグラフ研究室があり、研究室のジェームズ・ヘンドラー氏とデボラ・マクギネス氏はこの分野で最高の教師です。 そこで私は知識管理システムを開発しました。私の考えでは、私たちは世界最高のセマンティックウェブ研究室であり、最もプロフェッショナルな集団でした。この技術を武器にしないのは不合理に思えたので、セマンティック検索システムを開発しましたが、その後誰も使いませんでした。 何が問題なのか考えていました。なぜこの分野の最高の専門家たちがこのようなシステムを作りながら、自分たち自身も使わないのでしょうか？ 人工知能プロジェクトが失敗する根本的な理由は何なのか、私はずっと考え続けています。 もちろん、その後も多くの失敗を経験しました。これらの直接的、間接的な失敗を踏まえ、プロジェクトが失敗する理由を徐々に整理してきました。これらの理由は直感に反するように見えることが多いですが、一つずつ説明していきます。 最後に、これら 10 の落とし穴を避けるために何をすべきかをまとめます。 NO.1 一度にたくさんのお金を使うプロジェクトを確実に失敗させる最初の方法は、一度に多額の資金を投入することです。 私は現在、自分のビジネスを立ち上げているところですが、何人かのVCから「もしBAT（百度、アリババ、テンセント）があなたの事業に多額の資金を投資したら、彼らは一気に追いつくことができるでしょうか？」と聞かれました。 私は「いいえ」と言いました。私がいつも例に挙げるのは、日本の第5世代戦闘機です。日本は国の資源を全て投入し、数百億円を費やしましたが、結局完成には至りませんでした。 第五世代コンピュータとは何でしょうか？1970年代後半は、人工知能（AI）における最初の「冬」からの回復の始まりでした。1980年代には、AI開発における第二のピークが到来しました。この頃、日本は第五世代コンピュータと呼ばれる新たなプロジェクトを立ち上げました。 第5世代コンピュータとは何でしょうか？最初の4世代のコンピュータは、真空管、トランジスタ、集積回路、大規模集積回路でした。日本が第5世代コンピュータに到達したとき、人工知能を開発するには、独自の人工知能用ハードウェアが必要だと考えられました。 （「知識情報処理システムの課題：第5世代コンピュータシステムに関する予備的報告書」より引用） 聞き覚えがありますか？最近、ディープラーニングに取り組んでいる中で、ディープラーニングチップに関する様々なアイデアに出会いました。このアイデアは新しいものではありません。30年前、日本は既に第5世代戦闘機のコンピューティングにおいて同様のコンセプトを採用していました。しかし、当時のAIチップは、今日のディープラーニングチップではなく、Prologチップでした。 Prologは人工知能のための言語であり、主に論理モデリング言語です。Prologを用いてコンピュータを設計できれば、コンピュータは思考し、様々な認知タスクを処理できるようになります。これは数百億円の費用と10年の歳月を費やした、国家規模の大規模プロジェクトでしたが、1992年についに頓挫しました。 これは特別なケースではなく、多くの大規模プロジェクトが最終的に失敗しています。 当初多額の投資をしたにもかかわらず、なぜ失敗したのでしょうか？すべてのプロジェクトには目標があることを理解する必要があります。予算が潤沢であれば、目標は通常非常に高く設定されます。例えば、第5世代ジェット戦闘機の開発という目標は、当時達成不可能だっただけでなく、30年経った今でも達成不可能なままです。 第五世代戦闘機プロジェクトは失敗に終わったものの、その開発過程で日本の人工知能技術は大きく向上しました。そのため、20年後、セマンティックウェブが登場した時も、日本のセマンティックウェブ研究レベルは依然として非常に高く、投入された資金は無駄にならず、多くの人材を育成しました。 日本が第五世代戦闘機を開発していた頃、アメリカも同様の研究を行っており、主にLISPマシンに焦点を当てていました。LISPは人工知能用の言語であり、論理モデリング用の言語でもあります。研究に参加していた企業の一つがThinkMachineでした。当時、LISP関連の企業は少なくとも100社ありました。 なぜThink Machineを別に取り上げるのでしょうか？Think Machineの失敗後、創業者はしばらく隠遁生活を送り、2005年にMetaWebという新しい会社を設立しました。この会社は、Wikipediaを使って優れたナレッジベースを作成するFreebaseという製品を提供しています。 2010年にこの会社はGoogleに買収され、Google Knowledge Graphに改名されました。そのため、今日のGoogle Knowledge Graphには多くの歴史的な起源があり、その起源は30年前のLISPマシンの研究にまで遡ることができます。 ローマは一日にして成らず、一度に多額の資金をプロジェクトに投入すると、過度に野心的な目標につながり、失敗する可能性が大幅に高まります。 かつて、ある大手国有企業の担当者にお会いしたことがあります。彼は社内ナレッジマネジメントシステムの構築に3000万元を費やす予定だと言っていました。「どうやって3000万元を捻出したのですか？」と尋ねると、彼は「初年度に3000万元を投資します」と答えました。私は何も言いませんでした。このプロジェクトは失敗するだろうと思ったからです。そして実際、失敗に終わりました。 一部の大企業は、AIプロジェクトにこれよりもはるかに多くの資金を投資しています。しかし、必ずしも成功が容易になるわけではありません。 これは最初の方法で、一度に多額の資金を投資することになります。 NO.2 最新の研究論文に基づいて技術的なルートを決定します。2 番目の方法は、最新の論文に基づいて技術的なルートを決定することですが、これも直感に反する可能性があります。 最新の技術が必ずしも最高の技術とは限らないからです。工学では、問題は通常、実用的な制約の中で解決されることに注意することが重要です。一方、研究論文は実験室環境で書かれるため、この点は異なります。 例えば、実験室環境では、ある程度のデータがあり、そのデータは統合され、クレンジングされ、ノイズが除去されていると仮定できます。目標は明確であると仮定できますが、これらの仮定は必ずしも現実には当てはまりません。 最も良い例は情報抽出です。これは2013年にEMNLPに掲載された論文から抜粋した図です。 この図は、NLP 研究論文で使用される技術的アプローチと実際の産業システムの違いを示しています。 2003年から2012年までの10年間、学術界で発表された自然言語処理のエンティティ抽出分野において、機械学習を用いた論文が75%、機械学習とルールベース手法のハイブリッドを用いた論文が21%、ルールベース手法のみを用いた論文はわずか1%強と、非常に低い割合でした。しかし、実際の産業応用を見ると、全く異なる技術分布が見られ、ルールベース手法が45%を占めていました。 IBMなどの大手ベンダーに限って見ると、そのソフトウェアの67%は完全にルールベースの手法に基づいています。統計的手法、つまり機械学習手法のみに基づくソフトウェアは、全ベンダー全体で33%を占めていますが、大手ベンダーではわずか17%です。 そのため、学術研究と産業界の実践には大きな違いがあります。なぜこのような違いがあるのでしょうか？先ほど述べたように、論文を発表する際には、現実に直面する制約を考慮する必要はありません。知識抽出やエンティティ抽出の分野では、エンティティ認識、自然言語処理、単語分割といった問題は理論的には解決されているものの、これらの手法は現実世界のコーパスでは効果がないことが証明されています。これは、質問応答システムという別の例でも証明できます。 今日、質問応答システムに関する発表論文のほとんどが統計的手法に基づいていることに気づきました。正確な統計は行っておらず、漠然とした定性的な観察に過ぎませんが。これは特に、過去2年間のNLPベースの手法、特にエンドツーエンドのアプローチにおいて顕著です。Xiaoiceのようなチャットボットを除けば、実際に産業界で応用できる質問応答システムは、例外なく、現実世界の問題を解決するために設計されたルールベースのシステムです。どれがディープラーニングを使用しているかは分かりません。もちろん、特定の部分やコンポーネントでディープラーニングが使用されている可能性はありますが、アーキテクチャ全体でディープラーニングが使用されているのを見たことがありません。 したがって、工学的問題に対する技術的アプローチを決定する際に、最新の研究動向を追う必要はありません。実際、論文の中には10年後の技術とは関連性がないものもあるかもしれません。技術的アプローチは、現実世界の状況とその制約に基づいて決定する必要があります。 NO.3 現実世界のアプリケーションシナリオから切り離されている3 番目のアプローチ:プロジェクトが実際のアプリケーション シナリオから切り離されている場合、そのプロジェクトは失敗する運命にあります。 この説明ではOWL2を使います。OWL2はセマンティックWebに携わる人にとって馴染みのある言語です。 HTMLなど、Web上で私たちが知っているすべての標準化されたフォーマットは、W3C（ワールド・ワイド・ウェブ・コンソーシアム）によって設計されました。W3CはWeb上の他のプロトコルも策定しており、その一つがOWLです。OWLは、インターネット上で私たちの知識をどのように表現すべきかを定義しています。 例えば、レストランはメニューを公開する際にどのようなフォーマットを使用すべきでしょうか？あるいは、履歴書をオンラインで公開し、Googleで検索しやすくしたい場合、Googleに自分が人間であること、姓、名、生年月日、そしてこれらのデータを公開する際にどのようなフォーマットを使用すべきかを伝える必要があります。そのようなフォーマットの一つがOWLです。OWLの最初のバージョンは2004年にリリースされ、第2バージョンは2010年にリリースされました。 OWLワーキンググループの中でも特に活発なワーキンググループには、著名な大学の教授陣や、IBM、Oracle、HPといった有名企業の科学者が多数参加しています。これらの大企業について言及した際に、GoogleやFacebookといった企業名が抜けていたことにお気づきかもしれません。 OWL2は当初、衣食住交通といった日常生活に関する情報をオンラインで表現・公開する方法を設計することを目的としていました。しかし、最終的なワーキンググループは大学の研究者と大企業のエンタープライズアプリケーション開発者で構成されており、そのほとんどは現実世界のシナリオとはかけ離れていました。 最終的に設計された製品であるOWL2言語は、本来想定されていたシナリオとは大きく異なっていました。OWLワーキンググループは会議中に数十の応用事例を作成しましたが、そのほとんどは、製薬会社が新薬開発において製薬知識をどのように表現すべきか、医師が医療記録、疾患、遺伝子をどのように表現すべきかといった、ほぼ同じ内容でした。オンラインで友人を見つける方法、友人とチャットする方法、食べ物を注文する方法を説明した事例は一つもなく、日常生活に即した例はありませんでした。 OWL2の最終版は600ページに及び、非常に複雑な言語でした。実際には、限られた数のエンタープライズレベルのアプリケーションでのみ使用され、実世界の日常的な使用における成功した実装は事実上存在しませんでした。これは、想定されたアプリケーションシナリオから乖離したプロジェクトの典型的な例です。そのため、多額の資金を投入したにもかかわらず、プロジェクトは最終的に真の目標を達成できませんでした。 NO.4 過度に高度なアーキテクチャの使用4 番目のアプローチは、過度に高度なアーキテクチャを使用することです。 これは前述の2番目のアプローチと共通しており、最新の研究論文に基づいて技術を選択すべきではないと主張しています。4番目のアプローチは、特に高度なアーキテクチャを使用すると、実際にはプロジェクトの失敗につながる可能性があると主張しています。 Twineは2007年、世界初の大規模セマンティックウェブアプリケーションとして称賛されました。当時はスター企業でしたが、2010年に閉鎖されました。なぜでしょうか？Twine設立当初のアイデアは、セマンティックブックマークアプリケーションを作ることでした。例えば、興味深い記事を読んだら、後で読むために保存します。Twineのロボットが保存された記事の内容を分析し、セマンティックタグを割り当てます。誰かが私のタグを購読すれば、そのタグの下に保存した興味深い記事を継続的に見ることができる、というのが基本的なアイデアでした。 Twineは、RDFと呼ばれる新しいデータベースをコアに採用していました。RDFはセマンティックWeb言語であり、リレーショナルデータベースよりもはるかに強力で、推論機能を備えたデータベースです。しかし、Twineのユーザー数が200万人に達したとき、データベースのパフォーマンスが不十分であるというボトルネックが発生しました。そこで、TwineのCEOは新しいデータベースの開発を決定しました。 当時、同社は約40名の従業員を抱え、そのうち20名が基盤コンポーネント、つまり新しいセマンティックデータベースの開発に携わっていました。2008年、事業は順調に進んでいました。彼らは自分たちの仕事が優れていることに気づき、ふと疑問に思いました。なぜブックマークだけを検索しているのだろう？Web全体を検索できるのに、と。そこで彼らは方向転換し、Web全体を対象とするセマンティック検索の開発を目指しました。しかし、この行き過ぎた動きが最終的に会社を破綻させました。2008年の金融危機が襲い、キャッシュフローが枯渇し、わずか1年で倒産に追い込まれました。 TwineのCEO、ノヴァ・スピバック氏は、この分野で非常に尊敬される先駆者であり、技術の達人であり、非常に成功した投資家でもありましたが、亡くなる際にTwineの失敗を振り返り、次のように述べています。「私はあまりにも多くの分野で革新を試みてしまいました。プラットフォーム、アプリケーション、あるいはビジネスモデルを革新すべきだったのに、あまりにも多くの分野で革新を試みてしまったようです。さらに、RDFデータベースという非常に先進的なアーキテクチャを採用したため、目標があまりにも野心的になり、達成できませんでした。」 彼の言ったことは今日でも非常に考えさせられるものだと思います。 このプロジェクトに関する分析記事を2年ごとにじっくりと読んでいます。Twineが破綻した後、Nova SpivackはTwineを改革し、Bottlenoseという新会社を設立しました。彼らは同じ技術を使いながらも、より焦点を絞ったアプリケーションシナリオに適用し、2Cサービスから2Bサービスへと移行しました。 創業8年のボトルノーズは、大きな成功を収めています。B2Bアプリケーションはそれほど大量のデータを必要とせず、システムのスケーラビリティ問題に対処する必要もありません。そのため、このシステムの中核的な強みであるセマンティック分析と理解能力が際立っています。 Twineのような失敗は珍しくありません。過度に高度なアーキテクチャを使用すると、最初から予測することが難しいリスクが生じることが多く、これはRDFデータベースのようなニッチな製品だけでなく、より主流の製品にも当てはまります。 例えば、ナレッジグラフアプリケーションを開発する際にグラフデータベースを使う必要があるかどうかをよく聞かれます。私はたいてい、必ずしもそうではないと答えます。 たとえば、グラフ データベースに精通していて、Neo4j の全体的な操作とメンテナンスに精通していて、Java 仮想マシンでエラーが発生した場合の対処方法、メモリ不足になった場合の対処方法、データ シャーディングの実行方法、マスター スレーブ レプリケーションの実行方法などを知っていれば、これらの操作とメンテナンスの問題をすべて理解していれば、このアプリケーションの実装に挑戦することができます。 アプリケーションのデプロイは焦ってはいけません。オンラインアプリケーションだけであれば、とりあえず保留にして、オフラインでのメンテナンス作業を先に決めてから本番稼働させるのも良いでしょう。あるいは、まずは小規模なデータセットで試してみるのも良いでしょう。つまり、あまり大きなステップを踏み出さないということです。 NO.5 ユーザーの期待を管理できない5 番目の方法では、ユーザーの期待を管理できません。 これはプロジェクトが失敗する非常に一般的な理由ですが、技術的に不可能という理由だけでなく、ユーザーの期待値が高いことが原因です。 まず、技術的に不可能なことから始めましょう。例えば、ある銀行は、いわゆる「ロボット・ロビー・マネージャー」を導入しました。これは、ロボットに話しかけて業務を遂行できるサービスです。もちろん、もしこれが実際に可能であれば、現在の技術の限界をはるかに超える、非常に驚くべきものになるでしょう。 最近よく知られている詐欺事件の一つに、ロボット「ソフィア」が関係しています。サウジアラビアはソフィアに初の市民権を与えましたが、これは詐欺の典型的な例です。 このタイプのロボットは登場しそうにありません。 この状況は他のアプリケーションでも発生し、特にチャットボットではユーザーのチューリングテスト欲求を最も刺激しやすいです。ユーザーはロボットと会話していることに気づくと、ロボットをからかおうとします。例えば、多くの人がSiriをからかうので、Siriは皆のからかいに対処するためのジョークを数多く蓄積しています。 検索エンジンを提供する場合、人々の期待は比較的低くなります。しかし、同じコンテンツをQ&Aエンジンとして提供する場合、人々の期待ははるかに高くなります。 当初は端末レベルの製品を提供していましたが、ユーザーからのフィードバックはそれほど芳しくありませんでした。その後、ポジショニングを調整し、検索インターフェースを介したサービス提供へと移行しました。システム全体のインテリジェンスはほとんど変わっていませんでしたが、ユーザーの期待値が低下したため、期待とフィードバックはすぐに向上しました。このセマンティック検索エンジンは、他の検索エンジンよりも優れています。 チャットボットにも同じことが当てはまります。ユーザーと対等に会話できるロボットを期待すると、通常は実現が困難です。ユーザーはしばらく使ってみて、面白くないと感じ、すぐに使わなくなってしまうことがよくあります。だからこそ、GoogleのチャットボットとAppleのSiriの位置づけには大きな違いがあるのです。Googleのチャットボットは単に会話をするだけではありません。ユーザーに代わって事前に行動を起こしたり、タスクをプロアクティブに自動化したりすることも可能です。これは実に賢明な選択と言えるでしょう。 現在、人間と長期的なインタラクションが可能なロボットは、秘書のような存在、あるいは単にタスクを自動化する機械に過ぎません。対話に重点を置くとユーザーの期待に応えることは困難ですが、自動化に重点を置けば、期待に応えることははるかに容易になります。同じ技術であっても、ユーザーへのサービス提供方法が異なると、ユーザーの期待に応じて全く異なるユーザーエクスペリエンスが生まれます。したがって、ユーザーが製品の成熟度を認識できるようにすることが重要です。ユーザーの期待を超えた場合にのみ、製品は成功し、購入意欲を獲得できるのです。 NO.6 認知の複雑さに対する理解の欠如6 番目のポイントは、認知の複雑さを理解できないことです。 冒頭でも触れましたが、その一例としてセマンティックWikiが挙げられます。私はこれまでにもこのようなシステムについて多くの記事を書いてきました。セマンティックWikiとは何でしょうか？おそらく皆さんはWikipediaやBaidu Baikeを使ったことがあるでしょう。これらは、多くの人がページに貢献する典型的なWikiシステムです。セマンティックWikiもまたコラボレーションに基づいています。Wikiであることに変わりはありませんが、このWikiページにはタグやコメントを追加できます。 どんな問題を解決できるのでしょうか？例えば、ページ間でのワンタイムデータ転送の問題を解決できます。あるページから別のページにデータを流すことができます。例えば、Wikipedia では多くの国の GDP (国内総生産) を見ることができます。中国のページには中国の GDP が表示され、アジア諸国の GDP 一覧にも中国の GDP が表示され、世界のすべての国の GDP 一覧にも中国の GDP が表示されます。例えば、あるページに中国の GDP を書き込んだ場合、その数字が変わるとすぐに他のすべてのページの数字が同期して更新されるようなメカニズムは存在するでしょうか？Semantic Wiki テクノロジーはこれを実現します。もちろん、Semantic Wiki は他にも多くのクールで強力な機能を実現できます。 2004年にセマンティックWikiシステムの開発を始め、合計3つのセマンティックWikiシステムを開発しました。その後、Semantic MediaWikiというオープンソースコミュニティに参加し、このシステムをベースに、非常に優れたナレッジマネジメントシステムを構築しました。 2010年、私たちはこのシステムの普及に取り組みました。当時、米国の国家機関からの委託を受け、この協働型知識管理システムが、後で機械が自動処理できるほど十分にイベントを記録できるかどうかを検証する実験を行いました。 比較実験では、RPIのコンピュータサイエンス学部の学生グループを募集しました。彼らはテレビシリーズを視聴し、そのあらすじを説明するよう指示されました。一部の学生は自然言語を使用し、他の学生はより構造化された説明のためにセマンティックウィキを使用しました。その後、両グループの学生は、それぞれの説明を読み、どちらのグループがテレビシリーズのあらすじを最も正確に再現できるかをテストで比較しました。結果は、自然言語を用いた方がより容易で、正確で、迅速であることが示されました。 次に、生徒たちが書いた構造化された記述を注意深く検証したところ、誤りが多数あることがわかりました。例えば、「張三は李思を抱きしめた」という記述です。いわゆる知識工学の訓練を受けた人にとって、「抱きしめる」は関係性を表すものであり、張三と李思はそれぞれ主語と目的語を持つ2人の人物であるのは明らかです。つまり、主語-動詞-目的語という構造です。「張三は李思を抱きしめる」という記述は非常に明確な知識モデルです。しかし、かなりの数の生徒がこの非常に単純なモデルを誤解していました。彼らは概念とは何か、関係とは何か、属性とは何か、さらには主語と目的語とは何かさえ理解していませんでした。そして、私たちがこの記述を最初に思いついた時、高校教育などの教育課程において、ほとんどの人が構造化された思考の訓練を受けていないという事実を見落としていたことに気づきました。これは、事前に認識できない認知の複雑さです。 私たちは皆、10年以上の訓練を受けているため、こうしたことを当然のこととして受け止めています。その後、OWLワーキンググループでも同じ状況に遭遇しました。ある人が複雑すぎると言ったのに対し、ある論理学者は「全く複雑ではない」と反論しました。コンピュータ上で実行する場合、アルゴリズムの複雑さは多項式複雑度でしかありません。それを聞いて、私は突然あることに気づきました。これらの論理学者が言及していた複雑さは、機械にとっての言語の複雑さであり、それが私たちが通常計算複雑度と呼ぶ理由なのです。 しかし、一般の人が理解できる複雑さはそうではありません。例えば、半ページで説明できるものはシンプルです。理解するのに20ページも読まなければならないものは複雑です。つまり、技術の核心は、プログラマーやユーザーがすぐに使えるかどうかです。一目見て、聞いて、開いてすぐに理解できるでしょうか？説明が不要でしょうか？それがシンプルさの意味です。 アルゴリズム設計、ドキュメント設計、アプリケーション設計など、その有効性の鍵はシンプルさと使いやすさにあります。これは非常に重要な要素です。Stanford ParserがNLP分野で広く使用されている重要な理由の一つは、その優れたドキュメントです。各クラスには独自のドキュメントがあり、豊富な例が掲載されています。 したがって、優れたドキュメントは、製品の認知的複雑さを大幅に軽減することができます。製品自体が複雑であっても、優れたドキュメントを作成することは製品の宣伝に役立ちます。したがって、プログラミング愛好家、技術者、アルゴリズム開発者など、製品に触れる人々にとって製品を可能な限りシンプルにすることが、製品の成功を確実なものにする鍵となります。 NO.7 プロ意識の欠如7 番目のポイントは簡単に理解できます。それは、プロ意識の欠如です。 ある会社がQ&Aシステムを作りたいと言って、3～5人の人材を投入したいと言っている人によく出会います。たいていの場合、彼らは博士号を持っているわけではなく、ただのエンジニアが2～3ヶ月、あるいは3～5ヶ月で何かを急いで作ろうとしているだけでしょう。それは単なる希望的観測です。もちろん、私は彼らを直接批判するつもりはありません。 人工知能製品は確かにある程度の専門性を有しています。多くの組織が自力でこれを試み、1,000万元、2,000万元、あるいは3,000万元もの費用を費やし、結局は失敗に終わっています。実際、十分な専門知識を持つ人材がいなければ、これを実現するのは非常に困難です。 私自身も、これまで関わった意味理解システムを含め、同様の状況を何度も経験してきました。このようなシステムを構築するには、実際には多くの異なるアルゴリズムを統合する必要があり、単一のアルゴリズムだけで解決できるものではありません。例えば、IBM Watsonシステムは、機械学習、自然言語処理、ナレッジグラフアルゴリズムなど、数十種類の異なるアルゴリズムを使用しています。これらのアルゴリズムを適切に組み合わせ、適切なバランスを保つ能力は、非常に重要なスキルです。どのアルゴリズムを使用し、どのアルゴリズムを避けるべきかを見極めることが不可欠です。 例えば、ルールシステムでは、10個の正規表現なら誰でも問題なく記述できます。しかし、100個の正規表現をうまく記述できるなら、あなたは間違いなく優れたソフトウェアエンジニアリングスキルを持つエンジニアです。1,000個の正規表現をうまく扱えるなら、あなたは間違いなくルール管理の正式なトレーニングを受けた人です。そして、10,000個の正規表現を本当にうまく扱えるなら、あなたは間違いなくルール管理において豊富な経験を持つ人です。 もちろん、1,000件や10,000件のエントリと言っても、10,000回コピー＆ペーストして単語をいくつか変更するという意味ではありません。それはカウントされません。人工知能の多くの側面における難しさは、ここにあります。オープンソースのパッケージをオンラインで利用すれば、作業の80%は簡単にこなせます。しかし、難しいのは最後の20%です。ユーザーのニーズを満たすには、通常98%または99%の精度が求められます。十分な専門知識がなければ、この最後の数点は非常に困難です。 例え話で言えば、月へ行きたいなら、必要なのははしごではなくロケットです。はしごを動かしても木に登ることしかできず、それ以上高くは登れません。必要なのは、立ち止まってロケットを作ることです。ロケットを作るには専門知識が必要です。専門知識がなければ、常に80%のレベルで止まり、それ以上高くは行けません。 先ほどお話しした意味理解プロジェクトに戻りましょう。当時、私たちはルールベースの手法、統計的手法、自然言語処理手法の統合など、多くの困難に直面しました。世界中の多くの研究室がこの課題に取り組んでいましたが、あらゆる側面において完璧なバランスを実現できる人材が不足していました。 実際、IBMのWatsonシステムの開発には、プロジェクト管理の変更や様々な技術の選択など、多くの社内改革が伴いました。このような人材は非常に希少です。中国では、意味理解システムのアーキテクチャを真にゼロから構築できる人材は極めて少なく、10人か20人程度でしょう。他の人工知能分野でも同様の状況に直面していると思います。 専門性はプログラミングや技術だけに限りません。AIプロダクトマネージャー、AIプロジェクトオペレーター、そしてナレッジシステムやデータガバナンス全体において、高度な専門性を持つ人材が求められており、現在、そのような人材が深刻に不足しています。 NO.8 エンジニアリング能力の不足8番目の方法はエンジニアリング能力が不十分であることです。 私の博士論文は分散推論エンジンに関するものでしたが、プログラミングスキルが不足していたため、卒業するまで実装することができませんでした。しかし、2012年と2013年以降、メッセージスイッチングベースのグラフコンピューティングを含むグラフコンピューティングの発展により、分散推論エンジンの開発ははるかに容易になりました。 しかし、これは私にとって特に大きな教訓となりました。 その後、私はどんな仕事に就く前にも、エンジニアリングスキルの向上に注力しました。これらのスキルには、ソフトウェアエンジニアリングのスキル、つまりコードの書き方、管理方法、システム統合、回帰テスト、バージョン管理などが含まれます。その後、面接を行う際にも、これらの側面に細心の注意を払うようになりました。 AI技術の成功は、アルゴリズムだけでなく、基盤となるアーキテクチャやシステムにも大きく左右されることが多いです。例えば、論文で非常に優れた分散推論アルゴリズムが紹介されていても、必要なアーキテクチャがなければ実装できません。これはディープラーニングにも当てはまります。最近、Chen Tianqi研究室ではアルゴリズム、アーキテクチャ、オペレーティングシステムをすべて一元的に運用しているのを拝見しましたが、これは素晴らしいと思います。現状では、アルゴリズムとアーキテクチャのギャップが大きすぎます。 エンジニアリングは人工知能の問題を解決する鍵です。コーディングスキル、アーキテクチャスキル、そしてエンジニアリングスキルが不足しているなら、アルゴリズムについて議論するべきではありません。アルゴリズムに集中する前に、エンジニアリングスキルの向上を優先すべきです。 NO.9 ラインナップが豪華すぎる第九点，阵容太豪华。 这一点不太好说具体的项目是什么，太敏感了。 但是我就从逻辑上给大家讲一下。因为一个项目如果太豪华，核心的问题就是沉没成本。 我们也经常看到一些初创公司，不管是从商务上，还是从技术上，特别优秀的人组成了一个公司，最后还是会失败。为什么？因为比较优秀的人，就是想要做大的事情。一个大的事情，很难一下子就做对。通常大的事情，是从小的事情成长起来的。如果我们不能够让豪华的阵容，从小事做起，通常这样一个事情是会失败的。
逻辑很简单，我就不多说了。 NO.10 时机不到，运气不好第十点，我可以把所有其他的因素丢到这儿，就是时机不到、运气不好。 其实可以把所有其他的事情都归结为运气不好。 比如说我们现在看深度学习，比如像attention、卷积、LSTM、联想记忆等等所有这些概念在90年代，我读研究生的时候，这些概念都已经有了，但是当时是做不到的。当时即使有了这些算法，也没有这样的算力，即使有了这样的算力，没有这样的数据。 在2000年的时候，我在硕士毕业之后，就在研究一种分层的多层神经网络。我们把它称为hierarchical neural network，跟后来深度学习的想法非常接近。我带着这个想法，去见我的博士导师。说我想继续沿着这个方向往前走，但他说现在整个神经网络都已经拿不到投资了，你再往前走，也走不下去，所以后来就放弃了这个方向，准备做语义网了。 10年之后，这个方法终于找到了机会，后来就变成了深度学习的东西。 很多时候，时机不到，即使你有这个算法，你也做不到。90年代的神经网络，差不多花了10年的时间，才等到了自己的复苏。 知识图谱也是一样的，知识图谱大概也等了十几年的时间，到了最近这几年才真正地得到了大规模的应用。 要約让我们来取个反，做个总结： 最后一点，时机和运气再啰嗦一下。 很多时候，我们是真的不知道这件事情能不能做得成，也真的不知道，自己处于什么样的历史阶段。很难预言未来是什么，但是至少有一点，如果我们多去了解一些算法层面的发展，包括人工智能的发展史，包括相关的这些技术的发展史，能够更好地理解未来。 所以我也推荐一下尼克老师的《人工智能简史》这本书。我看了两遍都挺有收获的。看了这东西，能更多地理解什么是时机，什么是运气。 有时候我也经常会读一些经典的文章，十年前或20年前的书，我读了还是挺有启发的。比如说，今年我又把Tim Berners-Lee 《编织万维网》那本书又重新读了一遍，读了一遍以后，我就坚定信心了。 知识图谱这样一个互联全世界的记忆的系统，大概率到2030年能够实现，这还是一个很遥远的时间，但是根据历史规律，应该到2030年能实现了。 一方面，降低我们现在的预期，另一方面也给我们前进更大的鼓励。 场景跃迁理论刚才反反复复提到了，要控制用户的预期，控制自己的预期。做一个项目，要从小到大，循序渐进。最后把所有的东西抽象到更高层面上，我自己总结为一个理论，叫场景跃迁理论。 这个理论的核心，是说一个人工智能的公司需要多次的产品市场匹配，就是Product-Market Fit。如果提供了一个产品，市场恰恰需要，而这个市场恰恰又很大，就说得到了一个产品市场匹配。 经典的互联网创业，通常做一次产品的市场匹配，就可以成功了。但人工智能往往要做好几次，互联网公司和人工智能公司很不一样。 一个称为养鸡场模式，一个称为养小孩模式。 互联网公司是一种养鸡场模式，它是一个大规模的复杂系统Complex system。它的关键是可扩展性。我养了一只鸡，我发现这只鸡不错，我养1万只鸡，这就是养鸡场模式。核心就是如何能养一万只鸡，这就叫可扩展性。 人工智能应用是另外一种类型的复杂系统，叫Complicated system，它是有非常多的组件，通常是上百种奇奇怪怪的组件组合在一起。它的核心并不是养一万只鸡，更多像养小孩一样，生完孩子，从小给他换尿布，给他喂奶，教他走路，教他说话，逗他玩，小学、中学、大学，一路把他养大，每一个阶段所面临的主要任务都不一样。你如何能够让这小孩成长，我们把它称为可演进性，这才是AI公司最核心的因素。 把一个AI的公司给养大，其实是特别不容易的事情。就跟养小孩一样，往往前5年的时间，都在搭团队，搞基础，特别辛苦。公司存活的观念就是，如何能够在演进的过程中，逐步地挣钱，而不是试图一步到位地找到市场产品结合点。不仅仅是在人工智能的阶段要挣钱，在人工智障的阶段，也要能够挣钱。 没有一个完整的系统，怎么能挣钱？只能够把系统中的某些组件拿出去，做部分的商业化。就好像毛毛虫到蝴蝶一样，毛毛虫要蜕皮，蜕好几次，才能变成一个蝴蝶。毛毛虫阶段，它要吃树叶子，在蝴蝶那个阶段，它是要吃花蜜，所以它在两个不同的阶段，它的商业模式是完全不一样的。人工智能公司也要蜕好几次皮。在早期的时候，因为产品还不够完善，所以人工智能公司早期都是外包公司，这是正常的，就应该接受，这是发展必经的阶段。 总结今天所说的一切，人工智能是一种新兴的事物，它是非常复杂的东西。很难用传统的旧经验来套这样一种东西的发展，必须经过很长时间的演化，才能够达到成熟的状态。而这个演化力才是我们想做一个成功的商业的尝试，最关键的因素。如何保证在一次又一次的场景跃迁当中，团队不散架，这样的能力，才是决定了某一个商业上面能不能成功的最大的关键。 我觉得不仅仅是商业，不管是在学校里做研究也好，还是在大型跨国公司里做研究也好，很多道理都是一样的。就是如何能够循序渐进地，从小到大地来做，谢谢大家！ -以上- https://zhuanlan.zhihu.com/p/41061140 |
