AIアプリケーションとナレッジ
RAG開発
言語モデルは、目の前に何を置くかで決まります。期待外れの回答の多くは、モデルの失敗の顔をした検索の失敗です。正しい一節は存在したのに、取り出されなかったのです。私たちは検索層を構築して調整し、そのうえで測定します。モデルが正しい根拠から論じられるようにするためです。
事業上の課題
デモがうまくいったのは文書が少なかったから
素朴なベクトル検索は数百件の文書ではうまく動き、数十万件を超えると大きく劣化します。分割は表を見出しから切り離します。意味的に似た一節が、本当に根拠となる一節を押しのけます。新しさは関連度に負け、廃止された規程が現行のものより上位に来ます。測定しなければどれも見えないため、チームはリリースし、もっともらしい回答を得て、誰かが誤った回答に基づいて動いたときに初めて誤答率を知ります。
私たちの取り組み
検索を作り、そして証明する
まず実際の質問と、正解と分かっている出典から評価データを作ります。採点できないものは調整できないからです。そのうえで処理の流れに取り組みます。文書構造を尊重する分割、キーワードとベクトルを組み合わせたハイブリッド検索、新しさと権威性のためのメタデータフィルタ、そして候補の並べ替え。一節どうしの類似より実体間の関係が重要な場合は、ベクトルで足りるふりをせずグラフを使います。すべての変更を同じデータで採点するため、改善は主張ではなく実証になります。
RAG開発
提供できること
-
企業向けRAG
-
高度なRAG
-
GraphRAG
-
ハイブリッド検索
-
ベクトル検索
-
検索の最適化
-
RAGの評価
代表的なユースケース
代表的なユースケース
- 顧客向けアシスタントの根拠を固め、すべての記載を公開文書までたどれるようにする。
- 文言の類似ではなく、どの契約が適用されるかで答えが決まる契約横断の検索。
- 正しい一節が表や図の説明である技術文書の検索。
- もっともらしく答えるが、信頼を失う程度には誤る既存アシスタントを作り直す。
進め方
進め方
-
要件化
要望を仕様に変える。誰が使い、何が正しい答えで、誰が決めるのか。
-
根拠づけ
答えを持つコンテンツとシステムに接続し、既存の権限を尊重する。
-
評価
自社の事例から作ったラベル付きデータで、外部の目に触れる前に採点する。
-
提供と運用
監視、コスト管理、品質を守る回帰テスト群を伴う段階的なリリース。
テクノロジー
テクノロジー
- OpenAI
- Anthropic
- Azure OpenAI
- pgvector
- Elasticsearch
- Microsoft 365
- SharePoint
- Confluence
- Salesforce
セキュリティとガバナンス
セキュリティとガバナンス
回答は自社のコンテンツに根拠を置き、出典を伴うため、読み手が確認できます。検索は情報源に設定済みの権限を尊重するため、利用者がアプリ経由で直接見られないものを見ることはありません。プロンプト、取得した文脈、応答は監査のために記録され、評価はリリース時の一度きりではなく継続的に実行されます。
協業モデル
協業モデル
AIプロジェクト
定義されたAIソリューションの設計と提供について、私たちが責任を負います。
専任AIチーム
お客様の技術スタックと提供モデルに合わせて構築される、長期の専任エンジニアリング体制。
マネージドAI
本番のAIシステムを、私たちが運用・監視し、継続的に改善します。
TeamExtension.aiを選ぶ理由
調整の前に測ります
検索の作業の多くは直感で行われます。分割サイズを変え、回答をいくつか読み、良くなった気がすると判断する。私たちは先にラベル付きデータを作ります。地味ですが、調整と当て推量を分けるのはそこです。回帰テストとしても残るため、半年後のモデル更新が静かに品質を落とすこともありません。
主なお客様
よくあるご質問