技術情報 の記事一覧

こんにちは、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番号 ・サーバー名、位置情報等 ・サーバーを接続しているスイッチ名とスイッチのインターフェース番号 あれば ・画面のスクショやログのコピー ※秘匿情報以外は加工せず生情報の方がベスト

GMOペパボ株式会社、デベロッパーエキスパートの黒瀧と申します。先月、技育CAMPにて「ブロックチェーンアプリケーション開発入門」というタイトルで講義を行いました。 登壇内容はこちら https://developers.gmo.jp/36511/ Web3の歴史と実際のサービスでの応用について 1990年代のWeb1の時代から現在のWeb3の時代までを振り返り、それぞれのアーキテクチャの基盤となる技術やコミュニケーションの方法を解説しました。Web2.5として、ブロックチェーンネットワークと既存のシステムが共存する形のSUZURIのNFTを利用したグッズ作成の事例も紹介しました。 NFTオリジナルグッズ販売の流れ (SUZURI) ブロックチェーンとスマートコントラクト Ethereumブロックチェーンを中心に、ブロックチェーンについて解説しました。スマートコントラクトやブロックチェーンネットワークの種類、ユースケースなどを取り上げました。アイデンティティに関しては、DID（Decentralized Identifier）として、個人がIDを管理し、必要な情報を適切な範囲で共有できる仕組みを説明しました。さらに、卒業証明のOpenCerts (https://www.opencerts.io/) のような取り組みも取り上げました。 Ethereumのユースケースの紹介 最後に、SolidityとSolidity Compilerの仕組みを解説し、今後の学習リソースとしての環境や書籍を紹介しました。取り上げた資料(一部)は以下の通りです。 Remix https://remix.ethereum.org/scaffold-eth: https://github.com/scaffold-eth/scaffold-ethWEB+DB PRESS Vol.130: https://gihyo.jp/magazine/wdpress/archive/2022/vol130 作って学ぶWeb3: ブロックチェーン、スマートコントラクト、NFTマスタリング・イーサリアム: スマートコントラクトとDAppの構築: https://www.oreilly.co.jp/books/9784873118963/Cryptozombies: https://cryptozombies.io/jp/ 最後に 参加者の皆様から多くの質問をいただき、あっという間の60分でした。Web3に関する取り組みはまだ発展途上ですが、将来的に私たちの生活に密接に関わるテクノロジーとなるでしょう。今回の講義が参加者の皆様の学びのきっかけになれば幸いです。ご参加いただいたみなさま、ありがとうございました。

こんにちは。デベロッパーリレーションズチームの儀部です。携わっているPJでTestimというテストツールをトライアルで導入しましたので、本記事で紹介させていただきます。 Testimとは TestimはAIを利用したE2Eのテスト自動化ツールです。テストの作成・実行・管理が簡単にできるため、テストの作成やメンテナンスにかかる時間を削減することができます。https://www.testim.io/ Autify、mabl、MagicPodなど類似のテスト自動化ツールもありますが、制限があるものの、Testimはフリープランも提供しているため導入してみました。 Testimの主な特徴 スマートロケーター 画面要素を見つけるためにAIが使用され、複数の属性を使用して要素を特定します。デザイン変更や要素の移動などアプリケーションが変化してもテストが壊れにくくなり、テストの信頼性を高めます。 オートメンテナンス Testimの自動保守機能は、画面要素などが変更されたときに自動的にテストケースを更新します。これにより開発者が手動でテストケースを修正する時間が削減できます。この機能によってテストの更新と保守がとても簡単になります。 テスト失敗時の詳細レポート テスト失敗時には詳細なレポート画面が確認できます。失敗した原因に加え、期待値と実行結果とのスクリーンショットの比較やネットワークログなど、テストケースを解析し問題を解決するのに必要な情報が表示されます。 豊富なサポート アカウントのセットアップから拡張機能、TestOpsといった内容まで含まれており、英語版ですがドキュメントは充実しています。また、時差がある中でもチャットの応答が遅すぎることはなく、手厚くサポートしてくれます。 Testimの使い方 簡単な使い方の流れをキャプチャー交えて説明します。 セットアップ アカウント（メールアドレス・パスワードを入力）を作成後、下記のChrom拡張機能をインストールします。https://chrome.google.com/webstore/detail/testim-editor/pebeiooilphfmbohdbhbomomkkoghoia テストケース作成 右上の赤い「Start recording」ボタンをクリックする。 テストケース編集画面 URLを入力する。 URL入力モーダル 新規でブラウザが立ち上がり、右下にレコーディングしている旨のメッセージが表示される。※フリープランはブラウザにChromeしか選択できないので注意 レコーディング画面 あとは検索ボックスへの入力やボタンのクリックなど、ユーザーの動きをレコーディングしてくれます。レコーディングを終了したい場合は、右下の赤い停止ボタンをクリックします。 テストケース実行 テストケース実行時のデモになります。 実行時のデモ 検索後に表示したページは私が以前記載したブログになります。拙い文章で恐縮ですが、お時間ある方はこちらもお読みいただけますと幸いです。急な宣伝で失礼いたしました(笑) https://developers.gmo.jp/29462/ まとめ 今回はTestimの紹介をさせていただきました。デモの通りで、テストケースの作成～実行まで簡単にできます。また、まだまだ便利な機能があるので、もっと使ってみたいと思いました。 AIが使用されている かつ フリープランの場合は無料で使えるので、とても便利なツールだと感じました。ぜひ皆さまも導入されてみてはいかがでしょうか。

