技術情報 の記事一覧

10月19日（木）に開催された「技育CAMPアカデミア -Vol.05」においてデベロッパーエキスパートの津田 良太郎が登壇し「Web3Dグラフィックス表現でライバルに差をつけろ！」というタイトルで勉強会を開催しました。イベント告知：https://developers.gmo.jp/38829/ 大テーマ「Web + α」 ECサイトで家具を買う際に、ARで部屋に配置してみたり、古代の生物を検索した際に360度からグリグリみれる図鑑に早変わりしたりと、ただの二次元平面情報表示装置としてのブラウザ・Web技術ではなくなってきています。 そのような技術が進む中で、日ごろ自分のエンジニアのテーマとして「Web + α」を軸に開発業務に携わっていることもあり、今回の技育祭で取り扱う内容も「Web + α」な内容にしました。これまで一方向から双方向、中央集権から分散とWeb1.0,Web2.0,Web3.0とWebの役割がアップデートされてきたことに付随して、Web技術の役割や表現も拡張されてきています。 今回のセッションではそのWeb表現であるCGに焦点を当て、「Web + CG」の力を駆使して表現力を身に着けようというお話をさせていただきました。 登壇者 GMOインターネットグループ デベロッパーエキスパート（Webフロントエンド, WebGL）GMOグローバルサイン・ホールディングス株式会社津田 良太郎 / Ryotaro Tsuda（@utautattaro） セッション「Web3Dグラフィックス技術でライバルに差をつけろ！」振り返り Web と CG WebとCGは生まれてきた目的や用途の違いからひとえに比較可能な技術ではありませんが、あえて本セッションではWeb（フロントエンド）技術、3DCG技術の両者の違いと意外な共通点についてまず説明しました。 まずWebと3DCGを区別するうえで最も大きな違いは駆動方式です。イベントドリブンであるWebとループドリブンであるCG。それぞれの駆動方式はニーズに合わせて成長してきたものですがWebとCGを融合するうえでは理解しておく必要があります。 またどちらにも「レンダリング」という言葉が存在しますがその意味も決定的に違います。Webの世界でのレンダリングとは「HTMLを生成すること」を指していますが、3DCGのレンダリングでは「3次元情報を2次元情報（ピクセル列）に当てはめていく作業」を指しています。Webの世界のSSRという用語をCGエンジニアが聞くと、「レンダリングしているのはブラウザなんだしサーバーサイドレンダリングじゃないじゃん」となってしまうわけですね。 このように技術的・文化的背景の違いから用語のズレなど、両者には少なくない違いがありました。 意外な共通点 ですがこの両者には意外な共通点がありました。それは「標準化」です。 Web技術はW3CやWHATWGなどが定義しているWeb標準APIを利用して開発を行います。ベンダー依存された独占的な技術を中心に回るのではなく、あくまでWeb標準、オープンな世界で標準として使っていこうという流れがあります。 対して3DCGにもグラフィックスAPIが用意されています。こちらはWeb技術とは違い、難解な3DCG技術を誰でも簡単に扱えるようにするため　という目的で始まった文化ですが現在では3DCGは基本的に何かしらの3DグラフィックスAPIを用いて実装がなされています。結果としてそれらは標準化され、多くの開発者は同様のAPIを用いて開発を行っています。 歩み寄りの歴史 2011年に、Web標準の3DグラフィックスAPI WebGLが登場しました。 Web標準化団体が定義する、3DグラフィックスAPIの登場で、Web＋CGの開発方法は確立しスタートしました。 現在はより高速化し汎用的になったWebGPUも登場し、WebとCGの世界はより融合してきています。 Web3DCGコンテンツを作りやすくするために、WebGLライブラリも多く登場してきています。Webコンテンツを開発しやすくするためにWebフレームワークが多く登場したように、WebGLライブラリの融合も相まってより開発の敷居が下がっています。 これまで別々の文化的技術的背景から生まれてきた二つの技術も、今ではこうして標準化され、広く普及してきています。 未来の話：WIth AI ! 冒頭でも話した通り、Web技術は今は四角い画面の二次元ピクセル列に収まりません WebGLはほとんどのプラットフォームで対応し主要なブラウザはほぼすべて動作する標準環境になりました。AppleのVision proやMeta Questをはじめとするデバイスでも動作するため、Web3DCGコンテンツを「見る」環境は広がってきています。 対して、「作る」技術はどうでしょうか？ WebGLライブラリの登場により開発の敷居は下がったものの、3Dコンテンツの元となるデータ（アセット）の作成はこれまで3Dモデラーと呼ばれる職種の力が必要でしたし、実データの3D化も高価な深度カメラが必要でした。 ですがAI進歩の流れにより3Dアセット作成もより民主化されてきています。Stable diffusionやDALL-Eなど画像生成AIが有名ですが、3Dに転じた3D生成AIも登場してきています。精度の課題はありますが、解決されればまさしく無から有を生み出す手法の決定版として有用でしょう。 対して実在のものをデジタルで再構築する、デジタルツイン（デジタルの双子）も大きな技術的進歩を遂げています。まずAppleが進めている深度センサLiDARを利用した手法では、民生品であるiPhoneに搭載されているので誰でも使えるようになっている上、Object Captureというアプリを利用することで簡単にデジタルツインが作成できるようになっています。 また機械学習を利用したアプローチでは3D Gaussian Splattingが強力な候補として挙がってきます。複数の画像データを学習し、点群データ化することで、誰でも簡単に動画や複数画像からフォトリアリスティックな3Dシーンが作成できます。 このように特殊なスキル・特別な機器がなくとも誰でも3Dデータが作れる3Dの民主化は、今まさに進行しています。 あとがき 以上駆け足になりましたがこれまでの歴史的背景から現在・未来の話へとまとめさせていただきました。この資料はもともと自分が3DCG系のエンジニアからキャリアをスタートし、Webフロントエンドエンジニアとしての技術も蓄えていった視点で、自分が困ったこと　戸惑ったこと　感じたことをベースにまとめさせていただきました。 最後にお話した未来についての話が、自分にとってはここ数か月の話ですがこれまでのキャリアで最も衝撃を受けています。これまではどうしても専門職　というイメージがぬぐえなかったIT技術職がAIの力で誰でもなれる環境に近づき、さらに専門職であった芸術関連やカメラ技術などもAIの力により民主化が進んでいます。 これらはWebエンジニアにとっては福音で、誰でもこれまでになかったWeb表現を生み出すことができるチャンスが広がっています。3DCG表現は一部のプロフェッショナルだけの専売特許ではなく、AIなど新規技術を利用することで簡単に扱えます。ぜひここで興味を持っていただいて、ライバルに差をつけられる一つ上の表現を身に着けてみてはいかがでしょうか！

こんにちは。新里です。今年の10/14（土）10/15（日）に東京ビックサイトでMaker Faire Tokyo 2023が行われました。また、今年は米国でMaker Faire Bayarea 2023が復活して勢いでエントリーしたら通ったので、10/20-22までMare island, Vallejoで展示を行ってきました。正確には最終日に風邪っぽくなってダウンしてしまいましたが。展示したものや、見て回ったものでも紹介しようかと。 Maker Faire ってなに？ DIYやモノづくりをしている人達（Maker）やギークが作った作品を持ち寄って展示するイベントですね。世界各地で開催されていて、日本では東京・京都・大垣・山口・浜松など各地で行われています。開催地情報を見てみると、世界各地で開催されていることが分かりますね。 Maker Faire Bay Area Maker Faire Bay Areaは2019年を最後に終了しましたが、今年からまた再開することに。2019年まではSan Mateoの会場で昔はIntel、NVIDIA、Google、ARM、Microsoft、Texas InstrumentsといったBay Area周辺のビックテックがスポンサーになって展示もしていました。 Maker Faire Bay Area 2016 Maker Faire Bay Area 2018 Maker Faire Bay Area 2019 今年のMaker Faire Bay Area/Mare island 未踏で制作した物を持って展示しに行ってきました。スピーカー類を大量に持っていくのは大変でしたが、何とか持っていけました。 色々面白い制作物にも出会えて写真を大量に撮ってきたので、少し紹介します。 これはSepia Luxという巨大な作品でした。去年のBurning Manでも展示されていた作品のようですね。タブレットからリモートで色を変えたり目玉の表示を変えれたり、なかなかの大作でした。 こちらは個人制作物のヒト型ロボットでKind Humanoidという作品でした。頭部に複数のAIプロセッサ（RPi4のように見えましたが、聞いたらRPiではなくAIプロセッサとのことでした）が搭載されていて、動画を見るとなかなかこれも面白そうです。 チカラこそパワー！！とでも言っているような車ですね。Project Empireという作品でエアロスペースパンクというジャンルを確立しようとしているみたいです。 所感として... 久しぶりにMaker Faire Bay Areaに参加してみて、勝手に思っている展示の3要素である、「デカい・光る・音がなる」というのを直接感じることが出来ました。Maker Faire Bay Areaにビックテックのようなスポンサー・展示が再びやってくることはあるのかどうか？興味津々だったりもしています。

10月17日（水）に開催された「技育CAMPアカデミア -Vol.04」においてデベロッパーエキスパートの駒井 直が登壇し「あなたのプログラミングを仕事のコードにするためのTips集」というタイトルで勉強会を開催しました。イベント告知：https://developers.gmo.jp/37619/ チームで信頼されるプログラミングの考え方をお見せしたい 技育CAMPアカデミアシリーズ、自分のテーマは学生さんの日常的なプログラミングでは恐らく気にしない（であろう）仕事の現場で気遣いしてくれると嬉しいポイントについて、簡単な問いを投げかけ思考してもらいながら紹介していきました。エンジニアの卵である参加者の皆様が、未来に"頼れるね、助かるね"と言ってもらえる助けになると良いな、という思いでお話ししました。 登壇者 GMOインターネットグループ デベロッパーエキスパートGMOペイメントゲートウェイ株式会社駒井 直（本稿執筆者） セッション「あなたのコードをプロのコードにするtips集」より 誤解を解く（あるいはプロを地続きに感じる） 冒頭5分くらいのスライドから抜粋です。能力や素材の良さとそこから生まれる結果は全く別の出来事で、プロの仕事で問われるのは後者ですよ、という事を前置きしました。参加者は学生さんですから、現時点で分かりやすい指標を持っていない事に不安があるかもしれません。先輩として、それらは"そんなこともできるんだ"という指標であって、作ってほしい価値ではない。価値から逆算していこう、という事をお伝えしたかったのです。 上図における”能力”の部分を伸ばすこと自体は、仕事の結果と何ら矛盾するものではないので、個人が能力を研鑽する事は前提なんだよ、という事もお伝えしました。 具体例を問いかける ここから、いくつか参加者の皆様に問いかけながら、気遣いポイントを示していきました。スライド抜粋します。 プロの仕事はチーム戦 身に覚えあり過ぎるやつ。今でも油断するとやってしまうかも。 はいそうですね、としか言えないコメントはディスクの無駄 コメントは思考のログ。半年後の自分は別人。 プロの現場で仕事をするのはチーム戦。自分以外のチームメイトを意識して作り上げていく事は、参加する学生さんの授業や自宅の開発ではあまり意識しないかなと思います。現場でリアルに助かる事としてお伝えしました。コードの職場見学ですね。 プロの仕事は長期戦 もう1例、スライド抜粋します。 サンプルの力尽き感。もう1つくらいミスリードを仕込めばもっと面白かった。 ここしか指摘箇所ないから、そりゃそうでしょう。反省しています。 経験者から見れば、当たり前ではある 今この瞬間動くことではなくて、将来にわたってなるべく長く動くための配慮をして欲しい。プロの仕事は長期戦。今現在の計算やロジックで未来の姿を表現することがプロのエンジニアの気遣い、違い＝価値なんです、という事を（大分デフォルメした）例でお伝えしました。 この視点。もう一例、検索APIのindex/non-indexによる仕事量の違いをお話ししました。 トラブル発生時や新規事業の立ち上げフェーズなど、技術的な選択基準が瞬発力一択になる場面は存在します。しかしながら、この点を軽く見てしまった結果のリアルも見ているので、インターネットの場を提供する事業の真ん中で働く自分の経験として、将来ある参加者の皆様にはぜひ植え付けたい視点でした。 セッションの締め 本セッションはこう締めました。 伝わったかな 登壇後記 今回の内容は、自分が毎年担当する社内新卒研修のコードレビューにおける、フィードバック頻出事項のまとめが下地です。大仰なタイトルに対して、お話ししたのは地味な内容です。今回出演したのは技育（Geek）campであって、その名の通りdive deepな尖ったテーマにすべきか迷いましたが、参加者の現在地から仕事場でコードを書く姿までをできるだけ地続きにしよう、それが自分が一番実感を持ってお届けできる事と思いこのテーマにしました。（dive deepは歴戦のdeveloper expertsにお任せします！） 結果、多数の学生さんに参加していただき、参加後のコメント率も良好だったので、セッションの終わりまで興味を持っていただけたようで安心しました。ソースコメントのくだりに"やさしさコードですね"と参加者からzoomチャットを頂き、そのフレーズを先に自分が思いつきたかったなぁ。。。そんなやり取りなど、参加者の素直な好奇心に講師側が助けていただきました。"君のコードは実践的で安心できるね"と一度でも言ってもらえたら。参加者の将来にそんな形でお返しできたなら冥利です。

