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
サービスメッシュ必読ガイド - マイクロサービス時代のサービス間通信管理
サービスメッシュは、(一般的にはマイクロサービスベースの)分散ソフトウェアシステム内における、すべてのサービス間"east-west"トラフィックを管理するテクノロジです。ルーティングのようなビジネス指向の機能運用に加えて、セキュリティポリシの適用やQOS(Quality of Service)、レート制限のような非機能サポートも提供します。一般的には(すべてではありませんが)サイドカープロキシを使用して実装され、すべてのサービスがそれを通じて通信するようになります。
サービスメッシュはデータプレーンとコントロールプレーンという、2つの高レベルなコンポーネントで構成されます。
データプレーンは"仕事をする(does the work)"もので、"[ネットワークエンドポイントを]出入りするすべてのネットワークパケットの条件付き変換、転送、監視"を役割としています。最近のシステムでは、データプレーンは(Envoy、HAProxy、MOSNなどのように)プロキシとして実装されるのが一般的で、サイドカーとして各サービスとともにプロセス外部で動作します。
コントロールプレーンは"仕事を監督する(supervises the work)"主体として、データプレーンの個々のインスタンスすべて -- 独立したステートレスなサイドカープロキシ群 -- を分散システムとして構成する役割を担います。
ユースケース
動的サービスディスカバリとルーティング
サービス間通信の信頼性
トラフィックの可観測性
通信のセキュリティ
One Team At Uber Is Moving From Microservices To Macroservices
Microservicesの粒度問題はしばらく続きそうです。
These services don't just do one thing: they serve one business function. They are built and maintained by a team (5-10 engineers). They are more resilient and get far more investment development and maintenance-wise than some of those early microservceis
いずれ将来的に全てのアプリケーションはCloudnativeになりますが、ホスティング環境もマルチテナントで、どこのPublic CloudかPrivate Cloudか、選択肢の話です。
要は安全な低価な場所に置けばいい訳です。
WalmartのEdge話、正に今過渡期の一つの事例として大いに参考になると思います。
SLAとして、ローカルに安価なハードウェアに、Cloudnativeアプリケーションを配置しないといけませんし、アプリケーションのdepolymentが簡単だが、データのマルチテナントが難しいです。
一万以上の店舗に、一万以上のk8sクラスタを自動的に構築し、かつデータ同期も完全に行う事が、決して容易な事ではないです。
Keynote: Seamless Customer Experience at Walmart Stores Powered by Kubernetes@Edge - Maneesh Vittolia, Principal Architect & Sriram Komma, Principal Product Owner, Walmart
At Walmart, while major application software can and does operate in the cloud, stores or any client edge compute cannot avoid the intermittent network events that can create less than ideal availability and performance of the software during those times. This can lead to poor customer experience and/or failed transactions during checkout. Because of Walmart's scale of serving around 265 million customer every week, the comnbined effect on customer experience as well as the loss of revenue is pretty huge. To overcome the issue between Stores and cloud, Walmart is building and rolling out the next generation of Point of Sale (POS) systems on highly resource constraint edge computing environment using modern service mesh based technologies designed to allow maximum business flexibility, extreme performance and rapid deployment and powered by Kubernetes.
KubeCon + CloudNativeCon North America 2019 Keynote
Presentation PDF
Kubernetes Meetup Tokyo #26 / Recap: Kubecon Keynote by Walmart
現地でも盛り上がっていたWalmartのKeynoteをRecap
GraphQL: A success story for PayPal Checkout
PayPal Checkoutサービスは、四年間をかけて、純正REST APIから、 Batch APIへ移行して、さらに去年からPayPal Checkoutに全面移行したお話です。
元々の課題の定義は、支払い行為に伴い複数処理が常に発生し、処理時間がかかった事。
However, REST's principles don't consider the needs of Web and Mobile apps and their users. This is especially true in an optimized transaction like Checkout. Users want to complete their checkout as fast as possible. If your applications are consuming atomic REST APIs, you're often making many round trips from the client to the server to fetch data.
特にスマートデバイスで世界は自分の周りも複数既存APIをmashupしたり、proxyやgatewayの形で対応しているね。