宇山 幸男 の記事一覧

はじめに 現在、弊社のコールセンターでは、従来型音声AI(音声→テキスト→回答生成→音声変換)を導入しています。このようなAIは、お客様の音声をテキストに変換し、AIが処理した後、再び音声に変換するという流れでした。 それに対し、昨年話題となったSpeech-to-Speech型のリアルタイムAI API(以下、S2S API)は、音声から直接音声で回答を生成できるようになり、より自然な会話が可能になりました。そこで、弊社でもS2S APIの導入を検討することになりました。 既存電話システムの仕組み まず一般的なVoIPシステム(IP電話)の仕組みですが、以下の2つのプロトコルで構成されています。 SIP(Session Initiation Protocol) 役割: 通話の開始、終了、転送などの制御特徴: 音声データ自体は送らない RTP(Real-time Transport Protocol) 役割: 実際の音声データの転送特徴: SIPとは別経路で送信される [電話システム] --SIP(制御)--> [相手先] --RTP(音声)--> このように、制御と音声が分離された2チャネル構成が電話システムの特徴です。 S2S APIを利用する上での3つの接続方式 S2S APIは、主に3つの接続方式に対応しています。 ※対応状況はサービスによって異なります。導入するS2S APIの仕様を確認してください。 1. WebSocket 双方向通信チャネルを提供するプロトコルです。 通信モデル: [クライアント] <--WebSocket(制御+音声)--> [S2S API] HTTPでハンドシェイク後、TCP接続を維持制御信号と音声データを単一チャネルで送受信実装がシンプルサーバー間（サーバー to サーバー）での処理に向いている ⚠️ 注意: WebSocketはTCPベースのため、ネットワーク上でパケットロスが発生した場合、再送処理により遅延が増大するリスクがあります。 2. SIP 電話システムと同じシグナリングプロトコルです。 通信モデル: [電話システム] <--SIP+RTP--> [S2S API] 既存のVoIPシステムと同じプロトコルSIP(制御) + RTP(音声)の2チャネル構成電話システムとの親和性が高い 3. WebRTC リアルタイム通信のためのフレームワークです。ブラウザ間のP2P通信向けに設計されましたが、S2S APIとの接続ではクライアントとAPIサーバー間の通信に利用します。 通信モデル: [ブラウザ] <--WebRTC P2P--> [S2S API] SRTP(Secure RTP)でメディア転送超低遅延(50-150ms)ブラウザから直接接続可能 3つの接続方式の比較 項目WebSocketSIPWebRTC遅延100-300ms（パケットロス時はさらに増大）100-300ms50-150ms実装難易度低中高電話システム連携変換必要直接可能変換必要ブラウザ対応○×○主な利用用途サーバー間処理電話システム直結Webブラウザ通話メリット実装が簡単デバッグしやすい既存インフラ活用変換不要低遅延デメリットTCP特性上、パケットロス時に遅延増大リスクカスタマイズ性低API実装に依存実装複雑ネットワーク環境によっては追加のインフラ構成が必要になるケースあり ※S2S APIサービスによって対応している接続方式は異なります。 コールセンターでの接続方式の選び方 コールセンターとS2S APIを繋ぐ場合、要件に応じて適切な接続方式が変わります。 既存の電話システムと直接接続する場合: SIP接続 既存インフラをそのまま活用できる 電話システムと同じプロトコル追加の変換処理が不要 統合が容易 電話番号からの着信に対応既存の通話フローに組み込みやすい 安定性 電話業界で長年使われている実績 接続イメージ: [お客様の電話] → [電話システム] --SIP/RTP--> [S2S API] 柔軟性やセキュリティを重視する場合: SBC経由WebSocket/WebRTC接続 音声処理のカスタマイズやセキュリティ管理を細かく行いたい場合は、SBC(後述)を経由してWebSocketやWebRTCで接続する方式が適しています。 接続イメージ: [お客様の電話] → [電話システム] --SIP/RTP--> [SBC] --WebSocket/WebRTC--> [S2S API] Webブラウザから利用する場合: WebRTC接続 電話システムを介さず、ブラウザから直接S2S APIと通話する場合は、WebRTC接続が低遅延で最適です。AIアバターなどで回答させたい場合はこちらの方式が適しています。 接続イメージ: [Webブラウザ] --WebRTC P2P--> [S2S API] 参考情報: SBCとは 実際の運用では、電話システムとS2S APIの間にSBC(Session Border Controller)を配置するのが一般的です。 SBCの役割 SBCは、異なる通信モデル間の「橋渡し」をする機器です。 主な機能: プロトコル変換: SIP ⇔ WebSocket/WebRTCセキュリティ制御: アクセス制限、暗号化音声処理: コーデック変換、ノイズ除去、録音柔軟性: 複数のS2S APIサービスへの対応 SBC経由の構成: [電話システム] --SIP/RTP--> [SBC] --WebSocket/WebRTC--> [S2S API] SBCを挟むことで、セキュリティ強化や柔軟な音声処理が可能になります。 まとめ コールセンターでS2S APIを繋ぐ接続方式は主に3つあります: WebSocket: 実装がシンプル、サーバー間処理向き（ただしTCPの特性上、パケットロス時は遅延増大に注意）SIP: 電話システムと親和性が高い、直接接続可能WebRTC: 低遅延、ブラウザ向き コールセンターでは、要件に応じて接続方式を選択します: 既存インフラ活用 → SIP接続柔軟性・セキュリティ重視 → SBC経由WebSocket/WebRTC接続Webブラウザ利用 → WebRTC接続 この記事で紹介した技術は、現在弊社内で導入に向けた検討・検証を進めています。今後お問い合わせの際に「なんだかスムーズだな」と感じることがあれば、このブログの技術が生かされているかもしれません。そんなことをふと思い出していただけたら嬉しいです。