9月1日〜3日に早稲田大学およびニコニコ生放送にてハイブリッド開催された技術カンファレンス「iOSDC Japan 2023」のスポンサーセッションにGMOペパボ株式会社の酒井 文也（＠fumiyasac）が登壇しました。セッションでは、ハンドメイドマーケット「minne」のiOSアプリ開発における歴史や現状の取り組みについて紹介しました。 登壇者 酒井 文也　＠fumiyasacGMOペパボ株式会社  minne事業部 プロダクト開発チーム シニアエンジニア https://speakerdeck.com/fumiyasac0921/minnewotong-zitegan-zitali-shi-tosonoxian-wojian-ju-etaqu-rizu-miyatiao-zhan-nihong-rete 歴史ある大規模サービスを開発・運用することのやりがいと課題 2012年1月に誕生したminneは、ハンドメイド作品を買いたい人と売りたい人をつなぐ国内最大のハンドメイドマーケットとして成長してきました。minneは、パソコンやスマートフォンを利用して簡単にハンドメイド作品を販売・購入できるプラットフォームであり、作家・購入者の両方をターゲットとしています。 そのため、多種多様な決済方法、ギフトチケット、海外配送、アクセス機能解析など、さまざまな機能があるのが特徴です。また、作品の閲覧やお気に入り追加などの操作の際に心地よいアニメーションや細かなインタラクションを用いるなど、シンプルなUIと作品を活かすための動きや表現に工夫が施されています。 今年で誕生から11年を迎える歴史あるサービスだからこそ、自身の成長や開発のやりがいにつながる面もあると酒井は語ります。 「コードベースが大きく多彩な機能を持つが、大規模な機能開発や運用のノウハウの片鱗に向き合う機会もしばしばある。たとえば、仕組み化や自動化を積極的に推進する取り組みや、パターン化された手順等のアプローチは目を見張るものがある。アプリの性質上、サーバー側での処理連携が必要になるので、Webエンジニアとの積極的なコラボレーションをする機会が多いのも特徴」（酒井） 一方で、「規模が小さいときには問題にはならなかったような部分が、大きな落とし穴になってしまうことがある。修正するコードや設定自体は些細なものでも、その影響がどこまで及ぶのか、現時点だけでなくその先も見据えて検討し、進めていかなければならない難しさ・奥深さがある」と、歴史が長く大規模であるがゆえの課題もあると酒井は指摘します。 先人たちが築いた歴史から学ぶ知見 酒井によると、minneでは「故きを温ねて新しきを知る」という精神が根付いているといいます。酒井は「言い換えれば、現状を正しく把握したうえでその先を見据えた取り組みをするよう実践してきた。これはGitHub上に残っているIssueやPull Requestでも感じることができる。それが今日の開発にもいかされている」と説明します。そのうえで、minne iOSアプリのアーキテクチャに関する全体の方針について紹介しました。 minneのiOSアプリでは、Combineフレームワークを利用したMVVMアーキテクチャをベースにした構成を採用しています。酒井は「この形に至るまでの議論や検討の軌跡が社内に残されていた。先輩社員からオンボーディング時にレクチャーを受けたときに、なぜそうしたかということが明確に言語化されていたのが印象的」とminneの開発に関わり始めた当時について話します。 過去には、Reduxに近い構造を有する単一方向のデータフローで管理する「The Composable Architecture」を検討した経緯もあったといいます。これは、状態管理が複雑で、MVVMアーキテクチャを利用しても大変に感じる場面も少なからずあったことから、選択肢の候補として検討されていました。ただ結果的には、検討および一部画面での試験導入までとなりました。酒井は「私自身、過去にiOSアプリ開発にReduxを利用した経験があったので、実際にこの過程は勉強になった」と振り返りました。 このように、普段から開発や設計に関する議論が活発に行われていることもあり、平素の開発ではドキュメントを交えてコミュニケーションする文化があるといいます。たとえば、minneのiOSアプリ開発では、必要な情報がまとめられたWikiがつくられています。「特に運用やデバック手段に関する知見、アプリ内で用いられている他サービスとの連携部分などは今でも参考にしている」と酒井は説明します。 また、下記は以前に酒井がまとめた決済に関するNotionの抜粋です。 Notionを作成した経緯について酒井は、「minneは、WebやiOSアプリでApple pay決裁をいち早く導入したサービス。Amazon Payやキャリア決済など数々の決済手段を整えていることから、特に複雑な部分について自分の復習も兼ねて概要を改めて確認できるよう整理した」と紹介しました。 「その先を見据えた取り組み」に関する事例 続いて酒井は、自身や先輩社員が実践してきた、あるいは現在行っている「その先を見据えた取り組み」に関する事例を紹介しました。 1. MVVM + SwiftUIへリプレイスする取り組み まずは、SwiftUIへのリプレイスです。現在minneでは、UIKitを利用している画面もまだ多くありますが、いくつかのシンプルな画面から少しずつSwiftUIを導入していく取り組みを進めています。このメリットとして酒井は「View要素関連処理がシンプルになり、読みやすくテストしやすい形にできる余地が大いにある」ことをあげます。一方で、最新のUICollectionViewを活用した処理を使うほうが良いケースもあるため、方針については機能や画面に応じて都度検討しています。現在のSwiftUIでは実現しにくい細かな部分や足りない部分においては、UIKitおよびUIViewRepresentableで補うようにしているといいます。 ここで酒井は、参加者に対して「次の画面のうちSwiftUI製の画面はどれか」というクイズを出題しました。 正解は、「注文内容確認」画面です。これは、minne iOSアプリで購入を確定する際に表示される画面です。酒井は「表示要素が多い画面でも、SwiftUIが利用できる余地は増えていると感じている。バージョンやデザイン面での制約を受ける場合はあるが、メリットも大きいので引き続き取り組んでいく所存」とコメントしました。 実際に酒井がSwiftUI＋MVVM構成へリプレイスした際の解説記事が下記のブログにて公開されています。興味のある方はこちらもあわせてご覧ください。 minne iOS内のUIKit+MVC構成画面をSwiftUI+MVVM構成へのリプレイスした時の振り返り https://tech.pepabo.com/2023/05/24/minne-ios-refactoring-swiftui/ 2. iOSアプリの基盤部分の変化へできる限り追従する挑戦 現在minneでは、施策と並行しながら、特に機能の根幹を成すものや自動化の要となるOSSについては、動向やバージョンアップを定期的に確認し、できる限り最新のものに追従していくようにしています。具体例としては、酒井の先輩社員が対応したというApollo iOSのver0.xからver1.xへのバージョンアップ事例を紹介しました。コマンドラインツールや内部処理をはじめとする抜本的な内容が含まれたかなり大きなアップデートだったといいます 3. 施策や調整時のデザイナー・Webエンジニアと積極的な関わりや共同作業 施策や調整時においては、モバイルアプリ担当者はもちろんですが、デザイナー・Webエンジニアとの連携が求められる場面も多くあります。酒井は「積極的な共同作業も忘れてはいけない大事な要素」と付け加えます。minneでは、iOSアプリ開発のエンジニアのなかにもRuby on RailsやGraphQL、Next.jsといったWebアプリの知見や経験を持つメンバーがおり、モバイルエンジニア、デザイナー、Webエンジニアの三者がコミュニケーションを重ねて良いものを作っていこうとするカルチャーがあります。 その他 ChatGPTを活用したPull Requestのサマライズ minneでは、AIの進化を追っていく動きも試験的に導入しているところです。たとえば、既存のCI環境のワークフローにおいて、Pull Request作成時、Build前にGitHub Actionsでdangerを実行し内容確認をするフローでChatGPTを活用してサマライズを追記するようにしています。つまり、Pull Requestとコードの差分から、どのような変更があったのか文章としてChatGPTが要約して説明してくれるというものです。酒井は「差分が大きい場合は解析ができないようなので不向きだが、細かな修正など内容次第ではかなり確信をついたところまで要約できるようになっている。昨今の変化に可能性を感じている」とコメントしました。 大規模かつ歴史あるアプリの開発に携わることの魅力とは iOSエンジニアというキャリアを軸に経験を積んできた酒井。かつてはバックエンドでの経験もあり、「Ruby on RailsやGraphQLなど、今後はよりサーバー側の機能と連動する部分の理解・知見を積み上げていきたい。また、直近ではAndroidの開発に携わっていたため、iOSとAndroidの共通点または相違点を見極めるための足がかりをつくっていきたい」と今後のビジョンについて述べました。そして、minneという歴史ある大規模なサービスの開発に携わってきた経験を踏まえ、次のように語り講演を締めくくりました。 「これまでの歴史や先人たちが残してくれた知見から学びを得て、未来を見据えた開発に携わっていけることが大規模かつ歴史あるアプリの開発に関われることの醍醐味。もちろん、その過程では大変な面も多々ある。大規模であるがゆえの課題もあるが、そこに向き合い、知見からヒントを得て、次につながるものにしていくという取り組みを進めている。ユーザーへの価値提供、そして良き歴史を残していくということが、私たちのチームにおけるこれからの使命」（酒井） アーカイブ 映像はアーカイブ公開しておりますので、まだ見ていない方、もう一度見たい方は 是非この機会にご視聴ください！ https://www.youtube.com/watch?v=sRnEXlPTZ0A

