2013年03月

10

実際どうでしょう Vol.4「『PureFlexは高い製品だからこそ・・・』エバンジェリストへインタビュー」

インタビューシリーズ 「実際どうでしょう」

普段の製品・ソリューション紹介だけでは聞き出せない情報を「実際のところはどうなんだろう?」という素人視点で、専門家に聞いてみるシリーズです。

掲載: 2013年3月

 

<重山は「PureFlexってお高いんですよね」程度のドシロウトでした。今回の話で柴田さんのファンになりました。 (*´ω`*) >

今回は、第1回の新井さんからの紹介でIBMエバンジェリストの柴田さんにお会いしました。
HP→Microsoft→IBMという経歴の持ち主で、ベンダー側の売込みにならない論法を身につけていらっしゃるザ・エバンジェリストという方でした。(インタビュアー:重山)
エヴァンゲリオンではなく、エバンジェリストの柴田さん

PROFILE

日本アイ・ビー・エム株式会社 柴田 直樹さん
システムズ & テクノロジーエバンジェリスト (PureSystems担当)
High Performance Computing(HPC)/VDI/Cloud ソリューション
ITmedia オルタナティブ・ブログ;My Life As Evangelist

※ 2013年3月時点でのプロフィールです。

MERITひろば事務局 重山 勝彦 (インタビュアー)
日本情報通信株式会社 MERITひろば事務局 入社3年目にてMERITひろばの運営、コンテンツ全般を担当。

 

「オンプレミス」は「固定資産」だと思えばわかりやすい

—– 本日は午後にマイナビのイベント※1で壇上に上がられるのですね。そんな忙しい時にインタビューのお時間頂戴して恐縮です。(重山)

 

※1 2013.02.08 マイナビニュース仮想化セミナー ~仮想化環境に最適なIT基盤とは!?~ 【Day 2】今こそ仮想化基盤を再考しよう!

 

柴田: 体調も喉の調子も良いので、大丈夫ですよ。ぶっつけ本番も鍛えられていますから(笑)
それよりも、インタビュー用の資料などは用意していないのですが、大丈夫ですか?

 

—– いつも雑談の雰囲気で進めているので、流れでお願いします。

 

経歴を拝見しますとHPC(High Performance Computing)※の分野にいらっしゃったのですね。
しかし、HPCって良く知らないのです。「グリッドコンピューティング」という単語ならなんとなく知っています。

※単位時間当たりの計算量が非常に多い計算処理、まとはそのコンピュータを示す。(High Performance Computer)
膨大な時間やコストがかかる大規模な実験の代用や、不確定要素の多さから実験が困難な自然科学現象の解明といった目的で行われることが多い。

 

柴田: あ、いいですね。いきなり自社製品の話をしてもつまらないですからね(笑)

HPCの世界では世の中で普及するずっと前から コモディティ(汎用製品)を並べていく「グリッドコンピューティング」がありました。車でいうとF1(HPC)の技術が一般車(汎用マシン)に落ちてきたようなものなので、例えば、並列、分散処理、ビッグデータも昔から関わっていて、なぜいまごろ賑わっているのだろう? というのが個人的な感想としてあります。

 

-—- 先に知り尽くしている技術ということですね。
あ、思い出しました。グリッドコンピューティングといえばGoogleの検索ポータルを支えているのが数千台のPCサーバを繋いで処理しているというWeb記事を見たことがあります。

 

柴田: よくご存知ですね。たしか当時、ひとつのリージョン(地域)で数千台だったと当時は聞いていました。

 

—– その技術はあまり企業のITには普及していない気がします。

 

柴田: はい、グリッド(コンピューティング)がなぜ流行らなかったのか。(実際には金融業界では積極的に採用された技術だと思います。)

それは、一言でまとめると「標準化覇権競争が発生し、まとまらなかった。」のかなと想像しています。そうでなければ、仮想化統合の流れも、もっと早くきていたはずです。ビジネスの世界では、技術が評価されて普及するだけでなく、違う力学が発生しますからね。

また、ITの世界では、言葉を定義したモノ勝ちという風潮もあります。
例えば、“クラウド“も人によって定義が異なると思いませんか?

 

—– はい。おっしゃるとおりです。特に“プライベートクラウド”は社内なのか、社外なのか・・・等の前提を揃えておかないと会話が咬み合わないケースがあります。

 

柴田: 以前、メンバーと“オンプレミス“の定義を話し合った結果「固定資産でいいんじゃない?」という事がありました。

 

—– 固定資産ですか。面白いですね。確かにシステム用語ではなく、会計で定義したほうが法人としては概念を理解しやすいですね。

 

柴田: はい。固定資産と考えると償却する、つまり“使いきろう”という意識が強くなるじゃないですか。クラウドに対するオンプレミスという言葉はそのほうが分かりやすいはずです。

 

「既存システムをクラウドにするだけ」というメッセージは偏っている

柴田: 今は WindowsAzureやAWS(AmazonWebService)、もちろんIBMのSmater Cloudも含めて 大手のパブリック・クラウドが全盛と言われていいますが、私はこれらの「既存システムをクラウドにするだけ。ハードウェアを持つことはもう古い」的なメッセージは少し偏っていると思っています。

 

—– 偏っているとはどういうことでしょうか。

 

柴田: この話は、昨年(2012年)の10月に開催されたイベント“ISUC仙台大会※”で参加者とディスカッション形式のセッションをした際のテーマなのです。

いわば、クラウドについての“実際どうでしょう?“版で、世の中に多く出ている「常識」「風評」「メリット」「デメリット」などの信憑性についてお話ししました。一部ですが、自社サービスも含めた否定的な内容もあったので大丈夫かなぁと思ったのですが共感をいただきうれしかったです。
※ iSUC(アイザック)は、IBMのユーザー団体《全国IBMユーザー研究会連合会》が主催するIBMシステム・ユーザーのための研修会
※【白熱教室】 社内 IT システムのクラウド化 「真の考慮点」 – 世の中の常識は ウソ か ホントか !?

 

オンプレミス=「固定資産」

 

—– おととしのISUC大津大会はMERITひろばも出展していたのですが、昨年は参加できませんでした。一部だけでも結構ですので、その内容を教えて頂けませんか?

 

柴田: はい。もちろんです。

クラウド利用に関する考え方をご紹介しました。例えば、料金体系については、大手クラウド事業者のメッセージって「時間あたり◯◯で安いです」「使った分だけお支払い」という面がありますよね。

それは日本のビジネスにフィットするかな?という視点です。例えば、日本の中小企業様のITに利用可能な「流動的な運用費用」は果たしてどのくらいあるんだろう。。ということです。

 

—– トータルコストについては、ケースバイケースだと思いますが、「使った分だけ」という重量課金の仕組みは、最大のインフラを考慮して自社構築するよりコスト的に有効だろうというイメージがありますが。

 

柴田: 日本の企業のIT部門のSEは社員が中心ですが、例えば、北米では80%以上がアウトソーシングです。つまり最初から外注費という概念なんですね。そのため、ITコストの増減には慣れています。

 

一方、日本のIT部門の予算は、月額で流動的に使える金額幅は10万円以下がほとんどです。来月急に30万あがりますと言われても予算を確保していないので困ってしまいます。
ですから国内企業はクラウドといってもEaaS、PaaS、もさることながら VPS(バーチャル・プライベート・サーバ:ここでは仮想サーバサービスの意味)でコストを固定金額で利用するのとう方も多いということです。

日本の製造業や金融業などはかなり計画性が高い産業ですからね。それで年間運用できるのです。

 

—– なるほど、北米で流行っている仕組みをそのまま日本に適応するのは合わない場合があるということですね。

 

柴田: はい。個人的にはパブリッククラウドベンダーのメッセージは黒船的に感じます。

あ、IBMもそのようなメッセージを出しているので自社否定になっちゃいますね。間違っているという意味ではなく、そのまま鵜呑みしないで検討すべきと表現させてください。(笑)

 

—– はい。心得ています。(笑)

 

でも、警笛を鳴らせるのは、エンドユーザのお客様の視点がわかっているからこそ言えるのですよね。

 

PureFlexは高い製品だからこそ、納得して採用してほしい

—– 今期から担当になっているPureSystems、特にH/WのPureFlexについてはどのように紹介しているのですか?

 

柴田: PureFlexはお客様から見て、価格だけ見ると 高い製品ですよね。

 

—– あれ、私がこのインタビュー中に勇気を持って「すごく高価格帯の製品ですよね?」って言おうと思っていたのに先に言われてしまいました。エバンジェリストとしては珍しいですよね。これだけの機能とサービスがある!というのが先にくると思っていました。(笑)

 

柴田: そうですね、エバンジェリストのイメージってスマートにテクノロジーとビジョンだけを話すと思われがちなのですが・・・(笑)

昨年、ある検証作業で、ローエンドモデルのx3300 M4(IBM System x3300 M4)を使ってパフォーマンス検証していたのです。CPUはインテル Xeon プロセッサーの2400系です。とにかく20万~30万台のサーバマシンです。これでラッシュテストをしたら凄く処理が早かったので衝撃的でした。これを知ってしまった上でPureFlex製品を紹介していくにはどうすればいいんだろうと悩みましたね。(笑)

それもあって、高いからこそ、お客様にはちゃんと検討し、納得して購入してほしいという思いに至りました。つまり「高い理由と、高い出費でお客様にお届けできるPureFlexの価値」を共感頂ければ。という思いで製品の訴求をしているところなのです。

—– 柴田さんって本当に正直な方なんですね。(笑)具体的にはどのように紹介されるのですか?

 

柴田: お客様が求めているものは“リスクの低減”と“コストの削減”が必要なのです。

製品のパフォーマンスは最近のハードウェア十分過ぎるほどありますし、お客様も理解されています。ですから、“リスクとリスクヘッジをどのレベルまで考慮するか”をテーマに考え、お客様の反応を確かめながら紹介をしています。

例えば、昨年はとある中小規模のデータセンター事業者様にPureFlexの紹介でまわったことがあります。

ちなみに業界大手のデータセンター事業者様はこちらが売り込んだから買うというレベルではなく、自社で調達基準を決めておられます。もっとハッキリ表現するとベンダーの意見はをすべて共感してくれるなんてことはなかなか無いのかなと思っています(笑)

 

—– サーバの購入台数も多いですから、買い手側が強いのですね。Facebookのデータセンターはデータセンターやサーバ部品の仕様を公開してその“仕様に合わせた製品を売り込みしてこい“という感じですよね。

 

柴田: はい。ですから次にクラウドの中堅、中小事業者にご紹介に行くわけです。イメージとしては物理サーバ台数が3桁のレベルです。このゾーンの企業がPureFlexを採用してくれないかと考えたのです。

事業者は大手のコストメリットには太刀打ちできない分、インフラについては、すごく細かいところまで配慮されています。特に“リスク”対してはものすごく考えて、工夫されています。昨年、いくつかデータセンターでデータ消失やサービス中断などの事故がありましたが、あの事例では大手の資本があったからこそ大丈夫でした。

中堅・中小ではひとつのミスが事業継続できなくなるレベルですから。

 

—– そういえば、Azureサービスは、うるう年計算不具合で止まったりしていましたが、大手だから影響は大きくても即倒産にはならないですね。

 

データセンター事業者にどうしても消せないリスクを教えてもらいました

柴田: データセンター事業者の方々に教えていただいたのですが、対策を取り続けていてもどうしても消せないリスクの1つというのが「メンテナンス作業中にサーバのケーブルに触れてシステムエラーを起こす」ヒューマンエラーだそうです。

確かに、ラックに入っているサーバのケーブルは8ノードで40本くらいに刺さっているわけですね。こうなると設定変更や移設作業中に間違ったケーブルに触れて場合によっては抜いてしまったりすることにもなる訳です。

このリスクを減らすためにBladeを導入したと聞きました。なるほどと思った訳です。

 

—– その話は現場ならではですね。機能、性能、コストの比較ではなく、運用する観点で製品を採用されてきたのですね。

 

柴田: はい。例えば「こういったケーブルリスクも考えてPureFlexを採用を検討しています。」というメッセージはエンドユーザのお客様にお伝えしていいのではないかと思います。

それが付加価値の1つですから。それ以外にも話しきれないほどの価値はあるんですが、わかりやすい例を1つご紹介しました。

実際に、あるデータセンターでやっていることなのですが、「下位コースでは汎用的なXXXサーバを利用しています。上位コースは大手メーカー製です。」と料金プランに記載しているのですね。1.5倍程度しか差がないですから上位を選択されるお客様も増えるわけです。
—– エンドユーザから見てもリスクと対策の中身がわかるから安心ですね。

 

海底ケーブルの障害でデータ通信に大きなタイムロスを生むことがある

柴田: 他にもクラウド検討時に何がリスクなのか?という視点では海底ケーブルの話があります。

エンドユーザは「ディザスタリカバリ(災害対策)として、海外のサーバにもバックアップをとっています」とおっしゃるケースがありますが、3.11の震災の時に日本と海外をつなぐ海底ケーブルやルーターが故障して繋がらなくなった事実はあまり知られていません。

切れた回線は、他のルートを迂回することで継続して使えるのですが、その迂回ルートの通信には何時間も余計に時間がかかるケースもあり、ビジネス継続としては問題です。

 

—– 全然知りませんでした。そもそも世界のインターネットとつないでいる海底ケーブルがどうなっているのかも知りません。

 

震災時にどの回線に障害が発生したかは一般的には公表されていません。ケーブルのマップはWeb検索で簡単に見つけることができます。

注釈)インタビュー時にはそのデータを見せていただけましたが、掲載できません。ご了承ください。

 

—– いやぁ、この情報を知ってしまうと海外に2重化していれば万全とは限らないと思ってしまいます。

 

柴田: はい。ベンダーとしてもこのようなリスクを正直に話した上で最適な利用を提案した方がお客様の信頼を勝ち取れるのではと思っているのですが、なかなかそうはいかないようですね。(笑)

 

10年を見据えたシステム・・・では足りなかった

柴田: しかし、このようなリスクを真摯にお伝えすることで、お客様は「普通のサーバでいいんだっけ?、クラウド基盤はどこにしっかりと持つ必要があるんだっけ?」となりここでやっとIBMの話を聞いてくれるのです。

 

—– 時間はかかるかも知れませんが、リスクと向き合うという点で必要な話ですね。それにしてもエバンジェリストとしては製品のリスクを先に話すのは珍しいなぁと思ってしまいます。

 

柴田: もし私がエバンジェリストではなかったら、このようなリスクの話はしないで、「ハイ、機能はこうです、比較するとこうです、だからこのマシンです、クラウドはダメです IBMが一番です」という話をしていたかも知れないですよ(笑)

 

—– 聞いたことがある会話です。(笑)

 

リスクをお伝えして、興味をもってもらった後に、IBM Flex Systemsの話に進み、「今後10年のクラウド基盤として使い続けることができる製品」と紹介するわけですね。

 

柴田: 私の発言を調べていらっしゃいますね。

実はですね、う~ん、この10年を見据えたという表現は思い切って発言したつもりだったのですが、お客様はもっと長い期間を期待されている場合も多いのですね。とあるお客様からは「短いよ」と言われてしまいました。例えば 公益、政府系のシステム等はインフラを長期期間維持する必要がありますから。

 

—– 情報系のシステムなら10年あれば十分と思ってしまいます。しかし、今から10年前はどうだったかを考えてみればいいのですね。

 

flexsys01

 

 

WindowsXPは20世紀に基本設計されたが現在も主流

柴田: その通りです。

例えば、ブレードサーバー(IBM Blade Center)は「立派な10年選手」の製品ですが、現在も利用されています。ラックマウント型の基本設計をしている時にこれほどまでに仮想化が普及するとは誰も思っていなかったと思いますが、設計に余裕をもっていたからこそ、今日も問題無く利用いただいているのだなと思います。

ちょっと方向性は違いますが、クライアントPC向けのOSで言えば、WindowsXPは2000年に基本設計したOSです。つまり20世紀のOSがまだメインで使われていることになります。

 

—– ITの仕事についていると新しい製品や仕組みがどんどん出てきているのを日々感じていますが、利用者としては、長く使いたい、使わなければならないケースは多々あるのですね。

さてPureFlexは、ハードとソフトをベンダーがあらかじめ最適に組み合わせた製品、いわゆる「垂直統合サーバ」になると思いますが、最近はクラウド基盤のサーバとして勢いがあるように感じています。

 

柴田: 確かに垂直統合が他のサーバを凌駕するようなイメージをメディアが発信しているかもしれないですが、例えばPower Systems(AS/400)を選んだお客様などは必ずしも同意する訳ではありません。

 

また、Pure Flexは販売店がほいほいと売れる訳ではないのは、重々承知しています。そのような状況でクラウドサービスに魅了されるお客様が増えるのも良くわかります。だからこそ、選ぶ方には慎重に選んでほしいと思っています。

 

—– 「MERITひろば」のコンテンツ掲載の業務に携わって勉強になっているのは、ハードウェアもソフトウェアも機能で紹介する/売る時代は終わってきていて、性能が良いのは当然で、そこにお客様が共感できるストーリーがあると良いということです。なんだかワイナリーがワインを販売するのと同じですね。

 

「100年続くワイナリーで、全体の数%しか取れない品種を贅沢にしようし、防腐剤は一切使わずにオーガニックで醸造、空輸も一定の温度で管理して・・・」

 

日本人は良い物は高くても買う、コモディティは100円ショップで買う

柴田: そうそう、その通りです。

 

それを「ドイツワイン、辛口のシュペートレーゼ、1本50万円です。すごく美味しいです。」と言われただけでは買わないですよね。

日本人は良いものは高くても価値がわかれば買います。一方コモディティ製品は100円ショップで買います。100円ショップのグッズもちゃんと使えるじゃないですか(笑)

 

—– おっしゃるとおりですね。実は私はMERITひろばの運用以外で、部門システムのインフラの管理も担当しているのですが、例えば、私どもの会社(日本情報通信)がクラウドを検討すると想定した場合のポイントなどはありますか?

 

柴田: そうですね、企業の成長カーブとクラウドの利用度には傾向があります。

従業員規模では250名くらいまでは積極的にクラウドを採用していきます。10人、20人のベンチャーなどは全てクラウドで賄えますよね、その延長の目安が250名くらい。今度は250名から500名くらいに成長していくと、クラウド投資額が膨大になっていくので、今度はオンプレ、固定資産のITシステムに進みます。

次に1,000名規模を越えていくと、事業の変化やIT規模の柔軟に対応できるのでクラウドの利用が進んでくるのです。従業員規模はあくまで参考値とみてもらってもこの流れがわかってもらえるかと思います。

 

—– クラウド利用度は上がって落ちるがまた上がる(0人 ↑  205人 ↓ 500人 ↑ 1000人 ↑ )というカーブを描くのですね。

確かに弊社は全体で1,000名超であり、基本はオンプレミスが多いですが、今まさにプライベートクラウド利用の検討が進んでいます。すごい、ぴったり当たっています。

 

柴田: 良かったです。お客様の企業がどのポジションにあるかの目安になりますからね。

プライベートクラウドを進めていく際の副次的高価としては、IT資産の棚卸ができる点があります。普段全然やれていない企業がほとんどです。また、プライベートクラウドにしましたというお客様でも仮想化していない、またはできない事情が残ったサーバーも少なくないことが多いです。

例えばFaxサーバや移植ができない基幹システムの一部です。こういったレガシーシステムは仕組み上残さないといけない場合も出てきます。

 

—– 実に興味深い話です。今日はこのあと移動して、イベントで壇上に上がられる訳ですから、もっとお話したいのを我慢します。是非、第2弾をやらせてください。

 

柴田: 楽しかったです。第2弾、こちらこそお願いします。

 

 

その他の記事

2024年04月08日

【てくさぽBLOG】watsonx Assistant + Watson Discovery + watsonx.aiを連携してみた

こんにちは。てくさぽBLOGメンバーの高村です。 ビジネスへの生成AI の取り込みに注目が集まっている今日、watsonx.ai をどう活用すればいいのか、多くのお客様からお問い合わせ頂いています。そこで前回の「【てくさぽBLOG】IBM watsonx.aiを使ってみた(Part2)」では、watsonx.ai のユースケースとして Retrieval-Augmented Generation(以下 RAG)をご紹介しました。 今回は、RAG の仕組みを利用し AIチャットボットを提供する「watsonx Assistant(以下 Assistant)」と検索エンジン機能を提供する「Watson Discovery(以下 Discovery)」、「watsonx.ai」を組み合わせた連携ソリューションをご紹介します。 目次 AssistantとDiscoveryの連携 watsonx.aiを取り入れた連携 Assistant + Discovery + watsonx.aiを連携してみた さいごに お問い合わせ AssistantとDiscoveryの連携 本来なら各製品を一つのブログで詳しくご説明したいところですが、今回は連携した結果についてのご紹介となりますので、Assistant と Discovery については今後のブログであらためてご紹介したいと思います。 Assistant は watsonx の大規模言語モデルが搭載され、自然言語の問い合わせを理解し、適切な回答を返すことができるチャットボット機能を提供する製品です。一方 Discovery はドキュメントから適切な情報を検索する検索エンジン機能、パターンや傾向を読み取る分析エンジンとしての機能を備えた製品です。 Assistant と Discovery を組合わせたユースケースでは Assistant にあらかじめ回答を用意してルールベースで回答させ、答えることが難しい問い合わせに対しては Discovery の検索結果を利用して回答します。 watsonx.aiを取り入れた連携 上記の連携では Discovery の検索結果がユーザーに表示される仕組みとなっていますが、watsonx.ai を介して回答を提供することでDiscovery が得た検索結果をさらに整理し、より理解しやすい形での返答が実現できます。 Assistant + Discovery + watsonx.aiを連携してみた Assistant、Discovery、watsonx.ai を連携してみます。 事前準備 利用環境 今回は IBM Cloud で提供される SaaS を利用して検証します。なお、Assistant と Discovery の Plusプランは30日間無償期間が付属されていますので、是非ご活用ください。 watsonx Assistant:Plusプラン(30日間無償期間あり、以降は有償) Watson Discovery:Plusプラン(30日間無償期間あり、以降は有償) watsonx.ai:Essentialプラン(有償) 検証の目的 検証では構築手順の他、以下の点を確認します。 「Assistant + Discovery + watsonx.ai」と「Assistant + Discovery」の連携による回答の違いを比較 言語モデルを変えて問い合わせを行い、回答の違いの比較 実施手順 以下の流れで検証を実施します。 Assistantのプロビジョニング Discoveryのプロビジョニング、検索対象とするデータの取り込み※取り込むデータは「IBM Power S1014 データシート」のS1014のPDF watsonx.aiのプロビジョニング Assistantの初期設定 Assistantのカスタム拡張機能からDiscoveryを繋げる Assistantのカスタム拡張機能からwatsonx.aiを繋げる Assistantアクションの作成、問い合わせの検証 言語モデルを変えて問い合わせの検証 検証実施 1. Assistantのプロビジョニング はじめに Assistant のプロビジョニングを行います。 IBM Cloud にログインし、カタログ画面から "Assistant" を選択します。 ロケーションとプランを選択し「作成」をクリックします。 しばらくすると以下の画面の様に、Assistant がプロビジョニングされます。 2. Discoveryのプロビジョニング 次に Discovery をプロビジョニングします。 カタログ画面から "Discovery" を選択します。 ロケーションとプランを選択し「作成」をクリックします。 しばらくすると以下の画面の様に、Discovery がプロビジョニングされます。※ここで、資格情報内にある「API鍵」と「URL」をメモに控えます 「Watson Discoveryの起動」をクリックし「New Project +」をクリックします。 Project name に任意の名前を入力、Project type では「Conversational Serch」を選択し「Next」をクリックします。 作成されたプロジェクトをクリックします。 「Integration Deploy」をクリックします。 「API Information」タブをクリックし「Project ID」をメモに控えます。 次に検索対象の PDF を Discovery に取り込みます。 「Manage collections」から「New collection +」をクリックし、「Collection name」に任意の名前を入力、「Select language」を「Japanese」に設定します。 Upload files の領域に PDF をドラッグアンドドロップして「Finish」をクリックします。 アップロードが完了しました。次に、Smart Document Understanding機能(以下 SDU)を利用して PDF内のヘッダーやテキストなどのフィールドを定義します。 SDU は、PDFをはじめとする非構造化データの文書構造を理解して検索や分析の精度を向上させる機能です。例えばタイトルと定義した箇所を検索キーとしたり、検索対象をテキストと定義した箇所のみとするなど可能になります。 「Identify Field」タブをクリックします。 取り込んだ PDF が表示されるので右側の Field labels からヘッダー箇所やタイトル箇所などをドラッグアンドドロップして指定していきます。 ページの定義が終わったら「Submit page」をクリックして次の頁を定義していきます。 SDU では数ページ指定すると自動的にヘッダー箇所やテキスト箇所を認識してくれるので、何ページもあるドキュメントには便利な機能です。 今回は SDU を使って PDF の文書構造を定義しました。SDU以外の Discovery の機能については、また別の機会にご紹介したいと思います。 3. watsonx.aiのプロビジョニング ※watsonx.ai のプロビジョニング方法は「【てくさぽBLOG】IBM watsonx.aiを使ってみた(Part1)」をご参照ください。 4. Assistantの初期設定 Assistant の初期設定を行います。 Assistant を起動します。 起動後、以下の項目を入力します。 Assistant name:任意の名前を入力 Assistant Language:「English」を選択※日本語を選択することが可能ですが、Assistant のスターターキットは英語での利用を想定しているため今回はEinglishを選択します Assistant の公開先を「web」に設定します。※"Tell us about your self" 以降はご自身の情報を入力ください 入力後「Next」をクリックします。 デフォルトのチャットUI を利用するため「Next」をクリックします。 プレビュー画面が表示されるので「Create」をクリックします。(以下の画面は「Create」が隠れてしまっています) 「Congratulations!」と表示されたら初期設定は完了です。 5. Assistantのカスタム拡張機能からDiscoveryを繋げる 「Githubのassistant-toolkit」から "watson-discovery-query-openapi.jsonファイル" をダウンロードします。 Assistant のメニューから「Integration」をクリックします。 下にスクロールし「Build custom extension」をクリックします。 以下の画面が表示されるので「Next」をクリックします。 「Extension name」に任意の名前を入力し「Next」をクリックします。 先程ダウンロードした watson-discovery-query-openapi.jsonファイルをドラッグアンドドロップでアップロードします。 以下の画面が表示されるので「Finish」をクリックします。 追加した Extension の「Add +」をクリックします。 以下の画面が表示されるので「Next」をクリックします。 以下の画面が表示されるので、選択および入力します。 Authentication type:「Basic auth」を選択 Username:「apikey」と入力 Password:メモに控えたWatson DiscoveryのAPI鍵 discovery_url:メモに控えたWatson DiscoveryのURLから"http://"を除いた値 ※以下の画面ショットは discovery_url入力箇所が切れてしまっていますが、実際は「Servers」の下に discovery_url の項目があります 以下の画面が表示されるので「Finish」をクリックします。 Extension が「Open」となっていることを確認します。 これで watsonx Assistant と Watson Discovery が連携できました。 6. Assistantのカスタム拡張機能からwatsonx.aiを繋げる 次に、Assistant のカスタム拡張機能から watsonx.ai を利用できるように設定します。 設定には IBM Cloud の APIキーと watsonx.ai のプロジェクトID が必要です。取得方法は「【てくさぽBLOG】IBM watsonx.aiを使ってみた(Part2)」をご参照ください。なお、今回は東京リージョンで watsonx.ai をプロビジョニングします。 Github の「assistant-toolkit」から "watsonx-openapi.json" をダウンロードします。 Visual Studio Code などで東京リージョンの URL に編集し保存します。 Discovery の連携と同様に、Assistant のメニューから「Integration」「Build custom extension」をクリックします。 以下の画面が表示されるので、任意の Extension name を入力して「Next」をクリックします。 編集した watson-discovery-query-openapi.jsonファイルをドラッグアンドドロップでアップロードして「Next」をクリックします。 以下の画面が表示されるので「Finish」をクリックします。 追加した Extension の「Add +」をクリックします。 以下の画面が表示されるので、選択および入力します。 Authentication type:「Oauth 2.0」を選択 Grant type:「Custom apikey」を入力 apikey:取得済みのIBM CloudのAPIキー Client authentication:「Send as Body」を選択 Header prefix:Bearer(デフォルト) Servers:https://jp-tok.ml.cloud.ibm.com(自動入力) 以下の画面が表示されるので「Finish」をクリックします。 Extension が「Open」となっていることを確認します。 これで Assistant と watsonx.ai が連携できました。 7. Assistantアクションの作成、問い合わせの検証 Github の「assistant-toolkit」から "discovery-watsonx-actions.json" をダウンロードします。 Assistant の「Actions」から「Global Setting」をクリックします。 「Upload/Download」タブをクリックし、Uploadスペースに discovery-watsonx-actions.json をドラッグアンドドロップしてアップロードします。 以下の画面が表示されるので「Upload and replace」をクリックします。 以下の画面の通り、3つのアクションが作成されます。 メニューから「Variables」「Created by you」をクリックします。 「discovery_project_id」の値をメモに控えていた Discovery のプロジェクトID を入力し「Save」をクリックします。 「watsonx_project_id」の値をメモに控えて置いた watsonx.ai のプロジェクトID を入力し「Save」をクリックします。 「model_id」の値で watsonx.ai で使用する言語モデルを指定します。2024年2月29日に GA された日本語で訓練された Granite-japaneseモデルを使用するため、「ibm/granite-8b-japanese」を入力し「Save」をクリックします。(その他変数はデフォルト値とします) 「Actions」から「Generate Answer」を選択し、「model_input」の値を以下の例の様に日本語に変更します。 例: ("<s>[INST] <<SYS>>\nあなたは親切で、礼儀正しく、誠実なアシスタントです。常に安全を保ちながら、できるだけ役立つように答えてください。答えは簡潔に日本語で回答してください。回答には、有害、非倫理的、人種差別的、性差別的、有毒、危険、または違法なコンテンツを含めてはいけません。回答が社会的に偏見がなく、本質的に前向きであることを確認してください。\n\n質問が意味をなさない場合、または事実に一貫性がない場合は、正しくないことに答えるのではなく、その理由を説明してください。質問の答えがわからない場合は、誤った情報を共有しないでください。\n<</SYS>>\n\n質問に答えることで、次のエージェントの応答を生成します。タイトルが付いたいくつかの文書が提供されます。答えが異なる文書から得られた場合は、あらゆる可能性について言及し、文書のタイトルを使用してトピックまたは領域を区切ってください。与えられた文書に基づいて回答できない場合は、回答がない旨を記載してください。\n\n").concat(passages).concat("\n\n[question]: ").concat(query_text).concat("[/INST]") 以上で設定は完了です。 さっそく Assistant から問い合わせをしてみます。 右下の「Preview」をクリックします。 チャットから S1014 の特徴について問い合わせしてみます。約18秒後に以下の回答が返ってきました。 「Inspect」をクリックすると、Discovery の検索結果が以下の通り watsonx.ai に渡されていることがわかります。 <s>[INST] <<SYS>> あなたは親切で、礼儀正しく、誠実なアシスタントです。常に安全を保ちながら、できるだけ役立つように答えてください。答えは簡潔に日本語で回答してください。回答には、有害、非倫理的、人種差別的、性差別的、有毒、危険、または違法なコンテンツを含めてはいけません。回答が社会的に偏見がなく、本質的に前向きであることを確認してください。 質問が意味をなさない場合、または事実に一貫性がない場合は、正しくないことに答えるのではなく、その理由を説明してください。質問の答えがわからない場合は、誤った情報を共有しないでください。 <</SYS>> 質問に答えることで、次のエージェントの応答を生成します。タイトルが付いたいくつかの文書が提供されます。答えが異なる文書から得られた場合は、あらゆる可能性について言及し、文書のタイトルを使用してトピックまたは領域を区切ってください。与えられた文書に基づいて回答できない場合は、回答がない旨を記載してください。[title]: IBM Power S1014 柔軟かつセキュアなハイブリッドクラウド・インフ ラストラクチャーで俊敏性を実現[document]: 1 コ ア 当 た り 4 つ の M a t r i x Math Acceleratorによる迅速 なAI推論のために洞察と自動 化を合理化 業界標準のDIMMより2倍優 れたメモリーの信頼性と可用 性を提供 IBM® Power® S1014 は、1ソケット、4U Power10プロセッサーをベースにしたサー バーで、IBM AIX®、IBM iまたは Linux®上のビジネス・クリティカルなワークロード 向けに設計されています。Power S1014を使用することで、ワークロードはより 少数のサーバーに統合され、ソフトウェア・ライセンスの数、電力と冷却のコスト を削減します。Power S1014サーバーは、プロセッサー上でのメモリー暗号化を 使用してエンドツーエンドからデータを安全に保護し、ラック型またはタワーフォー ム・ファクターで購入できます。 プロセッサー・レベルでのメモリー暗号化と、POWER9 と比較してすべてのコア で4倍の暗号化エンジンによりコアからクラウドまでのデータを保護 ますます高度に分散した環境に存在するデータには、もはや境界線を設定すること は不可能です。 [question]: S1014の特徴は?[/INST] Assistant と Discovery のみの連携で検索した結果は以下の通りです。watsonx.ai を使用した方がより簡潔で分かりやすい回答を得られることが分かります。 8. 言語モデルを変えて問い合わせの検証 言語モデルを "llama-2-70b" にして同様の問い合わせをしたところ、約24秒後に回答が返ってきました。箇条書きで丁寧な印象です。 言語モデルを "elyza-japanese" にした際は10秒ほどで回答がありました。主語として「S1014の特徴は」とあることで、問いに対する回答が分かりやすくなっています。 言語モデルを変えて試した結果、llama-2-70B は箇条書きで回答し丁寧な印象を受けましたが、回答が得られるまでに24秒かかりました。一方 Granite-japanese や elyza-japanese はシンプルな回答を生成し、Granite-japanese は18秒、elyza-japanese は10秒というより短い時間で回答を得られました。 Watson Discovery の検索結果に基づき watsonx.ai で回答を生成するので、ある程度時間がかかると予想していましたが、elyza-japanese は速い回答で主語を添えてわかりやすく回答してくれました。 また、llama-2-70B は汎用的で使いやすいモデルですが、プロントで「日本語で回答して」と指示をしても問い合わせ内容によっては英語で回答することがありました。日本語の回答精度を求める場合は、Granite-japanese や elyza-japanese を使用した方が精度の高い回答を得ることができます。 モデルを変えて問い合わせてみると、モデルごとに得意なタスクが異なることがわかりました。数百億のパラメータで訓練された大規模言語モデルを一概に選択するのではなく、言語やタスクの特性に合わせて最適なモデルを選定することが重要になりそうですね。 さいごに いかがでしたでしょうか。Github から提供されているスターターキットを使って Assistant、Discovery、watsonx.ai を繋げてみましたが、ほどんど躓くことなく UI から簡単に設定することができました。 接続自体に高度な難しさは感じませんでしたが、問い合わせに対して正確な情報を得るためには Assistant の検索設定を調整する必要があります。今回は1つの PDFファイルの検索を行いましたが、複数の PDFファイルから情報を引き出す際には Assistant で query を設定することで特定の PDFファイルからの検索が可能です。 このように PDF などの非構造化データを検索対象として精度の高い回答を得るには、Discovery において文書の構造を明確に定義し、Assistant の検索設定を調整することが必要です。 実際にヘルプデスクなどの Webチャットで利用する場合は、Assistant にあらかじめ用意した回答をルールベースで回答させ、それでも解決できない問い合わせについては Discovery を通じて検索を行い、watsonx.ai を用いて回答を生成するという流れが効果的です。 ただし、生成AI によって生成される回答は常に”100%正確な回答”ではないので、より高い精度の回答を追求するためにはプロンプトの調整などチューニングを施すことが必要です。その結果、より使いやすい Webチャットの実現が期待できます。 お問い合わせ エヌアイシー・パートナーズ株式会社E-Mail:nicp_support@NIandC.co.jp   .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }

2024年01月16日

【イベント開催レポート】IBM watsonx.ai ハンズオンセミナー

こんにちは。ソリューション推進部です。 2023年12月12日に、エヌアイシー・パートナーズ株式会社として初めてのハンズオンセミナー『「IBM watsonx.ai 」を利用したRAGのハンズオンセミナー』を開催しました。 今回のハンズオンセミナーは、以下の2つのことを目的として行いました。 パートナー様に製品の紹介とハンズオンを合わせて体験いただくことで、製品をより深く知っていただくこと 製品を活用したビジネスの新たな応用の可能性を見つけ出していただくこと 私たちのチームでは、パートナー様にご紹介・ご説明する製品を「実際に触ってみること」を大切にしています。これは私たち自身の技術力の向上という目的もありますが、パートナー様に私たちのリアルな経験を交えながら製品のご説明をすることが、お客様の具体的な課題発掘や案件創出に繋がっていると考えているためです。 今回のハンズオンを通して、パートナー様ご自身が製品の価値を体感しご理解いただくことで、新しいビジネス展開のイメージを創出するお役に立ちたいと考えました。 それでは、今回実施したセミナーの内容について簡単にご紹介いたします。 目次 レポート watsonx.ai紹介講義 ハンズオン実施 IBMさまによる最新情報紹介・講義 さいごに お問い合わせ レポート 1. watsonx.ai紹介講義 ハンズオンを実施する前に、watsonx.ai と RAG についての講義を行いました。 国内では生成AIビジネスが加速し、競争力やセキュリティなどの課題が増えています。これらの課題を解決する製品として、IBM watsonx をご紹介しました。 watsonx は「watsonx.ai」「watsonx.governance」「watsonx.data」という3つの製品から成り立っています。watsonx.ai は、基盤モデルをベースとした AI開発スタジオです。 ここでは、IBM が信頼できるデータを用いて事前に学習した基盤モデルや Hugging Face, Inc.* と連携したオープンソースの基盤モデルが利用可能で、ビジネスの状況や要件に応じて最適な基盤モデルを選択することが可能です。 また、RAG についての概念や利点、活用が期待されるシーンもご説明しました。RAG を用いた具体的なユースケースとしては、IBM Watson Speech to Text や Watson Discovery、watsonx.ai を活用したコールセンター業務の事例や、watsonx Assistant や Watson Discovery、watsonx.ai を活用した ECサイトの問い合わせの事例を取り上げました。 時間の制約からこれら2つの事例しかご紹介できませんでしたが、今後、watsonx.ai を活用した多様な事例を私たち自身も理解し、パートナーさまと共に議論を深めていきたいと思います。 *Hugging Face, Inc.:機械学習 アプリケーションを作成するためのツールを開発しているアメリカの企業。 2. ハンズオン実施 ハンズオンでは、受講者の方々に「RAG」を活用した watsonx.ai の Foundation Model(LLM)への問い合わせを体験していただきました。 RAG とは「Retrieval-Augmented Generation」の略で、LLM への問い合わせをする際に、事前に用意したベクターストアへデータ(今回はPDF)を取り込んでおき、問い合わせプロンプトをもとにベクターストアを検索し、その結果を付与して LLM へ問い合わせを行う、というテクノロジーです。 RAG を使うことで、一般公開されていない社内情報を活用して LLM を利用することが可能となるため、自社での利用やお客様の課題を解決するための方法として有効であると考えています。 ハンズオンの環境につきましては、準備に時間をかけずスムーズに始められるよう、事前に弊社にて PC や RAG を利用するための Jupyter Notebook を用意いたしました。 また、watsonx.ai では複数の Foundation Model を利用できるため、複数のモデルを使って挙動の違いを確認してみたり、取り込む PDFファイルを追加することで回答がどう変わるのか、など、ご自身で自由に検証をする時間を多く設けました。皆さまそれぞれに前提スキルは異なっていたかもしれませんが、「体験の時間が足りない…」ということはなかったかと思います。 今回ベクターストアへ取り込むのは PDF のみとしましたが、テキストファイルや PowerPoint なども取り込むことができるので、応用できる使い方が非常に広いということを理解いただけたのではないかと感じています。 3. IBMさまによる最新情報紹介・講義 日本アイ・ビー・エム データ・AI・オートメーション事業部 四元さまに「watsonx」に関して、最新事例と製品アップデート情報の2本立てで講義をしていただきました。 事例においては、IBM社内の watsonx活用事例(AskIT)は特筆すべきと言えるでしょう。 AskIT は、IBMの自然言語処理(NLP)能力を活かし、30万件を超えるサポートチケットから抽出された知見をもとに、重要なサポートトピックに迅速に対処する AIアシスタントとして開発されたそうです。このツールは4ヶ月で133,000人の IBM社員に利用され、問い合わせの75%以上が AI によるチャットで解決されるなど、非常に大きな成果を上げています。 製品アップデート情報のメインは、12月に発表された「watsonx.governance」でした。 AI を組織として採用するためには倫理感のある意思決定が必須であり、watsonx.governance は AIガバナンスとして以下の3つの機能を提供する製品である、というご説明をいただきました。 AIライフサイクルを通してAIモデルの実態を把握するための「モデル・インベントリ」 AIの性能や課題の管理などを行う「評価・モニタリング」 総合監視画面を提供しリスクを可視化する「モデル・リスクガバナンス」 モデル・インベントリでは、他社の AI商品である「Amazon SageMaker」「Azure Machine Learning」などの AIモデルも合わせて管理・監視できることが非常に興味深いです。 watsonx は、AIワークフローを一貫してサポートすることで倫理的かつ透明性の高い AI利用を可能にしています。これらの技術革新は私たちが直面している数多くの課題に対する解決策を見出し、先進的なビジネス環境を促進していく上での重要なステップと言えるでしょう。 日本アイ・ビー・エム株式会社 データ・AI・オートメーション事業部 四元 さま さいごに セミナー後には、参加いただいたパートナーさまとご支援いただいた IBMさまとの懇親会を開催いたしました。 当懇親会を通してパートナー様の生成AI に対する取り組みや課題を直に伺うことができ、大変有意義な場となりました。 2023年12月18日に弊社は10周年を迎えました。10年間で培った経験を糧にし、今後さらに新しい取り組みにチャレンジしていきたいと考えております。 本年も、ブログを通してパートナーの皆さまへ様々な情報をお届けさせていただきます!今後ともどうぞよろしくお願いいたします。 懇親会会場 お問い合わせ エヌアイシー・パートナーズ株式会社E-Mail:nicp_support@NIandC.co.jp   .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#eb6100; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }

back to top