K2Aフレーム™は著者がこの数年会社のAI推進仕事の中で経験してきた課題を個人で考えた問題解決方法論です。 このフレームワークに関する用語やプロセス定義などに対して著作権を所有するため、利用したい場合は、本ブログのコメント機能を使ってご連絡ください。

1. K2Aフレーム™の目的

業務知識をAIに変換し、人とAIが協働できる組織文化を作る体系的な方法論。

• 「AI Agentを作る事」ではなく、「業務知識をAI化し、成果を出すこと」が目的
• 投資の中心はシステムではなく、人材と知識整備
• 社員の役割は今までの業務「操作者」ではなく、AIにリプレスされる予定のヒューマンリソースではなく、「AI Pilot（伴走者）」へ進化

1.1 よくある経営陣の誤解パタン

• 「AIは魔法ーAI Agentがあれば大量コスト削減・外注削減可能」型の誤解
  AIは万能ではなく、「限定領域での支援」が適切
  期待値と成果の乖離で「PoC疲れ」に落ち、投資継続が止まり、社内外の信頼を失うリスクが高い
  
• 「AIで人材シフトー流行りのAIツールで既存正社員を新規事業へシフト可能」型の誤解
  「AI運用・評価・改善」など新たな役割が発生
  現実は「人員削減」より「リプレイス＋高度化」の組み合わせが有効
  

1.2 よくある現場の誤解パタン

• 「データプラットフォームがないからAI活用が無理」
  K2Aシナリオカード・手順カードがすでに"データの最小単位"。
  つまり「まず業務をカード化すること自体がデータ化の入口」になる。
  SharePoint/Notion/Confluence/Google Driveにカードを整理して「人とAIの共用リポジトリ」にする。
  これが「疑似データプラットフォーム」になる。
• 「APIがないからAI Agentが動く環境がない」
  Excel・チャット・ワークフローシステムのログ、承認メール――すべてが"半構造化データ"。
  APIがなくてもCSVエクスポート、RPAでスクレイピング、フォーム入力のログなど、既存の出口を探す
  K2Aを回すうちに「ここは毎回手入力がダルい」→「じゃあ簡単なAPIつけよう」と後追いで必要性が出る。
  

2. ブランド定義

• 名称：K2Aフレーム™(Knowledge-to-AI Framework)
• タグライン：業務知識をAIへ、人を未来へ / Turning Knowledge into AI, Empowering People

3. K2A循環プロセス™

Capture(業務知識を捕捉) -> Structure(知識を整備) -> PromptOps(プロンプト設計・運用) -> Evals(評価・検証) -> Adopt(業務導入) -> Refine(改善・再登録) -> 再びCaptureへ

4Aモデル（AI Agent Application Architecture）は、小生が提唱するLLMベースのAIエージェントアプリケーションを迅速かつ拡張性高く構築するためのリファレンスアーキテクチャです。以下の6つのレイヤーで構成され、エンタープライズ用途に対応可能なセキュリティ・柔軟性・観測性を備えています：

User Interface Layer
Gateway Layer
Orchestrator / Reasoning Layer
MCP Server / Tool Layer
Data / API Layer
Context / Memory Layer

SSO, SCIM, and User Management SSO Overview
SSO は、エンタープライズおよび教育機関向けの顧客のみが利用可能です。

背景のアーキテクチャと用語
現在、ChatGPT および API プラットフォームの両方で、SAML 認証を通じた SSO がサポートされています。
•ワークスペース：ChatGPT のインスタンスを指します。
•組織（Organization）：API プラットフォームのインスタンスを指します。
•アイデンティティプロバイダー（IdP）：デジタル ID を管理するために使用するサービスを指します。当社は、SAML をサポートするすべての IdP との接続をサポートしています。代表的な IdP には以下が含まれます：Okta,Azure Active Directory/Entra ID, Google Workspace

現在、各 ChatGPT ワークスペースには、それに対応するプラットフォーム組織が関連付けられています。
つまり、エンタープライズ プラットフォームの「一般」ページにある 組織 ID（org-id） は、エンタープライズ ChatGPT ワークスペースに関連付けられている 組織 ID（org-id） と同じです。
そのため、ワークスペースと組織は同じ認証レイヤーを共有しています。

What is ChatGPT Enterprise?

公式ドキュメントの更新時間は2024年6月のままですので、あまり機能更新していないかもしれません。

ChatGPT Enterpriseとは？

ChatGPT Enterpriseは、企業向けのセキュリティとプライバシーを備えたサブスクリプションプランです。無制限の高速GPT-4oアクセス、長い入力を処理できる拡張コンテキストウィンドウ、高度なデータ分析機能、カスタマイズオプションなど、さまざまな機能を提供します。

