コード×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モデルを選択し、プロンプトテンプレートを適用し、知識ベースから関連するコンテキストを検索するためのパイプラインのような構造を持っています。
The SPACE of Developer Productivity
This framework, called SPACE, captures the most important dimensions of developer productivity: satisfaction and well-being; performance; activity; communication and collaboration; and efficiency and flow. By recognizing and measuring productivity with more than just a single dimension, teams and organizations can better understand how people and teams work, and they can make better decisions.
Imagination in Actionは、2023年4月13日にマサチューセッツ工科大学のSamberg会議センターで開催されるAI技術イベントです。
AIアプリケーションに関する基調講演やパネルディスカッションを通じて、
スタートアップ、創業者、起業家が成功するAI会社を構築するためのインスピレーションが共有されました。
OpenAIのCEOのSam Altman氏のBreakthrough potential of AIに関するセッションについては大変参考になりました。
簡単にまとめますと、
・急いでLightweightなアプリケーションを作るべきではない。利用者のニーズをよく考えて、会社の長期戦略を考えることが重要です。
・fine tuningレイヤー追加しなくても基本モデルでも十分機能する。トレーニングデータを増やすより機能を考えることが重要です。
・まず行動することは大事。やっているうちに戦略が見えてくる。
以下は自分の日本語訳になります。
数年前に似た障害があったが、
ANAシステム障害 顧客DB同期処理失敗?
ANAシステム障害 顧客DB同期処理失敗? その2
今回は別の原因がらしい。
4月3日に発生した国内線システム不具合の原因及び再発防止策について
4月3日に発生したシステム不具合により、多数の国内線に欠航・遅延を生じさせる結果となりました。ご利用のお客様、関係の皆様に多大なご迷惑をお掛けいたしましたこと、深くお詫び申し上げます。この度の不具合につきまして調査を行った結果、原因が明らかになりましたので、再発防止策とあわせてご報告申し上げます。
発生原因
国内線旅客システムのデータベースにおける、ソフトウェア不具合であることが判明しました。具体的には、予約管理業務のために、特定のデータを抽出する日常の処理において、ソフトウェアのバグを起因とするエラーが発生し、データベースサーバー2台が一時的に高負荷状態となりました。その結果、データ処理が滞り、サーバー2台が同時停止しました。再発防止に向けた対応
（1）データ抽出方法の変更（2）データベースサーバーが2台同時に停止しないための制御プログラムの強化
上記を確実に実施した上で、万が一、今後システム障害が発生した場合に備え、バックアップシステムへの迅速な切りかえ、訓練の実施などの対策を講じるべく、引き続き対応を図ってまいります。
SNS上はこの半年間ChagGPTが一番の話題に間違いない。
これは自然言語処理の革命である。
今後の10年は、GPTによる技術革新とイノベーションを大いに期待したい。
金曜日に会社に行って同僚とAIとGPTについて雑談した。
私の見解は、100年前に比べて一般的な人々は週末がなく、毎日十数時間働いていたとして、
大量生産の工業化とIT化により週5日、1日8時間の労働が標準となった。
なので、AI化が進んだ結果、週末に3日間休みを持ち、1日6時間の労働が新しい常態になるでしょうと思う。
前職の社長からPM TPM EMそれぞれの役割を聞かれたので、
下記ツイートを紹介しました。
Correction. pic.twitter.com/YZvhWNKscm
— Gergely Orosz (@GergelyOrosz) February 14, 2022
なお、Medium-sizedを例に少し日本語の文字に落としてみました。