10月5日（木）に開催された「技育CAMPアカデミア -Vol.03」においてデベロッパーエキスパートの三村 聡志が登壇し「コンピュータの仕組みを知ろう」というタイトルで勉強会を開催しました。勉強会では、普段あまり気にしないようなコンピュータ内のデータの保存の仕組みからOSの仕組みまでを紹介しました。イベント告知： https://developers.gmo.jp/37769/ 登壇者 GMOインターネットグループ デベロッパーエキスパート三村 聡志（@mimura1133 / 親方） 実際に動いているものを見てコンピュータの見方を広げる 今回の勉強会では「実際に動いているものから仕組みを知る」ということにフォーカスを当てました。いくつか勉強会の資料のスライドを用いて説明します。 たとえば「コンピュータが『0』『1』の2つの値の組み合わせで動いている」という話は、学校の技術の教科書にも掲載されているほど、コンピュータの説明としてよく登場する話です。 では、実際にどういう信号が「0」と「1」になっているのでしょうか。下記の右下の図を見てみましょう。よく見ると波形が表示されていることに気づきます。 この波形は、左の図の装置で記録した実際の通信データであり、実際にUSBキーボードの通信を記録したものになります。 コメントを入れて読みやすくしたものが下図になります。（上図で掲載の波形とは少々異なります） 色々とアルファベットが書き込まれていて複雑になってきました。もちろん、今回の勉強会では、このような波形を読めるようになる事はゴールとはしていません。 今回の勉強会では「実際にはこういうことが起きている」とか「教科書に載っているような理想との差（たとえば波形が矩形波ではないということ）がある」ということを知ること、そしてこのような基礎技術の存在を知り見方を広げることが今回の勉強会の大きなテーマでした。 身近なものから高度な技術まで 今回の勉強会では下記の4テーマに触れて進めました。このうち後半の3テーマについて順を追って説明します。 2進数・「0と1」ファイルの中身（フォーマット）プログラムの動く仕組みOSの仕事 ファイルの中身（フォーマット） ファイルの中身をバイナリエディタを用いて開きその特徴を調べました。 まず Bitmap ファイル (BMP) の場合。（ここでは分かりやすくするために 24bit フルカラーのファイルを用います。）下図に示すように、光の三原色がそれぞれ 1バイト (=8bit) で表現されていること、また書き換えるとその部分がそのとおりに色が変わることを紹介しました。 またファイルによっては特徴的なデータ列 (magic) が含まれる場合や、文字列として中身が見える場合などがあり、そのような特徴がファイルによって存在することを確かめました。 プログラムの動く仕組み ここでは nasm を用いて、実際にアセンブル・および逆アセンブルを実施して、簡単なプログラムの作成と解析を行いました。 高度なプログラムも簡単な操作を複数組み合わせることで成り立っていること、そしてもちろん現在のPCで動作するプログラムも基本的な考え方は同じであることを紹介しました。 OSの仕事 ハードウェアの抽象化・リソース管理・スケジューリングについてこれまで話をしてきたことを組み合わせながら説明を行いました。 OS側でケアをすることにより、機器毎の違いをアプリケーションの開発者が気にしなくてもよくなっていること、複数のプログラムを起動しても動いていることなどを実例を交えて説明を行いました。 さいごに 今回の内容は1時間としてはとても濃い内容になっていたと思います。また演習環境の準備の関係上、勉強会の時間内では手を動かせなかったかたもいると伺っています。 いくつかの準備不足等はありましたが、資料は参加者のみなさんには公開していますので、少しでも興味関心が湧く所やもう少し掘り下げてみたいと思える場所が今回の内容から見つかれば嬉しいと思っています。

こんにちは、GMOインターネットグループ株式会社の長谷川です。今回は ConoHa のインフラ特に公開APIに関してお話して行こうと思います。 ConoHa の API とは ConoHa VPS は、OpenStack を採用しています。OpenStack 準拠の API を公開しており、コントロールパネルで提供されている機能のほか、VPS の構築やネットワークの設定などのシステム構築に直接関わる部分から、ユーザー情報や請求情報といったアカウント管理などが操作でき、効率良くサーバー管理・運用をすることができます。https://www.conoha.jp/vps/function/api/ どうやって API インフラを実装していくのか まず前提として以下の理由から素の OpenStack API をそのまま提供するということはありません。 課金データが OpenStack API 単体では管理できないからセキュリティーの問題冗長性やパフォーマンスの問題 上記の理由から LVS, HAProxy, API ラッパーを使い冗長構成やセキュリティーの課題に対して対応していきます。 LVS, keepalived, HAProxy とは何ぞや？ LVSLinux virtual server のことで Linux の負荷分散ソリューションの一つ。LVSは IPVS (IP virtual server) と ipvsadm ユーティリティから構成されており layer4 の負荷分散を提供する。 keepalivedLVS と一緒に使われ VRRP などの protocol を利用し、LVS サーバを監視して冗長化を行う。 HAProxy高可用性、負荷分散を提供するプロキシ兼ロードバランサーである。layer7 の負荷分散を可能にしている。 インフラ構成 上記は API を公開する際の基本的な構成の一部になります。LVS & keepalived により、HAProxy に VIP（Virtual IP）を付与します、これにより片系の HAProxy が落ちたとしても VIP 経由のアクセスは切り替わり継続してサービスの提供を行うことが出来ます。 また、LVSとkeepalived 自体も2台でHAの構成を取ることにより冗長性を高めています。 アクセス時の流れ（リクエスト時） 1.APIのエンドポイントにクライアントからアクセスします。 2. クライアントからアクセスを受けるとエンドポイントの FQDNはVIPに名前解決され、リクエストは VIPに流れます。VIPは負荷分散も兼ねているので、VIPに来たリクエストは2台あるうちのどちらかの HAProxy に流れます。 3.HAProxyは設定ファイルに記述されたACLを読み込んでアクセスの許可、どのバックエンドにリクエストを送るのか、それぞれのバックエンドに合わせたパスの書き換え等を行います。 4. HAProxyでは複数のバックエンドを後ろに置くことが出来ます。よって、エンドポイントごとやメソッドごとにリクエストを転送する先のバックエンドを切り替える事が出来ます。（エンドポイントとメソッドによってAPIラッパーに転送したり選ぶことが出来ます。） アクセス時の流れ（レスポンス時） 上記の図のように レスポンスをクライアントに返すときは、バックエンド → HAProxy の経路をたどりその後 Direct Server Return （DSRと呼ばれます）で HAProxy から直接クライアントにレスポンスを返します。 レスポンスを DSR で返す理由は、レスポンスに使われる経路が減ることにより負荷の軽減や処理速度の向上につながるからです。 全体的な構成 実際に運用する際の構成では internal（スタッフアクセス用 API ）, external （お客様アクセス用 API ）で上記のセットが 2つ必要になります。また、兼用されるものもあるため internal, external を合わせた構成は以下のようになります。 LVSとHAProxyの構成図（internal&external） 上記の図に関しては、最低限の 1セットの構成を図で示したものとなります。システムの要件により、この構成のセットが増えていきます。アクセス数が多い API のエンドポイントやファイルアップロード等の負荷のかかるエンドポイントでは上記のシステム構成を別で持ち、通常系の API と分ける事により負荷の影響が他のエンドポイントに及ばないような設計になっています。 まとめ ConoHa API のシステムに関して、簡潔に解説しましたがどうでしたでしょうか？API エンドポイントの負荷対策やセキュリティーは重要なものとなり、今回解説した部分は一部でしかありませんが、解説した仕組みを用いてお客様が使いやすいよう API を提供しています。是非 ConoHa で API を利用して VPS の操作を自動化してみてはいかがでしょうか？

こんにちは、GMOインターネットグループ株式会社 フロントエンドエンジニアの浦田です。ConoHaは現在、大進化の時期に差し掛かっており、チーム一同大奮闘中でございます。そんな中で今回は、ConoHaコンパネのシステム設計やGUIアーキテクチャパターンについて入社一年目で学んだ内容を共有したいと思います。 はじめに ConoHaコントロールパネルでは、ドメイン駆動設計を使用し、「保守性」「再利用性」「拡張性」が高くい変化に強いソフトウェアの設計を心がけております。 本記事では、ドメイン駆動設計をベースに、GUIアーキテクチャなどフロントエンドにおけるソフトウェアの設計についてメリット・デメリットとともに解説したいと思います。 ドメイン駆動設計 システムにおけるドメイン駆動設計について少し解説したいと思います。ビジネスドメイン（業務領域）を中心に据え、ビジネスルールやプロセスをソフトウェア設計に反映させます。これにより、開発者はビジネス要件に集中し、ドメインの理解を深めながら柔軟かつ効果的なソリューションを構築を行うことができます。問題領域の複雑さに対処し、ソフトウェアの保守性、再利用性、拡張性を備えた変化に強いソフトウェア設計です。 コンパネ開発においてドメイン駆動設計のメリットデメリットを現場の声とともにまとめてみました。 メリット 書くところ（クラス）が決まっているので簡単要件を正確に反映させたモデルを作成できる保守性と可読性の向上 デメリット 複雑性の増加・実装量が多い学習コストが高い ユビキタス言語の意識から可読性が高く、要件が分かりやすいクラスは、実装者と事業者とのやり取りをよりスムーズなものにできていると感じています。 MVP ConoHaではGUIアーキテクチャーパターンを使用して、フロントエンドの設計を行っています。パターンには様々あり、原点となるMVCパターンは、ユーザの入力をControllerが受け取り、ControllerがModelを操作し、その結果をViewでユーザーに返します。ConoHaではControllerがViewに組み込まれ、PresenterがModelとViewの制御を行うMVPパターンを採用しており、踏襲した形で一部にアレンジを加えています。フロントの設計方針（クラスの定義）についてはこちらに記載してありますのでご覧ください。以下ではフロントにおける「保守性」「再利用性」「拡張性」についてまとめてみました。 保守性： View: 画面描画や情報取得を集約し、変更があってもViewのみに影響を与えるため、保守性が高まります。Presenter: EventHandlerとの連携で、必要な変更点が限定され、変更時の修正範囲が明確です。Repository: インターフェース経由で参照するため、バックエンドの変更があっても影響が局所的で、保守作業が容易です。 再利用性： Selector：セレクタや属性の定義を一元管理し、再利用と保守が容易です。変更が必要な場合、Selectorのみを修正すれば済みます。Repository：インターフェースによって異なるバックエンド実装を切り替えやすく、コードの再利用性を高めます。 拡張性： EventHandler：新しいイベントの追加や既存イベントの変更が可能で、システムの拡張が柔軟です。バックエンド通信の追加もPresenterを介して容易に行えます。 この設計において、各要素の役割分担が明確であり、変更に対する影響範囲が限定的なため、保守性が高まり、再利用性と拡張性も確保されています。以上の設計を実際に実装して感じた、メリットとデメリットをまとめてみました。 メリット 実装者間のバラつきが少なくなった可読性の向上モジュールが独立しているため、修正が他の部分に影響を与えにくく保守性が向上する デメリット 実装量が多い学習コストが高いことファイル数が増えたのでコンパイルに時間がかかるようになった気がする... おわりに いかがだったでしょうか。 以上が、ConoHaコントロールパネルのフロント設計になります。皆様により長くConoHaをご愛顧いただけるよう、私自身、まだまだ駆け出しのフロントエンドエンジニアではありますが、日々奮闘していきたいと思います。