自社でChatGPT Enterpriseを利用するには？

ChatGPT Enterpriseを導入したい場合は、営業チームにお問い合わせください。「どの製品やサービスに興味がありますか？」の項目で「ChatGPT Enterprise」を選択してください。

ChatGPT Enterpriseのセキュリティとプライバシー管理について

ChatGPT Enterpriseでは、ビジネスデータをユーザー自身が所有・管理できます。お客様のビジネスデータや会話を学習に使用することはなく、モデルも使用履歴から学習しません。また、ChatGPT EnterpriseはSOC2準拠であり、すべての会話は送信時および保存時に暗号化されます。

さらに、新しい管理コンソールでは、チームメンバーの管理、ドメイン認証、SSO（シングルサインオン）、利用状況のインサイト機能を提供し、エンタープライズ環境での大規模導入を可能にします。

詳しくは、プライバシーページやTrust Portalをご覧ください。追加のご質問がある場合は、営業チームまでお問い合わせください。

ChatGPT Enterpriseのその他の特徴

ChatGPT Enterpriseでは、以下の点が一般ユーザー向けプランと異なります：

• 無制限のGPT-4 Turboアクセス（使用制限なし）

• 高速なパフォーマンス

• 高度なデータ分析機能の無制限利用（旧Code Interpreter）

• 共有可能なチャットテンプレート（企業内のワークフロー構築や共同作業に活用可能）

ChatGPT Enterpriseのサポートを受けるには？

問題が発生した場合は、ヘルプセンターのチャットツールを使ってサポートチームにお問い合わせください。迅速に対応いたします！

コード×AIーソフトウェア開発者のための生成AI実践入門を読んだ感想や今まの業務の中の自分の学びのまとめです。

全体感想

Corrective Retrieval Augmented Generation

Abstract
大規模言語モデル（LLM）は、生成されるテキストの正確性を完全に確保することができないため、必然的に幻覚を示します。（情報を取り込んでいるパラメータの知識だけでは。）
検索補強型生成（RAG）はLLMを補完する実用的な手段ですが、取得されたドキュメントの関連性に大きく依存しており、検索が誤った場合にモデルがどのように振る舞うかという懸念があります。

このため、私たちは生成の堅牢性を向上させるために、訂正検索補強生成（CRAG）を提案します。
具体的には、軽量な検索評価器（ retrieval evaluator）を設計して、クエリに対する取得されたドキュメントの全体的な品質を評価し、それに基づいて異なる知識取得アクションをトリガーできるようにします。
静的で限られたコーパスからの取得は、最適でないドキュメントのみを返すことができるため、大規模なウェブ検索が検索結果を拡張するために利用されます。

さらに、取得されたドキュメントに対して、選択的に重要な情報に焦点を当て、それ以外の情報をフィルタリングするための分解して再構成するアルゴリズムが設計されています。
CRAGはプラグアンドプレイであり、さまざまなRAGベースのアプローチとシームレスに組み合わせることができます。
短文と長文の生成タスクをカバーする4つのデータセットでの実験結果は、CRAGがRAGベースのアプローチの性能を大幅に向上させることが示されています。

RAGは本当に熱い。会社で検証環境を提供したら使いたい要望が殺到している。ある部門の試算では年間10数億円の利益貢献。これでちゃんとPJ化しないね。
ただ体系的に検索品質を評価するためにどうすれば良いのか課題なのでこちらを参考になった。
Best Practices for LLM Evaluation of RAG Applications

長い文章のため、ChatGPTで下記Promptで訳してもらった：
「あなたはプロの日英翻訳専門家。質問者に質問して、質問者からの英語を日本語に訳してください。翻訳のプロセスは２段階でお願いします。まず直訳して、それから直訳の結果に対して、ネイティブ日本語者から見ても自然な日本語に再度訳直してください。」

---
チャットボットは、大規模な言語モデル（LLM）の強力なチャットと推論能力を活用するための最も普及したユースケースです。
Retrieval augmented generation (RAG) アーキテクチャは、ナレッジベース（ベクトルストアを介した）の利点と生成モデル（例：GPT-3.5およびGPT-4）を組み合わせることで、幻覚を減らし、最新の情報を維持し、特定のドメインの知識を活用するための業界標準となりつつあります。
しかし、チャットボットの応答の品質を評価することは今日も未解決の問題です。
業界標準が定義されていないため、組織は人間による評価（ラベリング）に頼る必要がありますが、これは時間がかかり、スケーリングが難しいです。

私たちは、実践に理論を適用して、LLMの自動評価のベストプラクティスを形成し、RAGアプリケーションを迅速かつ自信を持ってプロダクションに展開できるよう支援しました。
このブログは、Databricksで実施している一連の調査の最初を表しており、LLMの評価に関する学びを提供することを目指しています。
この投稿でのすべての研究は、Databricksのシニアソフトウェアエンジニアであり、Databricks Documentation AI Assistantの作成者であるQuinn Lengによって実施されました。