皆さんお久しぶりです。中村です。昨今はAI関連の技術の進歩が目覚ましいですね。今回は上記に関連して、会社の制度をふるふるに使って高性能GPUを買ったり/貸してもらったお話をさせていただこうと思います。 そもそもGPUって？ GPU（Graphics Processing Unit）は、コンピュータのグラフィックス処理を担当する半導体チップのことを指します。元々は、コンピュータゲームや動画再生などの高度なグラフィックス処理を効率的に行うために開発されました。GPUは多数の計算を同時に行うことが得意で、並列処理に特化しています。近年では、GPUの計算能力が高まったことで、グラフィックス以外の用途にも利用されるようになりました。特に、ディープラーニングや機械学習の分野でのデータ処理において、GPUはその高速な計算能力を発揮しています。GPUは現代のコンピュータ技術において、多岐にわたる用途での活躍が期待される重要なコンポーネントとなっています。by chatgpt で、GMOインターネットグループはどんな制度があるんですか？ GPUレンタル こちらは高性能GPUを貸りることができる制度です（期間は要相談）AI関連技術の採用推進をグループとして推していることもあり、学びやすい環境が整っています。 【パートナー向け「NVIDIA H100」および「NVIDIA L4」搭載サーバーの無償貸出】AI関係の研究開発・活用促進を目的に、NVIDIA社の最新GPU「NVIDIA H100」、「NVIDIA L4」を搭載したサーバーの短期間のグループパートナー向け無償貸出を開始します。これにより、新規サービスの実証実験や研究開発をスピーディーに行うことが可能になります。なお、GPUホスティングの環境は先に発表した（※1）「ConoHa for AI」と同等のもので、社内でのフィードバックを製品の質の向上につなげます。また研究開発やローカルでの画像生成AIの活用促進として、NVIDIA GeForce RTX™4090またはNVIDIA GeForce RTX™3080Tiを搭載した高性能ゲーミングノートパソコンもグループパートナーに対し短期貸出を開始し、トライアル利用の後、GMO インターネットグループ株式会社では同様のスペックのマシンを長期貸出可能にいたしました。GMOインターネットグループ株式会社他、グループ各社でのAI関連開発用機材としての採用を推進します。 詳細：https://www.gmo.jp/news/article/8454/ エンジニア支援制度（学ぼうぜ） こちらはGPUにかかわらず自分のスキルアップに繋がるものであれば使用可能な制度です。自分は資格取得やガジェットが多いですが、人によっては遠方勉強会の参加費等で利用する方もいます。 #スキルアップ補助制度「学ぼうぜ！」技術関連の書籍や最新ガジェットの購入、開発合宿への参加費など、スキルアップに繋がる事項にかかる費用を、年間10万円まで補助するプログラムです。エンジニア・クリエイターのスキルアップに対するモチベーションの向上を図るとともに、得た成果やスキル・ノウハウを社内で共有し合うことで、GMOインターネットグループ全体の技術力の向上を目的としています。 内容スキルや役職に関わらず、1人につき年間10万円までを補助補助対象技術書の購買、技術系雑誌の講読費用最新ガシェット機器個人利用・個人名義の機器購入費用の50％　※通信費は個人負担　会社支給のスマートフォンなどの買換えは全額補助研究対象とする他社サービスの利用料金開発合宿への参加費条件レポートの提出（効果・成果、得られたスキル・ノウハウの共有） 詳細：https://www.gmo.jp/csr/human-capital/engineer/ どっちの制度使ったの？ 結論どっちも使いました！ GPUレンタルで借りたGPU 個人では気軽に使えないようなGPUを借りました！条件にもよりますが画像生成AIなどの処理が数秒で終わるレベルのものです。 L4(データセンター向けGPU)RTX4090 16GB(Laptop version) Nvidia L4 RTX4090 Laptopシリーズ エンジニア支援制度（学ぼうぜ）で買ったGPU 個人では気軽に使えないようなGPUが自宅にも欲しいと思ってしまったので今年の補助を全部突っ込んで購入しました。 RTX4090 24GB(デスクトップPC用) ZOTAC GAMING GeForce RTX 4090 AMP Extreme AIRO White Edition そのGPUは何に使ったの？ 画像生成AIの生成速度比較などを試していました。画像生成AI（StableDufusion）については長谷川さんの記事が参考になるので是非どうぞ！ https://developers.gmo.jp/22831/ インフラサマーインターン 折角なので学生の方にも最新技術に触れられるようにインターンのカリキュラムに盛り込みました。実機を会場に持ち込み、目の前で動いている環境を構築しています。 手前：GPUレンタルで借用したRTX4090ノートPC、奥：学ぼうぜで購入したRTX4090導入したデスクトップPC 今回のカリキュラムでは、【作りたいものをイメージ→プロンプト作成→画像生成→振り返り】を繰り返し行い、画像生成AIを通してチームを表すフラッグを作ってもらいました。 気になった方はConoHa for AIをチェック！ ConoHaでも高性能GPUが使用できる仮想サーバーサービスが発表されています！サービスリリースはまだですが、気になる方は是非チェックよろしくお願い致します！https://www.conoha.jp/ai/teaser/

