雪泥鴻爪--IT技術者の随筆

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を例に少し日本語の文字に落としてみました。

先週末からAUのシステム障害で輻輳が流行語になっていたようで、「輻輳」とは何か調べてみました。

まずは、「輻」。Wikipediaによれば、

スポーク（spoke）とは、輻（や）とも呼ばれる、車輪を構成する部材のひとつである。 中心から放射状に伸びる棒状部品がスポーク。 外周部分を支えているリムと、車輪の中心にあるハブをつなぐ。基本的にはハブから放射状に伸びている。

「輳」は、mojinaviによれば、

輳とは、あつまる／車の輻が轂に集まるなどの意味をもつ漢字。

「輻輳」のWikipediaの解説は下記となります。

輻輳（ふくそう）とは、物が1か所に集中し混雑する様態をいう。

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