Building LLMs-Powered Apps with OPL Stack

OPL stands for OpenAI, Pinecone, and Langchain

OpenAI:
- 強力なLLM（例：chatGPTとgpt-4）へのAPIアクセスを提供します。
- テキストを埋め込みに変換するための埋め込みモデルを提供します。

Pinecone:
- 埋め込みベクトルの保存、意味的類似性の比較、高速な検索を提供します。

Langchain:
- 6つのモジュール（モデル、プロンプト、インデックス、メモリ、チェーン、エージェント）から構成されています。
- モデルは埋め込みモデル、チャットモデル、LLMなどの柔軟性を提供します。これにはOpenAIの提供するものに限らず、Hugging FaceのBLOOMやFLAN-T5などの他のモデルも使用できます。
- メモリ：チャットボットが過去の会話を記憶するためのさまざまな方法があります。私の経験から言うと、エンティティメモリはうまく動作し効率的です。
- チェーン：Langchainに初めて触れる場合、チェーンは素晴らしい出発点です。ユーザーの入力を処理し、LLMモデルを選択し、プロンプトテンプレートを適用し、知識ベースから関連するコンテキストを検索するためのパイプラインのような構造を持っています。

DPEが最近流行っているようで、関連資料をメモしてみました。

DPE(Developer Productivity Engineering)が新しいソフトウェア開発工学の方法論で、ビルド・テストとCIなどの自動化ツールにフォーカスしています。その実践をDPEチームにより担当されます。
DPEとSREの違いは、SDLCフェーズの違いであって、DEV(development & test)開発生産性とOPS(deployment & maintenance)運用信頼性の違いだと思われます。
なお、DXE(Developer Experience Engineer)はDPEを実現するためのエンジニアロールの一つと自分が解釈しています。
ちなみに、GoogleのEngineering Productivity部門にDPEやDXEとのロールがなく、通常のSoftware Engineer (SWE)とTest Engineer (TE)だけあります。

4年前に開発生産性を考えるサービス化(API化)の本質はソフトウェア開発産業化記事は、DPEのようにツールチェーンのことを意識していたが、明確的に言葉定義として出てこなかったのが残念。

DPE - Developer Productivity Engineering

1 From QA to Engineering Productivity

Google Testing Blog Tuesday, March 22, 2016

In summary, the work done by the SETs naturally progressed from supporting only product testing efforts to include supporting product development efforts as well. Their role now encompassed a much broader Engineering Productivity agenda.

2 The Effect of Work Environments on Productivity and Satisfaction of Software Engineers
Brittany Johnson, Thomas Zimmermann, Senior Member, IEEE, and Christian Bird, Member, IEEE
2019/09

3 Developer Productivity Engineering: Introduction and Key Concepts

gradle.com By Dennis Welter
September 9, 2019

Hans Dockter, CEO & Founder of Gradle, talks about the emerging practice of developer productivity engineering, a discipline of using data to improve essential development processes from build/test to CI/CD.

Topics covered in this webinar are:

Quantify the costs of a low productivity environment with wasted time waiting for builds, tests, and CI/CD pipelines
Communicate the importance of fast feedback cycles and catching errors earlier, including incorrect signals like flaky tests
Discuss acceleration technologies for speeding up feedback cycles
Make the practice of developer productivity engineering a respected discipline
Use data to understand and improve essential development processes

ビルド、テスト、CI/CDパイプラインの待ち時間にかかる無駄な時間など、生産性の低い環境におけるコストを定量化する
フィードバックサイクルを高速化し、不具合テストのような不正確なシグナルを含むエラーを早期に発見することの重要性を伝える。
フィードバックサイクルを高速化するためのアクセラレーション技術について説明します。
開発者生産性エンジニアリングの実践を尊重される規律とする
本質的な開発プロセスを理解し、改善するためにデータを使用する

Scaling Kubernetes to Over 4k Nodes and 200k Pods

PayPalはApache MesosからKubernetesへ移行しようとしていて、ただパフォーマンスチューニングでは大変苦労したことを記事にしてくれました。
Apache Mesosでは簡単に1万Nodeまでスケールアウトしましたが、Kubernetesでなかなか負荷テストが通らなかったそうです。色々やった結果は4000止まり。
ちなみに負荷テストツールはk-benchを利用していました。

テスト環境：
ーGCP
ーWorker Nodeスペック：4CPU、最大40Pod
ー規模：3つMaster Node、3つNodeのetcdクラスター、4100 Worker Node、20万Pod