皆さんはじめまして。アーキテクトチームに所属している宇山です。私は現在、あるプロジェクトで大量の会話データを活用したローカルな大規模言語モデル（LLM）を開発するべく日々検討を重ねています。今回はその性能を向上させる2つの重要な技術である、RAG（Retrieval-Augmented Generation）とファインチューニングに焦点を当てて解説していきます。これらの手法は、AIの性能を向上させる上で非常に重要ですが、未経験の方にはちょっと難しく感じるかもしれません。そこで、できるだけわかりやすく説明していきますので、ぜひ最後までお付き合いください。 ローカルLLMとは まず、「ローカルLLM」について簡単に説明します。ローカルLLMとは、ChatGPT、Gemini、Claudeのような外部のSaaSサービスを介さず、ユーザーや組織が管理する環境で直接動作する大規模言語モデルのことです。とはいえ、パソコン上で動作するような小さなモデルでは多くのデータを扱えないため、弊社が提供しているConoHa GPUサーバのようなVPSを利用します。これにより、データのプライバシーも確保しやすくなります。 なぜRAGやファインチューニングが必要なのか 事前学習済みのLLMは非常に強力ですが、以下のような限界があります： 1. 知識の更新: LLMの知識は学習時点で固定されます。新しい情報に対応できません。2. 専門性の不足: 一般的な知識は広くカバーしていますが、特定の分野や業界に特化した深い知識は不十分な場合があります。3. タスク特化の難しさ: 汎用モデルは多様なタスクをこなせますが、特定のタスクで人間レベルの精度を出すのは難しいことがあります。4. プライバシーとセキュリティ: 一般的なLLMは公開データで学習されているため、機密情報を扱う際にはリスクがあります。5. カスタマイズの制限: ユーザーや組織固有のニーズに合わせてモデルの動作を調整することが困難です。 これらの課題に対処するために、RAGとファインチューニングが重要になってきます。これらの技術を使用することで、LLMの能力を大幅に向上させ、より実用的で効果的なAIソリューションを作ることができるのです。 RAG（Retrieval-Augmented Generation）とは RAGは、「検索拡張生成」と訳されることもある技術で、厳密には学習手法ではなく、LLMの推論プロセスを拡張する方法です。 RAGの特徴： 既存のLLMを使用し、外部の知識ベースから関連情報を取得して回答を生成します。 モデル自体を変更せず、質問に応じて適切な情報を検索し、それを基に回答を生成します。 RAGの利点： モデルの再学習が不要なので、新しい情報を素早く取り入れられます。 特定の分野や最新の情報に対応しやすくなります。 RAGの欠点： 外部知識ベースの質と量に依存するため、準備に時間がかかる場合があります。 検索精度によって回答の質が左右されます。 ファインチューニングとは ファインチューニングは、既存の事前学習済みモデルを特定のタスクや領域に適応させる学習手法です。 ファインチューニングの特徴： 事前学習済みのLLMを、特定のデータセットで追加学習させます。 モデルの重みを調整し、特定のタスクや領域に特化させます。 ファインチューニングの利点： 特定の分野や用途に高度に最適化できます。 一度学習すれば、その後の推論が高速になります。 ファインチューニングの欠点： 大量の学習データと計算リソースが必要です。 新しい情報を追加する際は再学習が必要になります。 RAGとファインチューニングの比較 わかりやすく表にまとめてみました。 特徴RAGファインチューニング学習の必要性不要必要新情報の追加容易再学習が必要リソース要求比較的少ない多い特定分野への適応柔軟高度に最適化可能推論速度やや遅い速い どちらを選ぶべきか RAGが適している場合： 頻繁に更新される情報を扱う必要がある 特定のドメイン知識を柔軟に組み込みたい 学習のためのリソースが限られている ファインチューニングが適している場合： 特定の領域で非常に高い精度が求められる 推論速度が重要である 十分な学習データとリソースがある まとめ RAGとファインチューニングは、どちらもローカルLLMの性能を向上させる強力な手法です。これらの技術は、LLMの限界を克服し、より適応性が高く、精度の高いAIソリューションを実現するために不可欠です。RAGは柔軟性と即時性に優れ、ファインチューニングは特定タスクへの最適化に強みがあります。プロジェクトの要件や利用可能なリソースを考慮して、適切な手法を選択することが重要です。 ちなみに我々のプロジェクトでは両方を採用し、最適な手法を検討しています。 AI技術は日々進化しています。ぜひ、自身のプロジェクトに最適な方法を見つけてみてください。