初めまして！GMOインターネットグループ株式会社、新卒2年目の江﨑です。今回は初心者が一から負荷テストについて学び、実施した経験についてお話しします。 はじめに 今回、オンプレミスのサービスのクラウドリフトに伴って負荷テストを行う必要がありました。私は普段、フロントエンドエンジニアとしてサービスのUI改善を行っており、負荷テストは未開の領域でした。そのため、一から負荷テストについて学び、多くの知見を得ることができたのでこれから学ぶ方の参考になればと思い、執筆させていただきました。 使用ツール Distributed Load Testing on AWSApache JMeter 今回はAWSが提供する Distributed Load Testing on AWS を用いて実行環境を簡単に構築し、細かいシナリオは Apache JMeter で作成しました。 ■Distributed Load Testing on AWSDistributed Load Testing on AWS ソリューションは、大規模および負荷時のソフトウェアアプリケーションテストを自動化して、リリース前に性能上の潜在的なパフォーマンスの問題を特定するのに役立ちます。このソリューションは、一定のペースでトランザクションレコードを生成する数多くの接続ユーザーを作成およびシミュレートします。サーバーをプロビジョニングする必要はありません。また、このソリューションでは、複数の AWS リージョンにまたがってテストを実行することができます。詳細：https://aws.amazon.com/jp/solutions/implementations/distributed-load-testing-on-aws/ 公式では上記のように紹介されています。 Distributed Load Testing on AWS 構成図 サーバーレスな負荷生成コントローラー・エンジン & Web UI を提供しています。（コントローラーは Taurus を使用）既存サービス（負荷テスト先）のクラウドリフトで忙しい中、負荷テスト元の実行環境を一から構築するとなると途方に暮れてしまいます。そんな手間を省いてくれる便利なツールとなっています。下記公式ガイドから簡単に環境構築できる AWS Cloud Formation を立ち上げることができます。実装方法の詳細については公式ガイドをご覧ください。https://d1.awsstatic.com/Solutions/ja_JP/distributed-load-testing-on-aws.pdf ■Apache JMeterApache JMeter™ アプリケーションはオープンソースソフトウェアであり、機能動作の負荷テストとパフォーマンスの測定を行うために設計された100%純粋なJavaアプリケーションです。元々はWebアプリケーションのテスト用に設計されましたが、その後他のテスト機能にも拡張されました。詳細：https://jmeter.apache.org/ 公式では上記のように紹介されています。GUIで直感的に操作ができ、プラグインを用いて様々なシナリオを作成できます。メジャーなツールであるため、ネット上に多くの記事が公開されています。また、日本語にも対応しているため英語が苦手な私でも難なく利用することができました。 シナリオ作成 シナリオは負荷テスト先のアプリケーションによって異なるので、今回は使われる機会が多いと思われる機能を抜粋して紹介します。 Thread Group Thread Group ・スレッド数や Ramp-up 期間、ループ回数を設定する機能・今回は Distributed Load Testing on AWS で設定するため全て 1 に設定 HTTP Cookie Manager HTTP Cookie Manager ・Cookie を使用する場合に必要となる機能・自動取得された Cookie はスレッドごとに管理される HTTP Request HTTP Request ・GET や POST などアプリケーション内で想定するユーザーのリクエスト内容を設定・ユーザーが行う一連の流れを作成することで解像度の高いシナリオを作成できる Regular Expression Extractor Regular Expression Extractor ・HTTP Request で取得した Body や Response Header から値を正規表現抽出する・上の画像では input 要素から value 属性の値を抽出して TOKEN 変数に代入している 他にも様々な機能があるので負荷テスト先のアプリケーションに合ったシナリオを作成してみてください。 負荷テスト実施 Distributed Load Testing on AWS に作成したシナリオをアップロードして負荷テストを行っていきます。 Create Load Test Task Count・負荷エンジンとなる Fargate タスク数Concurrency・タスク毎に生成される仮想ユーザー数・Task Count × Concurrency = 同時接続数Ramp Up・Concurrency に達するまでの時間（0 以上, 単位：秒 or 分）・Ramp Up 時間を増やすと徐々に負荷がかかるHold For・Concurrency を維持し続ける時間（1 以上, 単位：秒 or 分）・Ramp Up 10分 + Hold For 50分 = 負荷テスト 1時間 上記項目入力後、Apache JMeter で作成したシナリオをアップロードして実行するだけで負荷テストが行われます。 負荷テスト結果 Test Results Avg Responce Time・すべてのリクエストの平均応答時間（秒）Avg Latency・すべてのリクエストの平均レイテンシ（秒）Avg Connection Time・すべてのリクエストについて、ホストへの接続にかかった平均時間 （秒）Avg Bandwidth・すべてのリクエストの平均帯域幅Total Count・リクエスト総数Success Count・成功したリクエスト総数Error Count・エラー総数Requests Per Second・すべてのリクエストの 1 秒あたりの平均リクエスト数Percentile Responce Time・テストの応答時間のパーセンタイル値（最大応答時間は 100%、最小応答時間は 0%） Error が発生していたり、Responce Time が異常に遅い場合は負荷テスト先のアプリケーションでボトルネックが発生しているため解消する必要があります。今回は Amazon CloudWatch や AWS X-Ray でボトルネックを確認し、クラウド環境の構成を見直し、修正しました。その後再負荷テストを行い、問題が無いことを確認してからアプリケーションのリリースを行いました。 おわりに 今回の経験を通して、負荷テストはお客様に安定したサービスを提供するための指標となることを学びました。正常に稼働しているシステムでも、負荷の大きいリクエストを送られたり、長時間稼働し続けるとエラーを出してしまいます。そういった不測の事態を避けたり、システムの限界を把握しておくためにも、リリース前の負荷テストは重要です。今回ご紹介したように、面倒な環境構築を行わずとも負荷テストを実施できる便利なツールが世の中には存在しますので、皆さまも是非、自身のサービスに対して負荷テストを行ってみてはいかがでしょうか。

9月26日（火）にオンラインで開催された「GMO Developers Night #38」では、オンライン総合決済サービスを展開するGMOペイメントゲートウェイ株式会社が登壇。決済代行業界初のサポートセンター国際認定を取得したカスタマーサポートの裏側について紹介しました。イベント告知：https://developers.gmo.jp/37658/ 登壇者 GMOペイメントゲートウェイ株式会社 システム本部 カスタマーサポート 部長　田中 弘道テクニカルサポートグループ　佐山 量哉サポート企画グループ　土屋 優希コンタクトグループ 課長　寺村 杏里 笑顔の絶えないハイクオリティなサポートセンター 冒頭では、田中がGMOペイメントゲートウェイ株式会社（以下、GMO-PG）およびカスタマーサポートの概要や特徴について説明しました。 GMO-PGは、オンライン事業者・公的機関等の加盟店に対し総合的な決済関連サービスを提供しており、社名のとおり加盟店と決済をつなぐゲートウェイの役割を果たしている会社です。2023年6月末現在においては、連結加盟店舗数15万5598店、年間連結決済処理件数58.6億件、年間連結決済処理金額14兆円という実績で、毎年営業利益25%成長を目標に増収・増益を続けています。 こうした会社の成長を支えるGMO-PGのサポートセンターは、システム本部の配下に所属しており、コンタクトグループ（G）、テクニカルサポートG、プロセシングサポートG、サポート企画Gの4つのグループから構成されています。 田中によると、GMO-PGのサポートセンターの特徴は大きく分けて5つあるといいます。 1つめは、エンジニア出身者が複数在籍している点。2つめは、ハイレベルな接客業界出身者が多数在籍している点。このような背景もあり、HDI格付けベンチマーク「クオリティ格付け」において、最高評価となる三つ星を6年連続で獲得。また、2023年6月にはセンター認証の最高峰である「HDIサポートセンター国際認定」が決済代行業界で初めて認定されるなど、外部機関からも高い評価を受けています。 3つめは、改善をドライブさせる専任チームがセンターを下支えしている点です。小規模なセンターの場合、改善担当はオペレーションチームが兼務することが多いですが、GMO-PGでは会社や業界のスピードにキャッチアップできるよう改善に向けた専任チームを設けています。 4つめは、メンバーのスキルレベルを見える化することにより、多様なキャリアパスを用意している点です。田中は「エンジニア出身者の多いテクニカルサポートや改善専任チームへの異動など、サポートを1つのサービスとして向上していけるようさまざまな職務がある」と説明します。 5つめは、「とにかく明るいサポートセンター」である点です。センターでは「ありがとう」「笑顔」「素直さ」を行動指針にしており、田中によると「笑顔が絶えないスタッフが揃っており、センター内には常に良い雰囲気が流れている」といいます。 技術的な内容に特化した対応を行う「テクニカルサポートG」 続いて、佐山がテクニカルサポートGの活動について紹介しました。 開発職としてキャリアをスタートした佐山は、顧客の声を聞くことができ、なおかつエンジニアの背景をいかせる職場としてテクニカルサポート職へ転身。現在は、技術的な問い合わせ対応を中心に加盟店やシステム会社のサポートを行っています。 加盟店が抱える悩みや不安、懸念点はさまざまで、問い合わせ内容も多岐に渡ります。たとえば、「決済処理がエラーとなった」「開発を行ううえでどの仕様書を見ればよいのかわからない」「処理フローの想定に問題はないか」など、回答に技術的な知識や経験が求められる問い合わせも多くあります。 エンジニア未経験者がこれに対応しようとすると、開発部門への確認が毎回必要となり回答に時間がかかる、質問の内容がオペレーターに伝わらない、期待どおりの回答が得られず問題が解決しないなどといった問題が生じます。そこで技術的な内容に特化した対応を行うため誕生したのが、テクニカルサポートGです。エンジニア経験者が多く在籍するテクニカルサポートGの強みについて、佐山は次のように話します。 「エンジニアの経験があるからこそわかる悩みや共感できる部分がある。エンジニアと同じ目線に立つことで、加盟店が抱える問題はもちろん、潜在化している問題を発見し、加盟店のシステム運用をより良くしていくことができる」（佐山） サービス導入から安定稼働に向けてアシストすることも、テクニカルサポートGの業務の1つです。そのため、グループのメンバーが営業同行をすることも多いといいます。営業同行では、加盟店システムの担当者も含めて打ち合わせることで、技術的な質問点も含めた不明点を解消していきます。また、それだけでなく、加盟店から改善の要望を受けた際には、開発部門へその声を届けるという役割もテクニカルサポートGが担っています。佐山は「お問い合わせ対応や営業同行を行うなかで、開発側に改善提案をしてシステムに反映させ、それを加盟店にご利用いただくというサイクルが回っている。私たちが加盟店の声を届ける架け橋となることで、複数部署からサポートする仕組みが形成されている」と機能改善に向けた体制について説明します。 たとえば以前、サービスへの接続方式の1つである「リンクタイプPlus」に対して、エラーメッセージがわかりづらいという声が普段のサポートのやり取りのなかからあがっていました。そこで、カード番号の誤りや利用できない支払い方法が指定されているなど、エラーの原因をより具体的に表示されるよう変更しました。 「加盟店からヒアリングした内容をただ開発に伝えるのではなく、具体的にどのようなメッセージがよいのか、システム処理として無理はないかなど、お互いにとってより良い方法を探すことができた。これはエンジニアとして開発や要件定義を行ってきた経験から為せることだと考えている」（佐山） サポート職に転身して良かったと感じる瞬間は、加盟店から感謝の言葉をもらえたときだという佐山。「自分の行った対応が加盟店のためになったと、自己肯定感を感じられる。感謝の言葉は、自分が作ったシステムを活用してもらえていること以上にモチベーションの向上において効果がある」とやりがいを語りました。 サポートの改善活動を専任で担う「サポート企画G」 土屋はサポート企画Gの取り組みを紹介しました。 独立系SIerや社内SEなどを経て2015年にGMO-PGに入社した土屋は、テクニカルサポートに4年従事した後、現在はサポート企画Gにて主にSalesforce関連の利用設計や改善を担当しています。 サポート企画Gは、土屋の入所当時は存在しなかったグループだったといいます。加盟店、決済手段が年々増えることで、問い合わせ対応のための知識習得への負担が大きくなるという状況を打開するため、2019年に改善に特化したグループとして立ち上がったのがサポート企画Gでした。サポート企画Gの設立前は改善活動にかける時間が部門全体で20%しかありませんでしたが、2022年には40%にまで増えています。 現在サポート企画Gでは、サポートにおける各種数値の管理・分析、FAQ・チャットボットといったセルフサポートサービスの運用改善、顧客満足度アンケートの実施、在宅環境の整備など内部の環境整備、社内ナレッジの運用など、さまざまな取り組みを通じて顧客満足度向上を目指しています。 サポート企画Gでは、お客様がなるべく努力をせずに早い段階で問題解決できる「シフトレフト」を目指す取り組みを行っており、そのうち土屋が「一番大きな取り組み」とするのが、FAQサイトの改善です。土屋の入社当時、FAQサイトには専任担当者がおらず、更新も分析もされていない状況でした。そこで有料のFAQシステムを契約し、実際の問い合わせ内容と突き合わせて不足しているFAQは何か分析できるよう、問い合わせを1件ずつカテゴライズしました。また、同じタイミングでPDFマニュアルのオンライン化を行いました。これによりFAQサイトの参照数は増え、加盟店の数が増えているのにもかかわらず問い合わせ数が減少するという効果があったといいます。 現在のFAQサイトは、そこからさらに改善された3代目のバージョンとなります。2代目で利用していたFAQシステムは従量課金制で、参照数が増えるほど費用がかかってしまう状況だったため、社内ナレッジを一元管理でき、他サービスへの展開も可能な別の汎用的なツールへ移行。現在稼働している3代目のサイトへリニューアルすることとなりました。土屋はこの際にエンジニア経験がいきたと振り返ります。 「移行の際にはエンジニア経験をいかし、データの持ち方など今後の発展も視野に入れた構築設計ができた。テクニカルサポート以外でも、カスタマーサポート部では元エンジニアの経験をいかすチャンスがある」（土屋） 2023年4月からは「KCS（ナレッジ・センター・サービス）」を本格スタートしています。KCSは、米マイクロソフトやオラクルといった先進IT企業が参画する非営利団体サービスイノベーションコンソーシアムが発表した方法論です。 KCSの導入以前、問い合わせを受けた担当者は、自身の知識やドキュメント、マニュアルなどを使って回答していました。しかし、KCSではまずはじめに必ずナレッジを検索し、それを利用して回答するという流れになります。既存のナレッジ内に見つからない場合は、ナレッジを新規に作成します。これにより、新人でもベテランメンバー同様の対応ができるようになるメリットがあります。 「KCSは方法論なので、運用方法やシステム設計は示されていない。方法論を理解したうえで運用ルールを作っていく必要があった。私はルール構築に加え、エンジニア経験をいかしてシステム面も担当。お客様対応にSalesforceを利用しているため、ナレッジもSalesforceで検索作成できるように構築設計した」（土屋） サポート企画Gではこれからも、お客様の満足度向上につながる取り組みを続けていきます。 人材教育を担当しセンターの品質を保つ「コンタクトG」 寺村は、コンタクトGの取り組みについて紹介しました。 アパレル会社での接客経験がある寺村。GMO-PGでは電話対応業務からスタートし、現在はコンタクトGのマネージャー職としてチームメンバーの管理、社内各部署との調整等を担当しています。 技術的な内容を扱うテクニカルサポートGに対し、コンタクトGでは、契約に関する手続きや管理画面などの問い合わせに電話・メール・チャットのマルチチャネルで対応しています。 特徴は、ファーストクラスのキャビンアテンダントや大手百貨店の販売員、5つ星ホテルのブライダル担当者など、ハイクオリティな対応が求められる接客経験者が多く集まっている点です。コンタクトGでは、そうした経験者の知見をいかして、品質管理のための対応評価やそれに基づく人材育成も担っています。 特にエンジニア出身者は接客・顧客対応の経験がない場合も多く、知識が豊富にあってもそれをわかりやすく伝えたり、相手の気持ちや状況に適した形で寄り添いを表現したりすることを不得意に感じる人も多いといいます。寺村は「メンバー1人ひとりと会話をしながら、ウィークポイントや成長スピードにあわせて研修を実施していく」と研修の方針について説明します。 初期研修/導入研修では、わかりやすい研修資料を作成・活用するだけでなく、本人からフィードバックの場を設けて研修内容や流れの整合性を見直すことで、カリキュラムのブラッシュアップを重ねています。以前は研修資料が整っておらず、講師の知識レベルによって内容の偏りがあったといいますが、現在では講師向けの研修も実施し、誰が講師になっても情報に偏りなく必要事項が網羅された研修ができるようなカリキュラムとなっています。 導入研修が終わるとOJTに進みます。実際の電話対応において不明点があった場合には、すぐに相談できるよう近くにリーダー以上の先輩メンバーを配置したシフトが作成されているため安心です。1人で顧客対応をするなかで感じる不明点や、導入研修ではカバーできなかった難しい内容については、個別研修やスキル別研修で補っていきます。配属5か月目をすぎると、毎年実施している対応評価、半期に一度受験する全員共通のテストで個々のウィークポイントを洗い出し、それぞれのメンバーにあわせたフォロー研修を実施していきます。 各人のスキルレベルは、受電件数、音源モニタリングのスコア、スキルテストの点数、メールの承認率、KCSナレッジへの貢献などの達成度によって、5段階で評価されます。寺村は「定量的でわかりやすい目標を設定することで、メンバーのモチベーションにつながる。ランクごとのレベル感が明示できるため、サポート全体のバランスを考える際などマネジメントもやりやすくなるメリットがある」と話します。 こうした取り組みの成果もあり、第三者からの高い評価を得ているカスタマーサポート部。寺村は「連続獲得のプレッシャーはある」と明かしながらも、「モチベーションにつながる面もあるうえ、加盟店にもより安心・信頼して使っていただける」と第三者評価の効果を説明します。そして「優しく思いやりのある対応がサポートにとっては大切。これを念頭においてよりご期待に応えられるよう、さらなる顧客満足度向上を目指していきたい」と今後の展望を語りました。 エンジニア採用実施中！ GMO-PGではエンジニアを積極採用中です。さまざまなバックボーンを持つエンジニアのみなさまの力を必要としています。興味のある方はぜひ採用HPをご覧ください。 また、これまで当社エンジニアが登壇したウェビナーやインタビューは以下にまとまっていますので、併せてご覧ください。https://www.gmo-pg.com/blog/feature/feature03/ さいごに ご視聴・ご参加いただき、ありがとうございました。参加いただいた方からは、御社の取り組みを理解することができました、自らの参考にできる部分があれば取り入れていきたい、教育体制についてとても勉強になりました、興味深かったなど、温かいコメントをたくさんいただき、大変嬉しく思っております。重ねて御礼申し上げます。 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://youtu.be/mcgoDy1M9TA

