almost weekly useful materials - 07/12 -
Opened this issue · 12 comments
NICTでの大規模言語モデルの研究開発
LLM勉強会第二回にて共有されたNICTで行われている日本語版GPT40Bの学習に関する情報共有資料
気になったところだけ抜粋
コメント
他の人の発表でfp16での学習は意味がなかったと紹介されていたが、NICTでfp16/bf16で学習がうまくいっているというのが驚き。
何かコツがあるのだろうか...?
出典
LLM勉強会 Domain adaptation (Language Models in Biomedical Domain)
第二回LLM勉強会にてLLMを医療ドメインにdomain adaptationする際のモデルサイズごとの適切な戦略を紹介している資料 from NII
モデルサイズが~1Bの場合はスクラッチで学習した方がよく、3B ~ 100Bの場合はContinual training + domain specificなinstruction tuningが良い戦略とされている
気になったところだけ抜粋
コメント
- 実務的にとても重要そうな知見
- Continual trainingは通常 関連ドメインのドキュメントを用いてfull parameter をMLMで学習することを言うので、いわゆるfinetuningとは別物であることに注意
- 直感的にはモデルに知識を覚え込ませると言う点でみるとMLMの方がたしかに合理的に見える
出典
RAGアプリにおけるプロンプトとtemperatureの応答品質への影響ほんとのところ
人事FAQに対して作成したRAGにおいて、promptやtemperatureが同性製品室に影響を与えるかを検証した事例の紹介
重要そうなところだけ抜粋
曰くRAGにおいては
- temperatureの影響は軽微で、高い方が生成品質が高い時がある
- 英語によるpromptingよりも日本語の方が質が高い
- ロールをきちんと指定する
コメント
- ちゃんと設定別に生成結果を集計していて偉い
- 今回の結果が別のモデルや、別の事例に適用できるかはわかららないが、やっぱり精度を測ることが大事
- prompt opsの発達が待たれる
出典
人名とニックネームが混じった検索の改善
表題の通り
実施したテクは以下
- n-gramによる部分一致検索 (今回は3)
- ひらがな/カタカナ, 大文字/小文字の統一
- 半角/全角 スペースの削除
- 完全一致時と部分一致でスコアに差をつける
コメント
メモ
出典
外部データをRetrievalしてLLM活用する上での課題と対策案
RAGを行う上で考えなくてはならない具体的な課題と対策案が述べられている良記事
課題1: retrievalに適さない形でソースデータがsplitされる場合がある
ソースデータの構造によってはタイトルにだけ固有名詞が振られており、本文中には対象の名称が一切含まれていない場合がある。 (記事中の例ではタイトルにポケモンの名前、本文にポケモンの説明)
この場合、queryをembeddingしただけでは本文中の関連箇所を抽出できない場合がある。
考えられる対策
- ソースデータの構造を意識して文章を格納する
- 例えば、分割したそれぞれの本文の先頭に「固有名詞の説明: 」などのマークをつける
- queryを明確にする
- 質問文を検索しやすい別の文章に置き換えてから類似度を測る
- LLMで仮の回答結果を生成させるHyDEが有名 (ただしこいつはめっちゃ遅い 10~30s)
- 情報量のない文章を事前に削除しておく
- ソースデータをretrievalしやすい形にLLMで整形し直す
課題2: LLMが見たことない単語を扱う場合
LLMを学習した際に見たことのない単語を含むqueryはembeddingも不安定になることが想定される (記事の例ではポケモンのニャオハ)
考えられる対策
- 単語の共起ベースで類似度を計算する
- 未知の単語を含んだコーパスでembeddingモデルを再学習する
- 未知の単語を既に含んでいる別のモデルを利用する
コメント
- 高品質なRAGを作成するためには情報検索領域の手法を積極的に取り入れていくことが必要そう
- 「ソースデータをretrievalしやすい形にLLMで整形し直す」というのは界隈でもやり方が模索されている印象
- 例)「XXはYYです」のような文章を事前にLLMでたくさん作っておく。HyDEを事前に行なっているという見方もできる
- query → queryをretrievalしやすいformatに整形 → retrieval という方法もありそう
- 例) ReAct的なのを利用して、このqueryを達成するための検索ワードを生成してください
- どんぴしゃの回答を出せなくても、ここら辺調べればいいんじゃね？的な推薦で助かるケースもあるか
出典
DockerイメージからDockerビルド時の履歴を確認する方法とは？
以下のコマンドで確認可能
docker history <イメージ名>:<タグ名>
実行結果
コメント
小テクだが、officialでない公開imageを利用する場合はとても役に立つと思った。
出典
AWS不要なリソースの削除を対応したのお話
AWSのコスト削減をする際にチェックするべきポイントがまとまっている良記事
コメント
実施する機会のたびに見返したい
出典
CNN+ViTモデルの傾向【サーベイ】
CNNとViTの認識傾向の違いをまとめ、ViTのアーキテクチャ改善動向についても触れられている記事
以下重要そうな点を抜粋
CNN
- カーネル範囲で特徴抽出
- 局所的な認識に有効→エッジなどの低レベル特徴を認識
- ImageNetで高精度化
- 様々なタスクにおいて高性能
ViT
- 画像をパッチに分割し全体の関係性を捉える
- 浅い層から受容野が広い→高レベル特徴を認識
- 超大規模モデルで高精度
- Transformerベースの可能性は無限大
局所的な認識のCNNはテクスチャに依存し，大局的な認識のViTは形状に依存する
CNNは高周波を認識，ViTは低周波を認識する特性がある．そのため，画像全体に高周波ノイズを付与した場合，高周波認識を行うCNNに影響があり，精度を低下させる．反対に，低周波ノイズを付与した場合は，ViTの精度が低下する．
画像に自然ノイズ，敵対攻撃などを加えノイズへの頑健性を調査した．結果として，有効なモデルがあるわけでななく，引き分けの結果である．
ViTの代表的な問題点と改善方法
- 計算量が膨大
- 入力特徴量を畳み込みによりダウンサンプリング
- キー，バリューをダウンサンプリング
- SAの計算範囲を制限
- 細かい認識が苦手
- CNNの持つ局所的な認識能力を獲得
- ViTはImageNetで精度向上しない
- CNNの持つ「近い画素は関係が深い」バイアスを獲得
ViTはImageNet程度の枚数では、局所的な認識能力が生まれない？
コメント
良いまとめ。
解くべきタスクに局所的な傾向が必要か大域的な傾向が必要かで、使い分ける必要がある
出典
Function Calling対応Playgroundを作って検証してみた/LLMMeetup#3
function callingの関数に失敗時の挙動や意図しない入力時の挙動を書いておくことで、プロンプトインジェクション対策がある程度可能であることを紹介しているスライド
コメント
奥が深い
出典
OpenAIの埋め込みよりも高性能？多言語E5を日本語で評価してみる
多言語テキスト埋め込みモデル Multilingual-E5-large とOpenAIのtext-embedding-ada-002の性能をJSTSで比較している記事
E5は以下のように学習されているとのこと
結果は以下の通りで、扱える系列長の差は大きいが、類似度判定タスクだと、open aiのモデルよりも性能が高く出ている
コメント
でもページで確認してみると、smallのモデルサイズは118Mで推論時間もかなり軽い
今日もいい天気ですね！
Computation time on Intel Xeon 3rd Gen Scalable cpu: 0.022 s
largeのモデルサイズは560Mで推論時間はちょっと長くなる
今日もいい天気ですね！
Computation time on Intel Xeon 3rd Gen Scalable cpu: 0.075 s
いずれにせよCPUで1秒かからないのはすごい
出典
PyTorchコーディング時の実装負担を低減させるテンプレートコード
Pytorchの学習に利用するコード群を適切な粒度に分割してモジュール化したコードを紹介している記事。
以下のような感じに分かれていて、なかなかいい感じ
コメント
参考になる
出典
生成系AIの実応用に向けて
LINEによる生成形AIの解説および、LINE内での取り組みの共有資料
特に参考になったものだけ抜粋
コメント
LLMの生成の前と後に色々ステップを設けているのが印象的。自分で何かシステムを組むときに参考にしたい。