こんにちは、暗号のおねえさんことGMOインターネットグループ デベロッパーエキスパートの酒見(@ysakemin)です。2023年7月22日〜28日、アメリカ・サンフランシスコでInternet Engineering Task Force (IETF) 117 に参加しました。今回の参加目的としては、IETF117でHackathonに参加すること、IETFにおける暗号技術の動向を調査することです。Hackathonでは低遅延暗号 Areion に関するプロジェクトを立上げたので、今回の記事ではその話題に触れたいと思います。 イベント概要 The Internet Engineering Task Force (IETF)とはIETFは、インターネット技術の標準化を行う団体です。 これまで、HTTP、IP、TCP/UDP、TLS、QUICなどインターネットで使われる多くのプロトコルが標準化されてきました。オープンな組織であり、会合には誰もが参加可能です。活動の生産物として、RFC(Request for Comments)を発行されています。IETFの詳細については、こちらをご参照ください。 以下は、本記事で取り扱う2023年7月に開催されたIETF117の概要です。 イベント：IETF117開催日時：2023年7月22日（土）～28日（金）開催場所：カリフォルニア州サンフランシスコ ヒルトンユニオンスクエア　　　　　オンラインのハイブリッド主催：NOKIA（ノキア） 活動の背景 今回のHackathonでは、低遅延暗号 Areion に関する活動を行ったのですが新規にテーマ登録して参加を行なったので、この活動を実施する上でのノウハウも書かせていただきたいと思います。 この活動の背景としては、NICT Beyond5G研究開発促進事業 委託研究の「リアルタイム暗号技術とプライバシー保護への拡張」があり、この研究テーマでは低遅延暗号Areionをインターネット上で利用できるような環境を増やすことがミッションの一つとなっております。気になる方はこちらのURLを確認してくださいね。 ＜ノウハウ1＞ Hackathonでの「最初の一歩」 Hackathonに参加する際には、IETF Hackathon Wiki の中から興味のあるテーマを見つけるのですが、今回のわたし達のテーマは立ち上げが必要です。 テーマを立ち上げるためには「Champion」になる必要があります。「Champion」とは、テーマの主催者であり、Championとして登録することはテーマを主導していくことの宣言となります。 Championになる方法は簡単で、Hackathon Wikiに下記のような内容を記入するだけです。 ### Your Project Name - **Champion(s)** - Your Name (email at domain.com) - **Project Info** - Your project description here なお、Hackathon Wikiの記入はIETF Datatracker accountの取得が必要となるため、ご注意ください。 例えば、今回の低遅延暗号 Areion ですと、Wikiへの記載例は以下のとおりです。 ＜ノウハウ2＞ Hackathon当日の場所取り Hackathon当日のChampion のミッションとして、お花見でいうところの「場所取り」があります。会場には大きなテーブルがたくさんあるので、どの席がいいか？などを考えて場所を決めます。場所の取り方は原始的で、ホワイトボードの空きテーブルと実際の空きテーブルを確認しながら、確保できそうな場所にテーマ名を記入します。私たちのテーマだと、以下のような感じで確保することができました。 テーブルが確保できたら、テーブルに立て看板が用意されているので、そこにテーマ名を出して場所取り完了です。 今回、いい感じの場所を獲得することができたのですが、真夏のサンフランシスコだったにも関わらず、エアコンの吹き出し口の真下な席で寒すぎて体調を崩したので…次回からはその辺も気にして場所取りしたいですね！ 陣地も獲得できたら、あとは計画していたHackを進めていきます。 Hackathonの2日目に成果発表会があるため、目標を達成して良い報告ができるように活動に取り組んでおりました。成果発表の時間は、IETF Hackathon Wikiにテーマ登録を行い、専用のGitHubリポジトリに登録することで枠をもらえます。 今回のHackathonでの活動 今回は、Areionのリファレンス実装のOpenSSLへの組み込みを行い、TLS1.3でAreionを使えるように対応を行いました。 Areionを組み込んだOpenSSLの実装と発表資料は以下のとおりです。 実装はこちら。発表資料はこちら。 Hackしている時や発表後にコメントやアドバイスを多くいただけたので、今回は大成功だったと思っています。 今後の取り組み 今後は、2023年11月4日から開催されるIETF118に向けて活動を準備していきます。引き続きよろしくお願いします。 当社では、先端技術を用いたコア実装、調査研究、実証実験などの研究支援から、標準化支援、エンタープライズ向けサービス開発まで積極的に実施しておりますので、お気軽にお問合せください。 お問い合わせはこちら