本記事はGMOインターネットグループで複数ある開発者ブログのなかから人気の記事をピックアップして再掲載しています。機械学習や深層学習のビジネス応用を研究、社会実装をしているグループ研究開発本部 AI研究開発室のデータサイエンティストが寄稿した人気記事です。 結論ファースト A. ベクターストアに入れる元ネタドキュメントの抽出⇒ unstructured が使えるかも B. ベクターストアに入れる元ネタドキュメントのチャンク分け⇒ タイトル。キーワードをメタデータで付加 C. ベクターストアに投げる質問プロンプトの最適化⇒ 形態素またはキーワード抽出でプロンプトを精査 D. ベクターストア検索結果の精査⇒ ContextualCompressionRetriever による検索結果要約とDocumentCompressorPipeline による検索結果絞り込みがよさげ「検索結果が質問に沿ったものか精査させる」タスクをChatGPTに担当してもらうことが私の業務課題には適しているのではという気付きがありました。 E. （おまけ）ベクターストアの選定⇒ 1位はFaiss。マネージドも多々あり。Chromaがこれから来るかも。 ChatGPT 活用に関する問題意識 プロジェクト管理者にとっての ChatGPT 活用 ChatGPT はシステム開発の現場でも非常に役に立っていますが、現在の利用範囲は「個別のコードの生成」や「レビュー」など、どちらかというと小さく限定されたタスクが多いと思います。 私はプロジェクト管理をしている立場なので、自分自身の業務で ChatGPT を活かすにはもっと広い視点でアイディアを出す必要性を感じています。最終的には以下のような業務に ChatGPT を活用できないかと日々妄想し、勉強会や Web 検索に勤しんでいます。 指定した仕様でプロジェクトのコードを実装してもらう。ソースコードを読み込んで仕様に関するQAを回答する。仕様に関するドキュメントを読み込んでソースレビューをする。既存ソースコードを読み込んでソースレビューをする。ソースコードや仕様ドキュメントを読み込んで該当機能の影響範囲を特定する。 今回は「影響範囲の調査」にフォーカスして考えてみようと思います。まだ道半ばですが、現在わかっている手法のいくつかをご紹介していきます。 In-Context Learning を突き詰める必要性 2023年7月の公式発表で ChatGPT 3.5 Turbo と 4 の Fine Tuning が2023年後半に利用可能になるかもという情報が公表されました。 "We are working on safely enabling fine-tuning for GPT-4 and GPT-3.5 Turbo and expect this feature to be available later this year."「私たちは GPT-4 および GPT-3.5 Turbo の微調整を安全に有効にすることに取り組んでおり、この機能は今年後半に利用可能になる予定です。」https://openai.com/blog/gpt-4-api-general-availability Fine Tuning は ChatGPT に特定の知識を身に着けさせる「追加学習」です。こちらに関してまだ古いモデルである GPT3 でしか提供されておらず事例も少なくなっており、わかっていないことがたくさんあります。1つの疑念として、 ChatGPT は少しの情報を与えた程度では専門的な知識を覚えてくれないのではというのがあります。例えば、自社のシステム仕様情報を Fine Tuning で覚えさせても、そもそもの元の学習データには似たような情報が膨大に入っており、そちらに引っ張られて結局一般的なことを回答してしまう、もっと言うとありもしない幻覚を回答するリスクはどこまでいっても残り続ける可能性があるのではという話を聞きました。Fine Tuning とは別のアプローチとして、「都度学習」 としての In-Context Learning があります。これはプロンプトに都度必要な情報を全部含めてしまうことでChatGPTが正確な回答を生成しやすくするという手法です。現状は Fine Tuning の可能性が不透明なことから、In-Context Learning を突き詰めて精度を向上していく必要性が当面は継続するという見方もできると考えています。 In-Context Learning の事例は巷に溢れており（現実的に2023年7月現在はこれしか有効な手法がないというのがある）、特に Python では LangChain や Llamaindex などのフレームワークがありますが、結局は「 ChatGPT のプロンプトの中に別のデータソースから得た情報を埋め込んでいく」という手法に集約されます。 私のプロジェクト管理業務の改善に大きく関連する話では Pinecone 社が出している以下の事例が興味深いです。 GPT4にLangChainのソースコードに関する質問を回答させるhttps://github.com/pinecone-io/examples/blob/master/generation/gpt4-retrieval-augmentation/gpt-4-langchain-docs.ipynb 本質的にはこれに近いことを自社のプロジェクトの仕様ドキュメント＋ソースコードで実現したい、というのが現在の私の目指すゴールになると思います。 In-Context Learning で利用するベクターストアの現実的な課題 LangChain でも Llamaindex でも内部的に外部データソースで情報検索をすることで In-Context Learning を実現しています。このデータソースの実現方法はいくつかあるのですが、特に特定のプロジェクトの情報を格納する目的では自前でのベクターストア構築が本命になると思います。ベクターストアは文書をベクトル化して保存し検索された単語との関連度を高速に判定することで精度の高い検索ができる検索エンジンです。（種類はいくつかあるので終盤で少し紹介します） ただ、ベクターストアは検索エンジンのため、その活用にあたり以下のような初期的な課題に直面します。（今回のメインコンテンツです） A. ベクターストアに入れる元ネタドキュメントの抽出B. ベクターストアに入れる元ネタドキュメントのチャンク分けC. ベクターストアに投げる質問プロンプトの最適化D. ベクターストアからのレスポンス精査E. （おまけ）ベクターストアの選定 ここからこれらひとつひとつをどのように解決できるか、調査・検証した内容をご紹介していきます。 A. ベクターストアに入れる元ネタドキュメントの抽出 ここでいう元ネタドキュメントは、仕様情報やソースコードなど ChatGPT が few shot の In-Context Learning のためにプロンプトに入れて送る情報です。まずはベクターストアに登録する事前準備として、この元ネタドキュメント情報をプログラムから扱いやすいように抽出・整形する必要があります。 unstructured ライブラリ 私の担当には Atlassian の Confluence を使って仕様ドキュメントを管理しているプロジェクトがあり、こちらはページ全体を HTML または PDF で出力できます。HTMLまたはPDFのドキュメントをどうやってパースしてテキストドキュメント化するのかという課題がありますが、 unstructured という Python ライブラリがありました。 公式ページhttps://www.unstructured.io/ こちらを使うと PDF、HTML だけでなく Excel や md からのドキュメントからでも個別のプレーンなテキストを生成できます。対応しているドキュメント種別は公式に記載があります。https://unstructured-io.github.io/unstructured/bricks.html#partitioning 具体例として、弊社 VPS サービスの Conoha API ドキュメントをHTMLとPDFにして練習してみます。トークン取得APIhttps://www.conoha.jp/docs/identity-post_tokens.php コードは至ってシンプルです。 from unstructured.partition.html import partition_html elements = partition_html("conoha_api_token.html") print("\n\n".join([str(el) for el in elements])) HTMLからドキュメントを抽出した結果（長いので折りたたまれています） MENU TOP Identity API v2.0 バージョン情報取得 バージョン情報詳細取得 トークン発行 Account(Billing) API v1 バージョン情報取得 バージョン情報詳細取得 アイテム一覧の取得 アイテム詳細取得(アイテム指定) 入金履歴取得 入金サマリー取得 請求データ一覧取得 請求データ明細取得(アイテム指定) 告知一覧取得 告知詳細取得(アイテム指定) 告知既読・未読変更 Object Storage 利用状況グラフ(リクエスト数) Object Storage 利用状況グラフ(使用容量数) Compute API v2 バージョン情報取得 バージョン情報詳細取得 VMプラン一覧取得 VMプラン詳細取得 VMプラン詳細取得(アイテム指定) VM一覧取得 VM一覧詳細取得 VM詳細取得（アイテム指定) VM追加 VM削除 VM起動 VM再起動 VM強制停止 VM通常停止 OS再インストール VMリサイズ VMリサイズ（confirm） VMリサイズ（revert） VNCコンソール ローカルディスクのイメージ保存 ストレージコントローラー変更 ネットワークアダプタ変更 ビデオデバイスの変更 コンソールのキーマップ変更 WebSocket(novaconsole)用のAPI WebSocket(httpconsole)用のAPI ISOイメージの挿入（mount） ISOイメージの排出（unmount） セキュリティグループのサーバへの割り当て状態表示 キーペア一覧取得 キーペア詳細取得(アイテム指定) キーペア追加 キーペア削除 イメージ一覧取得(nova) イメージ詳細取得 イメージ詳細取得(アイテム指定)(nova) アタッチ済みボリューム一覧 アタッチ済みボリューム取得（アイテム指定) ボリュームアタッチ ボリュームデタッチ アタッチ済みポート一覧取得 アタッチ済みポート取得（アイテム指定) ポートアタッチ ポートデタッチ VMメタデータの更新（ネームタグの変更） VMメタデータ取得 VMに紐づくアドレス一覧 VMに紐づくアドレス一覧(ネットワーク指定) VPS利用状況グラフ（CPU使用時間） VPS利用状況グラフ（インターフェイストラフィック） VPS利用状況グラフ（ディスクIO） バックアップ一覧取得 バックアップ一覧取得(backup id 指定) バックアップの申し込み バックアップの解約 ブートディスクバックアップのリストア ブート・追加ディスクバックアップのイメージ保存 ISOイメージの一覧 ISOイメージダウンロード Block Storage API v2 バージョン情報取得 バージョン情報詳細取得 ボリュームタイプ一覧取得 ボリュームタイプ取得（アイテム指定) ボリューム一覧取得 ボリューム詳細取得 ボリューム詳細取得（アイテム指定) ボリューム作成 ボリューム作成（ソースボリューム指定） ボリューム削除 ブロックディスクのイメージ保存 Image API v2 バージョン情報取得 イメージ一覧取得(Glance) イメージ詳細取得(アイテム指定)(glance) イメージコンテナのスキーマ情報取得 イメージのスキーマ情報取得 イメージメンバーコンテナのスキーマ情報取得 イメージメンバーのスキーマ情報取得 イメージメンバー一覧取得 イメージ削除 イメージ保存容量制限 イメージ保存容量制限情報取得 Network API v2.0 バージョン情報取得 バージョン情報詳細取得 ネットワーク一覧取得 ネットワーク詳細取得 ネットワーク追加(ローカルネット用) ネットワーク削除 ポート一覧取得 ポート詳細取得 ポート追加 ポート更新 ポート削除 サブネット一覧取得 サブネット詳細取得 サブネットの払い出し(ローカルネット用) サブネットの払い出し(追加IP用) サブネットの払い出し(LB用) サブネットの削除 POOL一覧取得 POOL詳細取得 POOL追加（バランシング指定） POOL更新(バランシング方式の変更) POOL削除 VIP一覧取得 VIP詳細取得 VIP作成 VIP削除 REAL（member）一覧取得 REAL（member）詳細取得 REAL（member）追加 REAL(member)更新 REAL(member)削除 ヘルスモニタ一覧取得 ヘルスモニタ詳細取得 ヘルスモニタ作成 ヘルスモニタ変更 ヘルスモニタ削除 ヘルスモニタの関連付け ヘルスモニタの関連付け解除 セキュリティグループ一覧取得 セキュリティグループ詳細取得 セキュリティグループ作成 セキュリティグループ更新 セキュリティグループ削除 セキュリティグループ ルール一覧取得 セキュリティグループ ルール詳細取得 セキュリティグループ ルール作成 セキュリティグループ ルール削除 ObjectStorage API v1 アカウント情報取得 アカウントクォータ設定 コンテナ情報取得 コンテナ作成 コンテナ削除 オブジェクト情報取得 オブジェクトアップロード オブジェクトダウンロード オブジェクト複製 オブジェクト削除 dynamic large objects static Large Object object versioning schedule objects for deletion temporary url middleware web publishing Database API v1 バージョン情報取得 バージョン情報詳細取得 サービス作成 サービス一覧取得 サービス情報取得 サービス更新 サービス削除 サービスメタデータ更新 データベース上限値取得 データベース上限値変更 バックアップ有効無効 データベース作成 データベース一覧取得 データベース情報取得 データベース更新 データベース削除 データベース権限作成 データベース権限一覧取得 データベース権限削除 バックアップ一覧 リストア アカウント作成 アカウント一覧取得 アカウント情報取得 アカウント更新 アカウント削除 DNS API v1.0 バージョン情報取得 ドメインホスティング情報表示 ドメイン一覧表示 ドメイン作成 ドメイン削除 ドメイン情報表示 ドメイン更新 レコード一覧取得 レコード作成 レコード削除 レコード情報表示 レコード更新 ゾーンファイルインポート ゾーンファイルエクスポート ConoHa API Documantation トークン発行 - Identity API v2.0 トークン発行 - Identity API v2.0 TOP Identity API v2.0 バージョン情報取得 バージョン情報詳細取得 トークン発行 Account(Billing) API v1 バージョン情報取得 バージョン情報詳細取得 アイテム一覧の取得 アイテム詳細取得(アイテム指定) 入金履歴取得 入金サマリー取得 請求データ一覧取得 請求データ明細取得(アイテム指定) 告知一覧取得 告知詳細取得(アイテム指定) 告知既読・未読変更 Object Storage 利用状況グラフ(リクエスト数) Object Storage 利用状況グラフ(使用容量数) Compute API v2 バージョン情報取得 バージョン情報詳細取得 VMプラン一覧取得 VMプラン詳細取得 VMプラン詳細取得(アイテム指定) VM一覧取得 VM一覧詳細取得 VM詳細取得（アイテム指定) VM追加 VM削除 VM起動 VM再起動 VM強制停止 VM通常停止 OS再インストール VMリサイズ VMリサイズ（confirm） VMリサイズ（revert） VNCコンソール ローカルディスクのイメージ保存 ストレージコントローラー変更 ネットワークアダプタ変更 ビデオデバイスの変更 コンソールのキーマップ変更 WebSocket(novaconsole)用のAPI WebSocket(httpconsole)用のAPI ISOイメージの挿入（mount） ISOイメージの排出（unmount） セキュリティグループのサーバへの割り当て状態表示 キーペア一覧取得 キーペア詳細取得(アイテム指定) キーペア追加 キーペア削除 イメージ一覧取得(nova) イメージ詳細取得 イメージ詳細取得(アイテム指定)(nova) アタッチ済みボリューム一覧 アタッチ済みボリューム取得（アイテム指定) ボリュームアタッチ ボリュームデタッチ アタッチ済みポート一覧取得 アタッチ済みポート取得（アイテム指定) ポートアタッチ ポートデタッチ VMメタデータの更新（ネームタグの変更） VMメタデータ取得 VMに紐づくアドレス一覧 VMに紐づくアドレス一覧(ネットワーク指定) VPS利用状況グラフ（CPU使用時間） VPS利用状況グラフ（インターフェイストラフィック） VPS利用状況グラフ（ディスクIO） バックアップ一覧取得 バックアップ一覧取得(backup id 指定) バックアップの申し込み バックアップの解約 ブートディスクバックアップのリストア ブート・追加ディスクバックアップのイメージ保存 ISOイメージの一覧 ISOイメージダウンロード Block Storage API v2 バージョン情報取得 バージョン情報詳細取得 ボリュームタイプ一覧取得 ボリュームタイプ取得（アイテム指定) ボリューム一覧取得 ボリューム詳細取得 ボリューム詳細取得（アイテム指定) ボリューム作成 ボリューム作成（ソースボリューム指定） ボリューム削除 ブロックディスクのイメージ保存 Image API v2 バージョン情報取得 イメージ一覧取得(Glance) イメージ詳細取得(アイテム指定)(glance) イメージコンテナのスキーマ情報取得 イメージのスキーマ情報取得 イメージメンバーコンテナのスキーマ情報取得 イメージメンバーのスキーマ情報取得 イメージメンバー一覧取得 イメージ削除 イメージ保存容量制限 イメージ保存容量制限情報取得 Network API v2.0 バージョン情報取得 バージョン情報詳細取得 ネットワーク一覧取得 ネットワーク詳細取得 ネットワーク追加(ローカルネット用) ネットワーク削除 ポート一覧取得 ポート詳細取得 ポート追加 ポート更新 ポート削除 サブネット一覧取得 サブネット詳細取得 サブネットの払い出し(ローカルネット用) サブネットの払い出し(追加IP用) サブネットの払い出し(LB用) サブネットの削除 POOL一覧取得 POOL詳細取得 POOL追加（バランシング指定） POOL更新(バランシング方式の変更) POOL削除 VIP一覧取得 VIP詳細取得 VIP作成 VIP削除 REAL（member）一覧取得 REAL（member）詳細取得 REAL（member）追加 REAL(member)更新 REAL(member)削除 ヘルスモニタ一覧取得 ヘルスモニタ詳細取得 ヘルスモニタ作成 ヘルスモニタ変更 ヘルスモニタ削除 ヘルスモニタの関連付け ヘルスモニタの関連付け解除 セキュリティグループ一覧取得 セキュリティグループ詳細取得 セキュリティグループ作成 セキュリティグループ更新 セキュリティグループ削除 セキュリティグループ ルール一覧取得 セキュリティグループ ルール詳細取得 セキュリティグループ ルール作成 セキュリティグループ ルール削除 ObjectStorage API v1 アカウント情報取得 アカウントクォータ設定 コンテナ情報取得 コンテナ作成 コンテナ削除 オブジェクト情報取得 オブジェクトアップロード オブジェクトダウンロード オブジェクト複製 オブジェクト削除 dynamic large objects static Large Object object versioning schedule objects for deletion temporary url middleware web publishing Database API v1 バージョン情報取得 バージョン情報詳細取得 サービス作成 サービス一覧取得 サービス情報取得 サービス更新 サービス削除 サービスメタデータ更新 データベース上限値取得 データベース上限値変更 バックアップ有効無効 データベース作成 データベース一覧取得 データベース情報取得 データベース更新 データベース削除 データベース権限作成 データベース権限一覧取得 データベース権限削除 バックアップ一覧 リストア アカウント作成 アカウント一覧取得 アカウント情報取得 アカウント更新 アカウント削除 DNS API v1.0 バージョン情報取得 ドメインホスティング情報表示 ドメイン一覧表示 ドメイン作成 ドメイン削除 ドメイン情報表示 ドメイン更新 レコード一覧取得 レコード作成 レコード削除 レコード情報表示 レコード更新 ゾーンファイルインポート ゾーンファイルエクスポート Description 有効なトークン情報を取得する Request URL Request Paramters username ユーザー名 plain ユーザ名 password ユーザーパスワード plain ユーザパスワード tenantId (Optional) Tenant ID plain テナントID Request Json Normal response codes 200 OK Example※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ RES ConoHa WING トップ 料金・仕様 特長 機能 ドメイン ご利用の流れ 導入事例 お申し込み ConoHa VPS トップ 料金・仕様 特長 機能 ご利用の流れ 導入事例 お申し込み ConoHa for Windows Server トップ 料金・仕様 特長 ご利用の流れ お申し込み ConoHa for GAME トップ 料金・仕様 特長 ご利用の流れ お申し込み おすすめ情報 ConoHa Mobile ConoHaカード ConoHa学割 ConoHaデビュー割 採用情報 美雲このはオフィシャルサイト ワプ活 マイクラゼミ 美雲このは徹底ガイド サポート トップ ConoHa WINGサポート ConoHa VPSサポート ConoHa for Windows Serverサポート 用語集 会員規約 ConoHaドメイン登録規約 ConoHaチャージ利用規約 ConoHaクーポン利用規約 特定商取引法に基づく表記 資金決済法に基づく表示 サービス品質保証制度(SLA) お問い合わせ プライバシーポリシー Cookieポリシー 会社概要 Copyright © 2023 GMO Internet Group, Inc. All Rights Reserved. from unstructured.partition.pdf import partition_pdf elements = partition_pdf("conoha_api_token.pdf") print("\n\n".join([str(el) for el in elements])) PDFからドキュメント抽出結果（長いので折りたたまれています） トークン発⾏ - Identity API v2.0｜ConoHa API 法⼈⼝座即⽇ > GMOあおぞらネット銀⾏ CFD国内1位 > GMOクリック証券 国内1位 > 電⼦印鑑GMOサイン 夢を応援 > 起業の窓⼝ byGMO ConoHa API Documantation トークン発行 - Identity API v2.0  トークン発行 - Identity API v2.0 Description TOP 有効なトークン情報を取得する Identity API v2.0  バージョン情報取得 バージョン情報詳細取得 Request URL トークン発行 Account(Billing) API v1  identity API v2.0 Compute API v2  POST /v2.0/tokens Block Storage API v2  Image API v2  Network API v2.0 Request Paramters  ObjectStorage API v1  Parameter Value Style Description Database API v1  username ユーザー名 plain ユーザ名 DNS API v1.0  password ユーザーパスワード plain ユーザパスワード tenantId (Optional) Tenant ID plain テナントID Request Json { "auth": { "passwordCredentials": { "username": "ConoHa", "password": "paSSword123456#$%" }, "tenantId": "487727e3921d44e3bfe7ebb337bf085e" } } Normal response codes 200 OK Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コン トロールパネルにてご確認の上ご利用ください。 REQ curl -i -X POST \ H "Accept: application/json" \ d '{"auth":{"passwordCredentials":{"username":"ConoHa","password":"paSSword123456#$%"}," https://identity.tyo1.conoha.io/v2.0/tokens RES HTTP/1.1 200 OK Date: Mon, 08 Dec 2014 02:40:56 GMT Server: Apache Content-Length: 4572 Content-Type: application/json { "access": { "token": { "issued_at": "2015-05-19T07:08:21.927295", "expires": "2015-05-20T07:08:21Z", "id": "sample00d88246078f2bexample788f7", "tenant": { "name": "example00000000", "enabled": true, "tyo1_image_size": "550GB", } ], "endpoints_links": [], "type": "mailhosting", "name": "Mail Hosting Service" }, { "endpoints": [ { "region": "tyo1", "publicURL": "https://dns-service.tyo1.conoha.io" } ], "endpoints_links": [], "type": "dns", "name": "DNS Service" }, { "endpoints": [ { "region": "tyo1", "publicURL": "https://object-storage.tyo1.conoha.io/v1/nc_a4392c0ccba74485abd } ], "endpoints_links": [], "type": "object-store", "name": "Object Storage Service" }, { "endpoints": [ { "region": "sjc1", "publicURL": "https://identity.sjc1.conoha.io/v2.0" }, { "region": "tyo1", "publicURL": "https://identity.tyo1.conoha.io/v2.0" }, { "region": "sin1", "publicURL": "https://identity.sin1.conoha.io/v2.0" } ], "endpoints_links": [], "type": "identity", "name": "Identity Service" } ], "user": { "username": "example00000000", "roles_links": [], "id": "examplea6963c074d7csample12a886ee", "roles": [ { "name": "SwiftOperator" }, { "name": "_member_" } ], "name": "example00000000" }, "metadata": { "is_admin": 0, "roles": [ "0000000000000000000000000000000e", "11111111111111111111111111111113" ] } } } ConoHa for Windows Server ConoHa WING ConoHa VPS ConoHa for GAME おすすめ情報 サポート トップ トップ トップ トップ ConoHa Mobile トップ       料金・仕様 料金・仕様 料金・仕様 料金・仕様 ConoHaカード ConoHa WINGサポー       ト 特長 特長 特長 特長 ConoHa学割  ConoHa VPSサポート  機能 機能 ご利用の流れ ご利用の流れ ConoHaデビュー割    ConoHa for Windows  ドメイン ご利用の流れ お申し込み お申し込み 採用情報      Serverサポート ご利用の流れ 導入事例 美雲このはオフィシャ    用語集  ルサイト 導入事例 お申し込み   ワプ活  お申し込み  マイクラゼミ  美雲このは徹底ガイド  会員規約 ｜ ConoHaドメイン登録規約 ｜ ConoHaチャージ利用規約 ｜ ConoHaクーポン利用規約 ｜ 特定商取引法に基づく表記 ｜ 資金決済法に基づく表示 ｜ サービス品質保証制度(SLA) ｜ お問い合わせ ｜ プライバシーポリシー ｜ Cookieポリシー ｜ 会社概要   Copyright © 2023 GMO Internet Group, Inc. All Rights Reserved. https://www.conoha.jp/docs/identity-post_tokens.php 1/1 上記の２つとも何とか取れていますが、パッと見、ちゃんとできているのかよくわからないｗ以下、結果をしっかり読んだ考察です。 [HTML 取込結果]・必要のない MENU ががっつり入っている。そのせいか、本題以外の文章がとても多い。・重要な curl や JSON の情報なし。 [PDF 取込結果]・MENU なし。・curl や JSON あり。 これだけ見ると PDF 一択のようにも見えます。HTML 側の問題回避のアプローチとして以下のような方法がある思います。・MENU など不要な文書をカットするために別のスクリプトを書いてノイズを除去する・ノイズ除去自体を ChatGPT にやってもらう具体的なチューニングまで踏み込めていないのですが、より効率的なデータ抽出のためさらなる検証を継続していこうと思います。 ひとまず元ネタのドキュメントから「文字」データは取れますよねというところができるようになりました。 B. ベクターストアに入れる元ネタドキュメントのチャンク分け 元ネタドキュメントは分割して、 ChatGPT のプロンプトに In-Context として入れやすい小さな塊（=チャンク）にしておく必要があります。この分割は人間が作る、が当然確実なのですが、現実的課題として100だの1000だのというレベルの大量の既存文書を機械的にチャンク化せざるを得ない状況が発生すると思います。 手法としては以下の2点が重要なポイントになります。・元ネタドキュメントの章やページなどの単位でチャンクを分けて、なるべく意味の塊をキープする。・タイトルやキーワードといった文章のメタデータを先頭に付加する。 1回に Embbeding 可能な文章量 ベクターストアに入れるデータは OpenAI の text-embedding-ada-002 でベクトル化を行いますが、こちらは1回に8191トークンが上限です。目安としては5000文字が1回の Embbeding でベクトル化できます。（トークンのカウントは漢字が入ると増えてしまうため TikToken ライブラリで行ったほうが確実です。）ChatGPT への質問プロンプトで送ることができるトークン数と文字数の目安は以下の通りです。gpt-4-0613   : 8,192 tokens （5000文字）gpt-4-32k-0613 : 32,768 tokens （20000文字）gpt-3.5-turbo-0613 : 4,096 tokens （2500文字）gpt-3.5-turbo-16k : 16,384 tokens （10000文字） チャンクサイズとRefine どのぐらいの文章の塊をプロンプトとして ChatGPT に送るべきなのか、という重要な問いを考える上で、私は Refine を前提とした1チャンクの大きさは300文字から1000文字程度のある程度意味のまとまった文章の塊にするといいのではという仮説で進めています。 Refine とは異なるデータを乗せたプロンプトで会話を複数回繰り返し、回答を少しずつ洗練する手法です。Refine に関連する回答生成の手法としては以下のような選択肢があります。・1つの大きなチャンクに全部を入れ込む。・1つの大きなチャンクを複数回送る。（Refine）・複数の小さなチャンクをマージして送る。・複数の小さなチャンクをマージしたものを複数回送る。（Refine）Refine は繰り返し処理のためコスト+処理時間がかかってしまうのがマイナス点なのですが、精度を上げる手法としては一定の効果があると今のところは感じています。最適なチャンクサイズを見つけるには、自分の扱うドキュメントと質問の特性に応じたサイズ検証を設計して、試しながらチューニングしていく他ないと思います。 unstructured でメタデータを入れ込む unstructured で自動的にチャンクを作る方法もあります。こちらは元ネタドキュメントを Elements という文節ごとに区切ってリスト化してくれるので、 1 Element = 1 Chunk として利用する事例もありました。ただ、私は元ネタドキュメントのほうがこの手法と相性が合わなかったようでどうもうまくいきませんでした。先ほどの PDF と HTML の例では文節の Element がいずれもほぼ単語レベルの小さすぎる分割になってしまいました。ここまで小さくなると意味の塊としては用をなしえません。JSON の塊もバラされて1つ1つの項目が別の Elements になってしまったりしたので、このままでは 1 Element = 1 Chunk のような形式にはできないなと。元ネタドキュメントは1ページ全体が小さいので Elements 全体まとめて 1 chunk するのが丁度よいと感じでした。（最大で gpt-3.5-turbo でも 2500 文字、 gpt-4-32k-0613 なら 20000 文字はいけるので、金額をかけてもいいから正確さが欲しいという場合はアリかもしれません。要検証） そうなると登録できる長さを計算し、機械的に一定の長さでループ処理するというのはあながち悪いとも言い切れません。いい感じに2500文字ぐらいのチャンクを作る事例（PDFから情報をとっている）https://qiita.com/sakasegawa/items/16714fa132e874cab069 さらに、メタデータのアイディアがあります。ここでいうメタデータは、タイトルやトピックのキーワードのことです。つまり文章がどんな内容なのかをチャンクの先頭で示し、検索精度を上げようという試みです。 以下で、機械的に文章を分割しながら小見出し的なタイトルをチャンクに入れ込む方法が以下に紹介されています。https://note.com/mahlab/n/n0a8fa0e1d586#6a22a272-b37f-4153-80cc-ca130bb11597こちらはチャンクの先頭にタイトルとサブタイトルに相当する情報を文章に付加しています。このケースでは unstructured でマークダウン（.md）のドキュメントをパースした際に、 title 要素を unstructured の element として取得できる点を活用しています。私の要件のように HTML が元ネタの場合は、ページの title タグや h1 タグをキーワードとして抽出し、それを先頭に記載するという方法が取れると思います。（HTML を unstructured でやってみたら本来 titleでないものがたくさんtitle扱いされてしまい結局使えず）こちらも1つのチャンクには複数のトピックが混ざらないようなもともときれいな内容の分割がされていることがやはり望ましいと言えます。 もう1点、1つ1つのドキュメントの要約を ChatGPT に生成させ、それをチャンクに入れて文章をわかりやすくするというのもアリなのではと思いました。文章が長くはなってしまいますが、より意味の関連度が強められる可能性があります。（検索に効果があるかは未検証） C. ベクターストアに投げる質問プロンプトの最適化 LangChain でも Llamaindex でも質問文は検索前に Embbedings API でベクター化されてから実行されます。ただこの質問文は冗長だったり関係ないものを含むと検索結果もブレが生じるので、質問文自体を形態素解析またはキーワード抽出してからベクター検索をするという方法があります。 形態素解析の場合、ライブラリで処理すれば一発です。 from sudachipy import tokenizer from sudachipy import dictionary # 人間が入力したプロンプト question = "トークン取得APIのパラメータを教えてください。" # 形態素解析モデルの構築 tokenizer_obj = dictionary.Dictionary().create() mode = tokenizer.Tokenizer.SplitMode.C # 形態素解析の実行 tokens = tokenizer_obj.tokenize(question, mode) keywords = [] # keywords for token in tokens: # 名詞だけを抽出して格納 if token.part_of_speech()[0] == "名詞": print(token.surface(), token.part_of_speech()[0]) keywords.append(token.surface()) 結果以下のようにキーワードを抽出できます。 トークン 名詞 取得 名詞 API 名詞 パラメータ 名詞 また、 pke を使えば重要キーワードを機械的に抽出ができます。 !pip install git+https://github.com/boudinfl/pke.git !python -m spacy download ja_core_news_sm import pke import spacy text = "トークン取得APIのURLとパラメータを教えてください。" spacy_model = spacy.load("ja_core_news_sm") extractor = pke.unsupervised.MultipartiteRank() extractor.load_document(input=text, language='ja', normalization=None, spacy_model=spacy_model) extractor.candidate_selection(pos={'NOUN', 'PROPN', 'ADJ', 'NUM'}) extractor.candidate_weighting(threshold=0.76, method='average', alpha=1.1) print(extractor.get_n_best(5)) 最終的にスコアの上位5件を絞り込んでいます。 [('url', 0.39361741945785217), ('トークン 取得 api', 0.30319129027107367), ('パラメータ', 0.30319129027107367)] 「キーワード抽出」はChatGPTに任せるのもありますが、質問するごとに毎回リクエストすることになる点が気になる点です。私の想定するユースケースでは簡単な質問文が使われるので、上記の例だけでも充分ではと思います。 D. 検索結果の精査 検索全般の課題として、以下のような点があると思います。・質問と関係ないドキュメントが検索にヒットしてしまう・ドキュメントが長いと LLM に In-Context Learning で付与できる文字数を超えてしまう こうした課題を LangChain ではどのようにアプローチできるでしょうか。 LangChain の Contextual Compression Retriever を使って部分要約をつくる これは「回答の生成」ではなく「検索結果の精査」のタスクを ChatGPT に担当してもらう方法です。当初の目的であった、ChatGPT に「検索結果から正確な回答を生成させる」ことは実際結構なチューニングが必要でハードルが高いのですが、「検索結果の精査をする」だけに特化すればある程度は機械的に行える可能性があります。 参考にした情報です。https://zenn.dev/laiso/articles/f5e5c616e128a7 ここから検証のため、ベクターストア Faiss をセットアップしていきます。上述の Conoha API ドキュメントから、検索対象となる API の情報を 7 件追加しています。 from langchain.text_splitter import CharacterTextSplitter from langchain.document_loaders import DirectoryLoader from langchain.vectorstores import FAISS def print_docs(docs): print(f"\n{'-' * 10}\n".join([f"Document {i+1}:\n\n" + d.page_content for i, d in enumerate(docs)])) loader = DirectoryLoader('./data_conoha_api', glob="*.txt") docs = loader.load() len(docs) 7つの API ドキュメントがロードされます。 from langchain.embeddings import OpenAIEmbeddings embeddings = OpenAIEmbeddings() ### 初回だけ Embbeding してファイルに保存 ## db = FAISS.from_documents(docs, embeddings) ## db.save_local("faiss_index") # ファイルからFAISSを生成 retriever=FAISS.load_local("faiss_index", embeddings).as_retriever() 素の状態でドキュメントを検索した結果です。 # 「トークン取得APIのパラメータをおしえてください。」のプロンプトを形態素解析した結果のキーワードで検索します # 名詞4つ "トークン 取得 API パラメータ" q=" ".join(keywords) docs = retriever.get_relevant_documents(q)) pretty_print_docs(docs) ベクターストアの検索結果（めちゃくちゃ長いので折りたたまれています） Document 1: Conoha API トークン発行 Identity API v2.0 Description 有効なトークン情報を取得する Request URL identity API v2.0 POST /v2.0/tokens Request Paramters Parameter Value Style Description username ユーザー名 plain ユーザ名 password ユーザーパスワード plain ユーザパスワード tenantId (Optional) Tenant ID plain テナントID Request Json { "auth": { "passwordCredentials": { "username": "ConoHa", "password": "paSSword123456#$%" }, "tenantId": "487727e3921d44e3bfe7ebb337bf085e" } } Normal response codes 200 OK Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQUEST curl i X POST \ H "Accept: application/json" \ d '{"auth":{"passwordCredentials":{"username":"ConoHa","password":"paSSword123456#$%"},"tenantId":"487727e3921d44e3bfe7ebb337bf085e"}}' \ https://identity.tyo1.conoha.io/v2.0/tokens RESPONSE HTTP/1.1 200 OK Date: Mon, 08 Dec 2014 02:40:56 GMT Server: Apache Content-Length: 4572 Content-Type: application/json { "access": { "token": { "issued_at": "2015 05 19T07:08:21.927295", "expires": "2015 05 20T07:08:21Z", "id": "sample00d88246078f2bexample788f7", "tenant": { "name": "example00000000", "enabled": true, "tyo1_image_size": "550GB", } ], "endpoints_links": [], "type": "mailhosting", "name": "Mail Hosting Service" }, { "endpoints": [ { "region": "tyo1", "publicURL": "https://dns service.tyo1.conoha.io" } ], "endpoints_links": [], "type": "dns", "name": "DNS Service" }, { "endpoints": [ { "region": "tyo1", "publicURL": "https://object storage.tyo1.conoha.io/v1/nc_a4392c0ccba74485abd58ec123eca824" } ], "endpoints_links": [], "type": "object store", "name": "Object Storage Service" }, { "endpoints": [ { "region": "sjc1", "publicURL": "https://identity.sjc1.conoha.io/v2.0" }, { "region": "tyo1", "publicURL": "https://identity.tyo1.conoha.io/v2.0" }, { "region": "sin1", "publicURL": "https://identity.sin1.conoha.io/v2.0" } ], "endpoints_links": [], "type": "identity", "name": "Identity Service" } ], "user": { "username": "example00000000", "roles_links": [], "id": "examplea6963c074d7csample12a886ee", "roles": [ { "name": "SwiftOperator" }, { "name": "_member_" } ], "name": "example00000000" }, "metadata": { "is_admin": 0, "roles": [ "0000000000000000000000000000000e", "11111111111111111111111111111113" ] } } } サービス一覧取得 Database API v1 Description データベースサービスの一覧を取得します。 Request URL Database API v1.0 GET /v1/services Request Paramters Parameter Value Style Type Description X Auth Token header string Userトークン offset(Optional) query int 取得開始位置 Default:0 limit(Optional) query int 取得数 Default:1000 sort_key(Optional) service_name/status/create_date query string ソートキー Default:create_date sort_type(Optional) asc/desc query string ソート順 Default:asc Response Paramters Parameter Value Style Type Description services list service_id plain UUID サービスID service_name plain string サービス名 create_date plain string 作成日時 quota plain int 使用容量上限値（単位GB） total_usage plain float 使用容量合算値（単位GB）、小数点第二位まで表示 status active/suspended/pending/creating/deleting/error plain string ステータス backup enable/disable plain string バックアップ有効フラグ prefix plain string プレフィックス metadata plain dict メタデータ キーと値の辞書オブジェクト total_count plain int 総件数 current_count plain int 現在の取得件数 Request Json This operation does not accept a request body. Normal response codes 200 Success Error response codes 400 Bad Request 401 Access Denied Repeatable Yes Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ curl i X GET \ H "Accept: application/json" \ H "Content Type: application/json" \ H "X Auth Token: 39be9f8d53044388b7f2e867eba8b140" \ https://database hosting.tyo1.conoha.io/v1/services RES HTTP/1.1 200 Success Date: Tue, 09 Dec 2014 01:46:58 GMT Server: Apache Content-Length: 1003 Content-Type: application/json { "services" : [ { "service_id": "9d6441f6 c5a0 4dcf a1a9 1a4d724e51fd", "service_name": "dbservice01", "create_date": "2012 11 02T19:56:26Z", "quota": 10, "total_usage": 2.25, "status": "active", "backup": "disable", "prefix" : "02p8y", "metadata" : { "key" : "value" } }, { "service_id": "ff164ba8 42d1 49d3 a597 a98503f6fd45", "service_name": "dbservice02", "create_date": "2012 11 02T19:56:26Z", "quota": 30, "total_usage": 14, "status": "active", "backup": "enable", "prefix" : "8ypg0" "metadata" : { "key" : "value" } } ], "total_count":100, "current_count":10 }----------Document 2: 請求データ一覧取得 Account(Billing) API v1 Description 課金アイテムへの請求データ一覧を取得します。 Request URL billing API v1 GET /v1/{tenant_id}/billing invoices Request Paramters Parameter Value Style Description X Auth Token Userトークン header トークンID tenant_id Tenant ID URI テナントID offset(Optional) 取得開始位置 query Default:0 limit(Optional) 取得数 query Default:1000 Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ curl -X GET \ -H "Accept: application/json" \ -H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \ https://account.tyo1.conoha.io/v1/487727e3921d44e3bfe7ebb337bf085e/billing-invoices?limit=3 RES HTTP/1.1 200 OK Server: openresty/1.7.10.1 Date: Fri, 08 May 2015 12:52:02 GMT Content-Type: application/json Content-Length: 230 Connection: keep-alive { "billing_invoices": [ { "invoice_id": 00001, "payment_method_type": "Charge", "invoice_date": "2014 08 01T00:00:00", "bill_plas_tax": 500, "due_date": "2014 08 01T00:00:00" }, { "invoice_id": 00002, "payment_method_type": "Charge", "invoice_date": "2014 07 01T00:00:00", "bill_plas_tax": 500, "due_date": "2014 07 01T00:00:00" }, { "invoice_id": 00003, "payment_method_type": "Charge", "invoice_date": "2014 06 01T00:00:00", "bill_plas_tax": 500, "due_date": "2014 06 01T00:00:00" } ] } }----------Document 3: 入金サマリー取得 Account(Billing) API v1 Description 入金のサマリーを取得します。 Request URL billing API v1 GET /v1/{tenant_id}/payment summary Request Paramters Parameter Value Style Description X Auth Token Userトークン header トークンID tenant_id Tenant ID URI テナントID Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ curl -i -X GET \ -H "Accept: application/json" \ -H "X-Auth-Token: 35941e7df872405d84e5b026dba8323c" \ https://account.tyo1.conoha.io/v1/487727e3921d44e3bfe7ebb337bf085e/payment-summary RES HTTP/1.1 200 OK Date: Wed, 24 Dec 2014 04:36:31 GMT Server: Apache Content-Length: 141 Content-Type: application/json { "payment_summary": { "total_deposit_amount": 1000 } }----------Document 4: イメージ一覧取得(Glance) Image API v2 Description イメージ一覧を取得 Request URL Image 一覧API v2 GET /v2/images Request Paramters Parameter Value Style Description X-Auth-Token Userトークン header トークンID name (Optional) query イメージ名 visibility (Optional) query 公開(public) または、非公開(private) を指定 member_status (Optional) query イメージメンバーの状態でフィルター owner (Optional) query イメージ所有者(テナントID指定) status (Optional) query イメージの状態 size_min (Optional) query イメージの最小サイズ。単位は bytes size_max (Optional) query イメージの最大サイズ。単位は bytes sort_key (Optional) query ソート対象となる項目。Deault:created_at sort_dir (Optional) query ソートする方向性 default:desc tag (Optional) query イメージタグでフィルター Normal response codes OK (200) Example ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQ curl i X GET \ H "Accept: application/json" \ H "X Auth Token: 35941e7df872405d84e5b026dba8323c" \ https://image service.tyo1.conoha.io/v2/images RES HTTP/1.1 200 OK Date: Tue, 09 Dec 2014 10:17:20 GMT Server: Apache Content-Length: 6102 Content-Type: application/json { "images": [ { "status": "active", "name": "testsnap", "tags": [], "container_format": "ovf", "created_at": "2014 12 05T13:16:57Z", "size": 3134390272, "disk_format": "qcow2", "updated_at": "2014 12 05T13:17:14Z", "visibility": "private", "id": "e9a36da8 5c2e 4d8c a7a4 db32e7054d34", "self": "/v2/images/e9a36da8 5c2e 4d8c a7a4 db32e7054d34", "min_disk": 0, "protected": false, "min_ram": 0, "file": "/v2/images/e9a36da8 5c2e 4d8c a7a4 db32e7054d34/file", "checksum": "238c596d2aa5c4c1daa101c4eb3682ff", "owner": "65a85d8e02e7470da8f72ed31effaf4e", "direct_url": "file:///var/lib/glance/images/e9a36da8 5c2e 4d8c a7a4 db32e7054d34", "hw_qemu_guest_agent": "yes", "schema": "/v2/schemas/image" }, { "status": "active", "name": "okvm centos65_ga_fio", "tags": [], "container_format": "ovf", "created_at": "2014 12 05T13:09:24Z", "size": 3135963136, "disk_format": "qcow2", "updated_at": "2014 12 05T13:09:41Z", "visibility": "private", "id": "7e8ef227 9000 46f2 82b4 c7d68f1bcf96", "self": "/v2/images/7e8ef227 9000 46f2 82b4 c7d68f1bcf96", "min_disk": 0, "protected": false, "min_ram": 0, "file": "/v2/images/7e8ef227 9000 46f2 82b4 c7d68f1bcf96/file", "checksum": "5331449d33377d47459628542f542d4d", "owner": "65a85d8e02e7470da8f72ed31effaf4e", "direct_url": "file:///var/lib/glance/images/7e8ef227 9000 46f2 82b4 c7d68f1bcf96", "hw_qemu_guest_agent": "yes", "schema": "/v2/schemas/image" }, { "status": "active", "name": "okvm centos65", "tags": [], "container_format": "ovf", "created_at": "2014 12 05T12:33:00Z", "size": 2967273472, "disk_format": "qcow2", "updated_at": "2014 12 05T12:33:18Z", "visibility": "private", "self": "/v2/images/7b85762c 23d0 4ed0 805b b5a0604049a2", "min_disk": 0, "protected": false, "id": "7b85762c 23d0 4ed0 805b b5a0604049a2", "file": "/v2/images/7b85762c 23d0 4ed0 805b b5a0604049a2/file", "checksum": "765f4a4670240bcd1e7f40fe5e655c90", "owner": "4a9f0a43587e46258d6b0feb45b58b31", "direct_url": "file:///var/lib/glance/images/7b85762c 23d0 4ed0 805b b5a0604049a2", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "okvm centos65_ga", "tags": [], "container_format": "ovf", "created_at": "2014 12 05T12:32:10Z", "size": 2967273472, "disk_format": "qcow2", "updated_at": "2014 12 05T12:32:26Z", "visibility": "public", "id": "0481cc6f 5cee 474c bdf3 b46c793a94ec", "self": "/v2/images/0481cc6f 5cee 474c bdf3 b46c793a94ec", "min_disk": 0, "protected": false, "min_ram": 0, "file": "/v2/images/0481cc6f 5cee 474c bdf3 b46c793a94ec/file", "checksum": "5ada4a66c2598d39fb6aacc6731aeae4", "owner": "4a9f0a43587e46258d6b0feb45b58b31", "direct_url": "file:///var/lib/glance/images/0481cc6f 5cee 474c bdf3 b46c793a94ec", "hw_qemu_guest_agent": "yes", "schema": "/v2/schemas/image" }, { "status": "active", "name": "okvm centos65", "tags": [], "container_format": "ovf", "created_at": "2014 12 03T08:22:44Z", "size": 2967273472, "disk_format": "qcow2", "updated_at": "2014 12 03T08:23:02Z", "visibility": "public", "self": "/v2/images/765acb4f e4df 4f9f a37c e062df376504", "protected": false, "id": "765acb4f e4df 4f9f a37c e062df376504", "file": "/v2/images/765acb4f e4df 4f9f a37c e062df376504/file", "checksum": "765f4a4670240bcd1e7f40fe5e655c90", "min_disk": 0, "direct_url": "file:///var/lib/glance/images/765acb4f e4df 4f9f a37c e062df376504", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "cirros 0.3.3 x86_64", "tags": [], "container_format": "bare", "created_at": "2014 12 03T07:48:41Z", "size": 13200896, "disk_format": "qcow2", "updated_at": "2014 12 03T07:48:42Z", "visibility": "public", "self": "/v2/images/3cab9d0f 29b1 45e3 b5fd 76e8d746b289", "protected": false, "id": "3cab9d0f 29b1 45e3 b5fd 76e8d746b289", "file": "/v2/images/3cab9d0f 29b1 45e3 b5fd 76e8d746b289/file", "checksum": "133eae9fb1c98f45894a4e60d8736619", "min_disk": 0, "direct_url": "file:///var/lib/glance/images/3cab9d0f 29b1 45e3 b5fd 76e8d746b289", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "cirros 0.3.3 x86_64", "tags": [], "container_format": "bare", "created_at": "2014 12 03T07:48:38Z", "size": 13200896, "disk_format": "qcow2", "updated_at": "2014 12 03T07:48:39Z", "visibility": "public", "self": "/v2/images/fd2cbdb5 b4dd 4afe 8409 fb2998ca50ef", "protected": false, "id": "fd2cbdb5 b4dd 4afe 8409 fb2998ca50ef", "file": "/v2/images/fd2cbdb5 b4dd 4afe 8409 fb2998ca50ef/file", "checksum": "133eae9fb1c98f45894a4e60d8736619", "min_disk": 0, "direct_url": "file:///var/lib/glance/images/fd2cbdb5 b4dd 4afe 8409 fb2998ca50ef", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "cirros 0.3.3 x86_64", "tags": [], "container_format": "bare", "created_at": "2014 12 03T07:42:58Z", "size": 13200896, "disk_format": "qcow2", "updated_at": "2014 12 03T07:42:59Z", "visibility": "public", "self": "/v2/images/a6f3a56f 0e21 4dfc b267 9df611034a5d", "protected": false, "id": "a6f3a56f 0e21 4dfc b267 9df611034a5d", "file": "/v2/images/a6f3a56f 0e21 4dfc b267 9df611034a5d/file", "checksum": "133eae9fb1c98f45894a4e60d8736619", "min_disk": 0, "direct_url": "file:///var/lib/glance/images/a6f3a56f 0e21 4dfc b267 9df611034a5d", "min_ram": 0, "schema": "/v2/schemas/image" }, { "status": "active", "name": "cirros 0.3.3 x86_64", "tags": [], "container_format": "bare", "created_at": "2014 12 03T07:41:52Z", "size": 13200896, "disk_format": "qcow 以下は ContextualCompressionRetriever で検索結果を ChatGPT で要約してから表示しています。（そのため検索するたびにリクエストはガンガン発生します。） from langchain.chat_models import ChatOpenAI from langchain.retrievers import ContextualCompressionRetriever from langchain.retrievers.document_compressors import LLMChainExtractor from langchain.retrievers.document_compressors import EmbeddingsFilter from langchain.document_transformers import EmbeddingsRedundantFilter from langchain.retrievers.document_compressors import DocumentCompressorPipeline from langchain.text_splitter import CharacterTextSplitter llm = ChatOpenAI(temperature=0, verbose=True) compressor = LLMChainExtractor.from_llm(llm) compression_retriever = ContextualCompressionRetriever(base_compressor=compressor, base_retriever=retriever, verbose=True ) compressed_docs = compression_retriever.get_relevant_documents(q) print_docs(compressed_docs) 要約版のベクターストアのドキュメント検索結果。取得してからChatGPTが要約しています。最初の素のベクター検索結果に比べてだいぶ簡素です。結構情報が抜けているとも言えます。 Document 1: トークン発行 有効なトークン情報を取得する POST /v2.0/tokens { "auth": { "passwordCredentials": { "username": "ConoHa", "password": "paSSword123456#$%" }, "tenantId": "487727e3921d44e3bfe7ebb337bf085e" } } 200 OK サービス一覧取得 GET /v1/services X-Auth-Token: 39be9f8d53044388b7f2e867eba8b140 { "services" : [ { "service_id": "9d6441f6c5a04dcfa1a91a4d724e51fd", "service_name": "dbservice01", "create_date": "2012-11-02T19:56:26Z", "quota": 10, "total_usage": 2.25, "status": "active", "backup": "disable", "prefix" : "02p8y", "metadata" : { "key" : "value" } }, { "service_id": "ff164ba842d149d3a597a98503f6fd45", "service_name": "dbservice02", "create_date": "2012-11-02T19:56:26Z", "quota": 30, "total_usage": 14, "status": "active", "backup": "enable", "prefix" : "8ypg0" "metadata" : { "key" : "value" } } ], "total_count":100, "current_count":10 } ---------- Document 2: "Userトークン" ---------- Document 3: 入金のサマリーを取得します。 トークンID ---------- Document 4: GET /v2/images Request Paramters Parameter Value Style Description X-Auth-Token Userトークン header トークンID  最後に ContextualCompressionRetriever とは少し違うアプローチで使える検索結果のフィルター処理を紹介します。DocumentCompressorPipeline で複数の処理を実行し、検索結果に処理を入れて減らしていきます。実はこれが一番役に立つかも。 from langchain.chat_models import ChatOpenAI from langchain.text_splitter import CharacterTextSplitter from langchain.retrievers.document_compressors import EmbeddingsFilter from langchain.document_transformers import EmbeddingsRedundantFilter from langchain.retrievers.document_compressors import DocumentCompressorPipeline # この例ではまずはじめに普通にベクターストアを検索する docs = retriever.get_relevant_documents(question) ### フィルター処理の設定 # 1 検索結果ドキュメントをさらに分割。小分けにして増やす。 # 1つのチャンクが長い場合、重要なところにフォーカスを上げる splitter = CharacterTextSplitter(chunk_size=500, chunk_overlap=0, separator="\n") # 2 質問プロンプト文と類似しすぎている検索結果を排除する。 redundant_filter = EmbeddingsRedundantFilter(embeddings=embeddings) # 3 小さくしたドキュメントのEmbeddingsを改めて作成し、質問プロンプト文との類似性を比較。しきい値以下を排除 relevant_filter = EmbeddingsFilter(embeddings=embeddings, similarity_threshold=0.80) # 各フィルターをDocumentCompressorPipelineでつないで、検索結果を減らす処理を行う pipeline_compressor = DocumentCompressorPipeline( transformers=[splitter, redundant_filter, relevant_filter] ) filterd_docs = pipeline_compressor.compress_documents(docs, question) print_docs(filterd_docs)  結果、いいかんじになっています。 Document 1: Conoha API トークン発行 Identity API v2.0 Description 有効なトークン情報を取得する Request URL identity API v2.0 POST /v2.0/tokens Request Paramters Parameter Value Style Description username ユーザー名 plain ユーザ名 password ユーザーパスワード plain ユーザパスワード tenantId (Optional) Tenant ID plain テナントID Request Json { "auth": { "passwordCredentials": { "username": "ConoHa", "password": "paSSword123456#$%" }, "tenantId": "487727e3921d44e3bfe7ebb337bf085e" } } Normal response codes 200 OK Example ---------- Document 2: ※エンドポイントURLにつきましては、お客様環境によって異なりますので、コントロールパネルにてご確認の上ご利用ください。 REQUEST curl i X POST \ H "Accept: application/json" \ d '{"auth":{"passwordCredentials":{"username":"ConoHa","password":"paSSword123456#$%"},"tenantId":"487727e3921d44e3bfe7ebb337bf085e"}}' \ https://identity.tyo1.conoha.io/v2.0/tokens RESPONSE HTTP/1.1 200 OK Date: Mon, 08 Dec 2014 02:40:56 GMT Server: Apache Content-Length: 4572 Content-Type: application/json { "access": { "token": { "issued_at": "2015 05 19T07:08:21.927295", ---------- Document 3: header string Userトークン offset(Optional) ... （20まで続く）  refine の中でChatGPT回答が複数得られるので回答同士の類似度を判定する 上記の例では、関係のない文書も含めて要約したりEmbbedingしたりするのでOpenAI API実行回数がだいぶ多いです。別のアプローチとして、LangChainやLlamaindexで用いられる refine の処理の途中で、回答同士の変化度の判定を行います。例えば、回答1から回答2に変更があった場合に回答2に価値があるとみなすことができます。類似度・関連度を活用するのとは逆のアプローチになると思います。 そもそも人間でも精査が難しいということもあると思っていて、全部の検索結果を表示してしまうのも別にいいのではと思ったりします。 E. ベクターストアの選定 ベクトルDB、ベクター検索エンジンなど様々な呼ばれ方をしていますが、類似した文書を高速に検索することができます。 結論として私はまだ選定の最適解に到達していません。なのでここはおまけです。 Githubのスター数でランキングを作っているサイトがありました。こちらは非常に参考になります。https://byby.dev/vector-databases Faiss がスター数でも知名度でも一番です。 ユースケース別に考えると、以下のような視点があります。 １）既存のDB運用があるのでそこに混ぜていきたいpgvector ２）マネージドで他のシステムに影響なく独立して運用したい＋大きなデータセットになった場合のスケーラビリティがあるElasticSearchmilvuspinecone こちらに出ていないものとして最近の注目株は Chroma があります。https://www.trychroma.com/ 個人的に Chroma の強みと感じているのは metadata を付与できる部分です。こちらは検索フィルタとして利用できるので、検索精度を上げることができます。公式の例では { status: [read/unread] } というステータス値を管理させています。https://github.com/chroma-core/chroma/blob/main/examples/basic_functionality/where_filtering.ipynbドキュメントの種類が広範囲にわたる場合はこの metadata にカテゴリ名などタグ付けをしていくことで検索精度を改善できると思います。LangChain, LlamaIndex と連携できる API があり、実装上は簡単にいける点も魅力的です。 まとめ A. ベクターストアに入れる元ネタドキュメントの抽出⇒ unstructured が使えるかも B. ベクターストアに入れる元ネタドキュメントのチャンク分け⇒ タイトル。キーワードをメタデータで付加 C. ベクターストアに投げる質問プロンプトの最適化⇒ 形態素またはキーワード抽出でプロンプトを精査 D. ベクターストア検索結果の精査⇒ ContextualCompressionRetrieverによる検索結果要約とDocumentCompressorPipelineによる検索結果精査がよさげ E. （おまけ）ベクターストアの選定⇒ 1位はFaiss。マネージドも多々あり。Chromaがこれから来るかも。 まだ全体としては不十分な点が多々ありますが、「検索結果が質問に沿ったものか精査させる」タスクをChatGPTに担当してもらうことが私の業務課題には適しているのでは。。という気づきがありました。これは大いなる前進です。元の目的は「検索結果の精度を上げてChatGPTが正確な回答ができるようにする」という点がありましたが、そこにこだわるのではなく、検索精度の向上自体をChatGPTに手伝ってもらうことが業務効率化につながる道が見えてきたので、この点をさらに研ぎ澄ましていこうと思います。 現在公開可能な情報は以上です。 最後に宣伝 次世代システム研究室では、最新のテクノロジーを調査・検証しながらインターネットのいろんなアプリケーションの開発を行うアーキテクトを募集しています。募集職種一覧 からご応募をお待ちしています。

