almost weekly useful materials - 07/17 -

[GENZITSU]

プロンプトエンジニアリング「Rephrase and Respond」の紹介

ユーザーからの質問を一度LLMに言い換えさせてから、回答させることで応答精度を改善させた論文の紹介

手法

1回のやり取りで質問の言い換えをおこなるOne-step RaRと言い換えと回答を別々に実施するTwo-step RaRがある

One-step RaR

"{question}" 
Rephrase and expand the question, and respond.

Two-step RaR

"{question}"
 Given the above question, rephrase and expand it to help you
do better answering. Maintain all information in the original question.

(original) {question} 
(rephrased) {rephrased_question} 
Use your answer for the rephrased question to answer the original question.

Two-stepでは元の質問も入れることで、LLMによる誤った書き換えリスクをヘッジしている

実験結果

評価に用いてたデータの性質

GPT4による結果では、特定の日付が偶数かを問うデータセットで大きく向上。(逆にチャットボット的なものに期待するcommon sense QAはベースラインの時点で精度が高い印象)

その他のモデルを見ると、質問言い換え能力が高いモデルじゃ無いと十分に性能を引きだせなさそうな印象を受ける

コメント

流し見した時はすごそうと思ったが、評価データの質が汎用性を考慮したものとは言えなさそうなので、日頃使えるかと言われると懐疑的。

one step RaRはレイテンシーの増加もそこまで大きく無いと思うので、まず試すものとして良さそう

出典

• プロンプトエンジニアリング「Rephrase and Respond」の紹介
• Rephrase and Respond: Let Large Language Models Ask Better Questions for Themselves

[GENZITSU]

プロジェクト推進におけるLLMチューニング

業務にLLMをフィットさせるための良い心構えが記載されている

コメント

良い(語彙力)

出典

• プロジェクト推進におけるLLMチューニング

[GENZITSU]

RAG vs ファインチューニング（コーディング性能で比較）

ドメイン固有言語をコーディングする際にRAGで打ち取るか、Fine tuningを通じて打ち取るかを性能比較した論文の紹介

Fine tuningと同等な性能をRAGでも実現できたが、単純なドキュメントだけでなく、コーディング例も引っ張ってくることで性能を上げたという趣旨

結果のまとめ

Few-ShotでLLMに渡すサンプル数は多いほうがいい

• 5件より20件の方が回答精度がいい
• それ以上多くてもあまり変わらなかった

ファインチューニングとの比較 RAGは、ファインチューニングとほぼ同等の成果を出したと言えそう

結論として、性能が同じなのであれば、新しいAPIの仕様が追加されたときに更新コストが低いRAGを利用した方が、メリットがありそうです。

コメント

コーディング例を登録しておいて適宜利用して精度が上がったということは、FAQを事前に作成しておいてそれを利用するのもありってことになるのかな。

出典

• RAG vs ファインチューニング（コーディング性能で比較）
• A Comparative Study of DSL Code Generation: Fine-Tuning vs. Optimized Retrieval Augmentation