吉田さんによれば、導入フェーズで大変だったのは、「AIの学習データを作ること」だった。
hitTOはユーザーが入力した質問文を解析し、最適な回答を返す。聞きたいことは同じでも、ユーザーによって異なる質問文を理解するためには、AIに質問と回答のバリエーションを学習させる必要がある。
そのため、1つの回答に対して最低15パターンの質問文を作成するというアプローチを取り、初期導入時には117件の回答と2322件の質問文を用意した。ヘルプデスクのQA履歴を元に、部員が総出で作文したという。
がんばってデータを用意したものの、初期段階ではhitTOの回答の精度はそれほど高くなかった。その理由を、吉田さんはこう説明する。
「例えば『イントラネットに入れない』というケース1つとっても、原因は『ネットワークにつながっていない』『パスワードが間違っている』等、いろいろあるわけです。そのため、最初は異なる回答に対して似通った質問を作っていました。hitTOは質問に対して候補となる回答の中から最も可能性が高いものを出すのですが、例えば、ある質問に対して3つの回答がそれぞれ3割の可能性で存在すると、“1つを選べない”ので、結局、『何も答えが出ない』という結果になってしまいました」(吉田さん)
この問題に対しては、“似たような質問に複数の回答がひもづく”ケースをなくし、例えば「イントラネットに入れない」という質問に対しては、「考えられる複数の解決方法を1つの回答の中に盛り込む」、という形で対応することにした。
このような試行錯誤を見ていた川口さんは「これまでのシステムとは異なる、AIゆえの苦労があったようだ」と話す。
「情報システム部のわれわれが慣れているのは、システムのロジックがこうだから、こういう質問を入れればこの答えが出るはず――という考え方です。でもAIの世界では、こちらが意図して答えを出させるというのではなく、どちらかというと“帰納法的なアプローチ”になりますよね。だから導入後にデータをブラッシュアップするのが重要で、運用体制をどうするかというのも、重要な視点だと思います」(川口さん)
まずはリリースして使ってみることで“AIのクセ”のようなものを理解し、それに合わせてデータを調整していくことでシステムを成長させていく必要があるのだ。
吉田さんは、「育てていかないと、勝手に大きくなってはくれないんです。回答の履歴を見て『ここは直してあげなきゃ』と思うなど、だんだんhitTOが可愛く思えてきました」と笑う。
Copyright © ITmedia, Inc. All Rights Reserved.