こんにちは、GMOインターネットグループ株式会社 ネットワークソリューションチームの梅崎です今回は主にサーバー管理者/アプリ開発者向けに「ネットワークが繋がらない、通信ができない」となったときの・ クライアント/サーバー側で可能なトラブルシュート方法・ ネットワーク管理者へ調査依頼を出す際に我々が欲しい情報をまとめてみました今回はそのエラー内容特定編です 注意事項 基本的には上からなぞっていけば大丈夫な形にはしていますがWindows機などはコマンドが違うことが多くコメントでやりたいことを記載しているので同様の情報を取得できるものを探していただければと思います あと、IPv6の調査はあまりやったことは無いですが基本的にはトラブルシュート方法は変わらずコマンドにIPv6用のオプションをつければ大丈夫だと思います どんなエラーなのかを特定 この章では最低限、通信の問題なのかクライアント/サーバーのアプリケーション的なエラー、設定の不備なのかを切り分けする方法を記載しています ブラウザ等で404や403といった4xxエラーが表示される クライアントとサーバーとの通信は問題ないです「URLが誤っている」かサーバーで「ファイルが存在しない」、「アクセスを許可していない」等が原因のため URLの再確認とWebサーバー側の設定の確認が必要です ブラウザ等で500や504といった5xxエラーが表示される クライアントとサーバーとの通信は問題ないですサーバー側のエラーやバックエンドが落ちているなどが原因の可能性が高いです サーバー、バックエンド側のログの確認が必要です ※サーバーとバックエンドの「通信に問題がある場合(作成中)」を参照してください 名前解決に失敗する 「URLが誤っている」か「DNSサーバーの設定が無い」「リゾルバの設定がされていない/間違えている」かなと思いますURLの再確認とDNSサーバー側の設定の確認、クライアント側のリゾルバの設定の確認が必要です タイムアウトエラーが表示される(Webに限らず) クライアントとサーバーとの通信に問題があるかサーバー側が落ちている、アクセスするIPアドレスに誤りがある可能性があります IPアドレスの再確認とサーバー側が落ちていないかを下記コマンド等で確認する必要があります ※コマンドの結果が問題ない場合は、「通信に問題がある場合(作成中)」を参照してください # プロセスが待ち受ける、バインドするIPアドレス/port等を確認 # 「*」は全IPアドレスで待ち受けている状態です、特定のIPアドレスが表示されることがあります # HTTP ならば TCP *:80, HTTPSならば TCP *:443などのことが多いです sudo lsof -i -P -nn # 出力例 # COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME # snmpd 1364 Debian-snmp 6u IPv4 43174 0t0 UDP *:161 # sshd 1387 root 3u IPv4 68716 0t0 TCP *:22 (LISTEN) # docker-pr 67965 root 4u IPv4 50378714 0t0 TCP *:443 (LISTEN) # docker-pr 67978 root 4u IPv4 49454775 0t0 TCP *:80 (LISTEN) 最後のLISTENの箇所のIPアドレスとポート番号が意図したものであることそもそも意図した行が存在することを確認してください IPアドレスやポート番号が意図と異なる場合はサーバー側の設定に不備があります 行自体が存在しない場合は大抵プロセスが落ちています サーバーの設定等の調査をしてください tcp/udpのポート番号がそれぞれ何用途かはWikipediaや IANAのページ などに書かれているので詳細はそれらを参照ください 「アクセスが拒否されました」等が表示される(Webに限らず) クライアントとサーバーを含む通信経路上でアクセス拒否する設定(ファイアウォール, ACL, iptables等)がされている可能性が高いですまた、サーバー上のプロセスが落ちている場合もこの表示になる場合があります 前項「タイムアウトエラーが表示される」と同様に下記コマンドで調査してください ※コマンドの結果が問題ない場合は、「アクセス拒否されている場合(作成中)」を参照してください # プロセスが待ち受けるport等が問題ないかを確認 sudo lsof -i -P -nn なんとなく重い、特定時間だけ不調になる 原因として思いつくだけでもDDoS, プログラムのバグ, クライアント/サーバーの過負荷, 通信の輻輳, 通信経路上での物理故障, etc... 本腰を入れた調査が必要なので サーバー管理者、ネットワーク管理者を巻き込んで調査してください 調査に当たっては下記の情報が欲しいです 必須 ・具体的な事象の説明 　☓「通信エラーがでている」 　○「画面に□□というメッセージが表示されている」 　○「△回に▲度□□というメッセージが表示される」 　○「動作に■秒かかるようになった」 ・クライアントのIPアドレス 　「192.0.2.123/24」や「192.0.2.123 255.255.255.0」等 ・サーバーのIPアドレス ・サーバーのプロトコル 　TCP/UDP/ICMP等とport番号 ・事象を確認した時間帯 　最低限、一時間単位で正確なものがありがたいです 利用していれば必須 ・クライアントのVLAN番号 ・クライアント名、位置情報等 ・クライアントを接続しているスイッチ名とスイッチのインターフェース番号 ・サーバーのVLAN番号 ・サーバー名、位置情報等 ・サーバーを接続しているスイッチ名とスイッチのインターフェース番号 あれば ・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト