プラットフォーム要件定義

Transcript

1. プラットフォーム要件定義
2. 要件定義 基本から考える 何を解決するための手段としてプラットフォームを定義するのか (私の個人的な視点からの考えです) 業務を効率化 組織を強化 会社の目的を 達成する
3. 概念では何が近いか（ 引用） データの集積・活用と LLMの連携を含む概念  Data Intelligence データの文脈を AIが理解し、高度なインサイトを生成 する概念  データプラットフォーム LLMとデータを繋ぎ込み、組織全体の基盤となるシス テム構成 Key Components / 主要要素  Data Assets データウェアハウス、データレイク、業 務システム、SaaS、ログなど、企業が 保有するあらゆる構造化・非構造化 データ  Metadata & Catalog データの意味・定義・型・生成元・変換 履歴・利用履歴などを表すメタデータ と、それらを横断的に検索・探索でき るデータカタログ  Governance & Quality 誰がどのデータにアクセスできるの か、どのようなルールで利用・共有・保 管するのか、法規制との整合性確保 といった枠組み
4. Phase1 記録と可視化の基盤づくり palantirを例に考えます
5. データインテリジェンスについて
6. Observability（可観測性） AI Observability / Agent Observabilityなどの言葉で定義され始めている 一般的な言葉では、広義にはなるがLLMOpsというのがある。
7. LLMOps データの資産化と性能改善 - 利用状況に合わせて、可用性を 向上させるためのシステム構成 の見直し - ニーズの高いタスクに対する業 務特化のボットを開発する。 Q. ユーザーは、どのよ うなチャット（ビジネスタ スク）をすることが多い か？ Q. チャットの生成速度 は、十分条件に達して いるか？ 問い合わせ
8. オントロジーとは
9. AI Observability の例(引用) • Context Relevance: 検索サービスやリトリーバから取得したコンテキストが、ユーザーのクエリに適切かどうかを評価します。 • Groundedness: 生成された回答が、取得したコンテキストに裏付けられているか（事実に基づいているか）を測定します。 • Answer Relevance: 生成された回答が、ユーザーの質問にどれだけ関連しているかを評価します（正解ラベルがなくても評価可能）。 • Correctness: 生成された回答が、与えられた正解（ ground truth）にどれだけ整合しているかを測定します。 • Coherence: 回答全体が論理的に一貫し、矛盾や飛躍がないかを評価します。
10. データ基盤とAIを繋げる 引用
11. Phase 02 RAGで扱う候補（コンテキストレイヤー）  扱うデータの候補 • slack、メール、会議などの会話データ（非構造化データと呼ばれる） • LLMの使用状況 • 承認履歴  この辺はどの業務を効率化するか、品質を上げるかというスコープを定義しないと決めることがで きないと判断しました。
12. Phase 02 AIによる業務品質の継続的向上  品質劣化・手戻りの削減 文脈不足や属人化に起因する課題を解消し、業務 プロセス全体の安定化を図ります。  AIによる継続的な実行 • 会議整理・論点抽出 • レビュー準備の自動化 • ドラフト作成の支援
13. 自律学習サイクル - human reflection（実装：langsmith automation rule） - self-reflection
14. エージェント基盤のプラットフォーム 承認フローやRAG、自律学習サイクルを回すことができるもの - Dify - Langchain系列　
15. 具体的な業務 これに関しても、データ同様に、何を効率化するか決めていないため、ここで話しません
16. プラットフォームエンジニアリングと社内ツール AppSmith： 社内ウェブツール作成のローコードツール AIエージェントのUIに使える可能性がある DEVELOPMENT ENVIRONMENTSについて プラットフォームエンジニアリングの観点で 説明できそうです。今回は省きます
17. 現状の承認フロー IDPツールとしてBackstageを 導入しています AppSmithをエージェント基盤の インターフェースとして活用 社内ポータルに統合可能です
18. 参照資料 パランティア アーキテクチャ図