almost weekly useful materials - 03/06 -

[GENZITSU]

LLM時代の情報抽出

Stockmark Tech Meetup #8 LLM時代の情報抽出の内容

stockmark researcher: 広田さんの講演

勉強になったこと

論文自体はT5程度のモデルでやっているが、LLMにも適応可能 以下は実装イメージ

UIE関係のその他の研究、普通のLLMではなくcode生成用のモデルを使った方が良いらしい

論文紹介：ChatGPT で情報抽出タスクは解けるのか？ Is information extraction solved by ChatGPT? An analysis of performance, evaluation criteria, robustness and errors という資料が役に立ちそう

より精度を高めたいときはLLMによる情報抽出jobに任せる。自前で作成した13BのモデルをvLLMで動かして、1日あたり2~3万件は捌ける。情報抽出用にLoRAチューニングしている。

Q&A

• KGにするモチベーション
  • マルチホップの情報を拾ってQAを行う際に、ある概念に紐づいてる、別の概念のdocumentをまるっと取得するなどがある。
• KGの応用方法
  • 概念を構造化させて、新しい技術の組み合わせを発掘する (ややチャレンジ寄り)
  • query expansion
  • 全文検索などにつかう スキーマ
  • wikiデータなどのスキーマを元にダウンストリームタスクに適したスキーマを作成している。

コメント

KGを元に関連概念を遡って関連ドキュメントを検索していくというのは面白そう。 巨大なKGをエンジニアリング的にどう運用していくのかが気になりではある

出典

• 発表リンク

[GENZITSU]

ゼロからつくる大規模言語モデル

社会的課題解決型データサイエンス・AI研究推進体シンポジウム -大規模言語モデルLLMの最前線- における 高瀬 翔 氏（LINEヤフー株式会社／SB Intuitions）の発表

勉強になったこと

既存の英語モデルには日本語データが入っているが、あれはたまたま入ってるだけにすぎない。事前学習をすっ飛ばして日本語のFTすればいいのでは？という説もあるが日本語の知識を覚えさせるためにも事前学習が必要という考え

実はllama2の70bの素の性能でもJCQAではかなり出る。一方で日本文化圏に対する詳細な知識が必要な場合は事前学習が必要？

Llama2では13Bに対して4Tくらいでやっているので実際は20倍以上でやった方が良い。基本的には少なめのパラメータ数で多めのtokenで学習することを目指した方がよいというトレンド

CommonCrawlをつかない選択肢は現状ないので、SBもこれを使っている

LLMにおいてもdata centricでよく見る関係が成り立つ。すなわち、ノイズをできるだけ消して学習した方が良い。一方でコーパスクリーニングしない場合で同程度の性能を達するのは難しい。

テキストクリーニングツールとしてHojiChar/HojiChar というのがある

Llama2で解けるような問題は、英語のデータを事前学習を入れることで性能が上がるが、そうでない専門的な話が必要な時は入れたとて意味がない。

高瀬さん的には小さいモデルでも起きうることが、目につきやすくなっただけではという立場(小さいモデルはこれが発生する前に収束している)。loss spikeが起きる前に戻って学習し直すというのもあるが、それも必ずうまくいくわけではない。

floating pointの設定は自分でやった方がよいが、megatron lmのデフォルト値も信頼できる

日本語コーパスの量をどかっと増やす方法は現状ない。。小規模で実験して大規模に行ってもうまくいかないことが多い

JGLUEの作者はLLMの評価にJGLUEを使っても..という感じらしい。どのデータセットが何の能力を評価しているかが大事

Q&A

• loss spikeについては
  • checkpointを遡ることはやられている？
  • 少し戻ってバッチの順番を変えたり学習率を下げたりはするが、値のスケーリングレベルのことはやっていない
• loss spikeの制御方法に関して論文には記されていないテクがあったりする？
  • 自分はOpenAIがそういうテクを持っていると思う
  • フルスクラッチ学習できる体力を持つことは大事
  • そもそもこの規模で学習している例がほとんどない
  • 予算取りは大変だがやってみながら試す他ない
• ググればわかることは覚えなくてもいい的なことがLLMにも当てはまったりする？深い知識はRAGを使うとか
  • 少数のexpertに分解しようという流れはある
• このようなトレンドがある中であえて日本語で事前学習をする意味はあるか？
  • 現状はわからん
• Adamのハイパラで0.95を使っているのは？
  • 小さいモデルでやってOKだったものを流用した形
• 西田さん)アダルトを排除するかどうか？アダルト系は実は読ませた方がよいのではと思っているが、
  • 含んでおいた方が後々のチューニングで出ないように制御するという方向がある

コメント

基本的に知らないことばかりだったのだが、特に斬新だったのは、簡単な日本語タスクだと素のllama70でもそこそこ溶けてしまうという事実。 ベンチマークをちゃんと作らないとLLMの性能歯正しく測れないんだなということを改めて実感した。 ノイズを消す/消さないの性能差のグラフも地味に重要性が高そう。

出典

• 社会的課題解決型データサイエンス・AI研究推進体シンポジウム -大規模言語モデルLLMの最前線-

[GENZITSU]

大規模言語モデルの事前学習知見

社会的課題解決型データサイエンス・AI研究推進体シンポジウム -大規模言語モデルLLMの最前線- における 藤井一喜 氏（情報理工学院 横田研究室）の発表の発表

勉強になったこと

クラウドのGPUはマルチノード化できない。ノード間の通信速度も大事

3D ParallelはDDP model parallelなどを適切に組み合わせないといけないため、実装が難しい。ただしFROPSは落ちづらい

並列化手法ごとに通信にかかる時間が変わるので、パラメータ調整の必要がある

実装が簡単なFSDPと3D parallelだと2倍ほど効率が変わる

3D parallelはすごいが、アーキテクチャーごとに実装方法を変える必要がある

Q&A

• Loss Splikeを低減する方法は何かあるか？
  • Z lossの導入 (PaLMのやつらしい
  • スパイクが起きた時にバッチをスキップする (BLOOMの時から言われてるやつ
• 勾配の同期
  • メモリを削減するということはノード間の通信が必要になる
  • all gatherなどの演算はテンソルサイズによって変わってくるが、計算時間の大勢を占めるのは行列演算や勾配の通信の方
• 3D parallelのパラメータ計算は手計算で求めているらしい
  • tensor parallelなどは事前知識的にここら辺というのがわかるので、後の設定をgrid search的に求めていく
• lossが下がっている意外に学習がうまくいってるかを判別する方法はないか？
  • 丸暗記をしていないかのチェック (最近のllmは丸暗記してなさそうなので、深くチェックしなかった)
  • val lossが下がっている & MTBenchが全部ちゃんと上がっていることを確認する

コメント

知らないことばかりだったので、勉強になった

出典

• 社会的課題解決型データサイエンス・AI研究推進体シンポジウム -大規模言語モデルLLMの最前線-

[GENZITSU]

みずほ銀行の含意判定ユースケース

第二回 Data Science Live: Bquant EnterpriseにおけるNLPの活用事例で紹介されていたもの

みずほ銀行 国際証券投資部 田村様の公演

テキストデータ前処理

• 目的: 決算会見における発言内容の極性と足元の株価推移の一致を確認
• データ: 株価の時系列推移, 決算会見のトランスクリプト, 企業の役員リストなど
  • 決算のトランスクリプトデータ
    • 発言時間
    • 発言者
    • 発言内容
    • etc
  • トランスクリプトデータは複数文が一括で入ることがある。これを1分ずつに分割
  • 単純にピリオドだけ用いるのではなく。ピリオド+半角スペースなどを用いて分割
    • $10.32 billion →が$10 32billionなどに分けられる
• 不要な文章を含意判定を用いて削除(挨拶やお礼など)
• 含意判定のzero-shot分類を利用して、不要な文を消す
  • this text describes {}
    • greetings 91%
    • sel-introduction 82%
    • gratitude 53%
    • closing presentation 3%
    • earning statements 4%
  • それぞれのカテゴリに対する含意確率をzero shotでも止め察せて、閾値に応じて取り除く文章を選定
  • 企業活動に対する文章かどうかの判定もさせる
• このような前処理の後に、一文ごとに株価上昇という観点でposi/negaをつける
• ポジティブな文章の割合と、株価推移の相関を調べる
• これを503社全てに実施する。さらにセクターごとにセンチメントの推移を確認して投資戦略に活かす

FEDテキスト解析

• 目的: 各会合のposi/nega, タカハトのスコアリングをしたい
• 同じく含意判定で実施
  • Inflation rate {}
    • may peak out
    • may peak out soon
    • is expected to peak out in the near future
    • will peak out
    • is expected to peak out soon
    • will peak out soon
  • それぞれに対する含意確率を求めて、閾値を設定
  • インフレがいつ頃まで続くかみたいなのをスコアに変換
• この含意判定を議事録の全ての文に適用して全体のスコアを設定
• ただし、同じ観点に関してもいろいろな文章を用いて含意判定をする必要がある (一つの質問だとバイアスがかかる)
• インフレの進行度ごとに12種類の質問を作成し、それぞれに対する含意判定結果を利用してインフレ圧力の強弱を見る
  • インフレに対する懸念
  • インフレが上昇する懸念は高止まり
• インフレに関して以外も、Core PCEなどにも適用可能

投資局面の分類 インベストメントクロックの説明

• 目的: 投資局面ごとにアウトパフォームする資産クラスの判定をCPI・価格変動率など野伝統的な数値データを用いて実施
  • インフレ弱：景気弱の時は債券が強い、インフレ強：景気弱の時はキャッシュが強いなど
• FEDのデータでインフレ局面の判定はある程度できるが、これを英語記事のニュースデータを用いて日時で算出できるようにする
  • they are {bullish/bearish} on the {stock/bond} market に対する4項の確率を用いてスコアリング
• 株価が上がったなどのbackward-lokkingの無駄なニュースをタグを用いて削除し、forward-lookingなHLだけにする (消費が増加)などを分析対象に絞る
• 過去10年で1000万研超の記事が存在するため、データ抽出や含意判定をsparkで実施。 (GPUよりも早かったらしい)
• 株式センチメントと債券センチメントを座標変換してインフレ度合いをスコアリング
• ニュースによるインフレファクターの方が従来型のものよりもインフレ上昇を補足しやすかった
• t時点とt-1時点のリターンの相関を計算して、相関予測向上に必要なニュースファクターを推定することで、市場関係者が何に注目しているかをみれるようにする。
  • 例えば米国のそう関与速に有益なスコアとして、FEDの雇用に対する発言やインフレなど
  • 日本はインフレに関するFED議事録/経済成長に関するFED議事録

Q&A

• 含意判定モデルはhuggingfaceから引っ張ってきたモデルを元に実施している
• 実際はneutralに振り分けられる文章が結構でてくるのでそこを事前に除いていく作業が大事。
• bloomberg提供のlanguage modelを元にした分析も別途実施している
• llm関係の取り組みも内部で実施している
• 価格の相関を元にした真のセクター分けをしたい
  • テスラはコモディテイ分類だが、それらのセクターとは明らかに異なる値動きをしている

コメント

含意判定を用いたzero shotで色々なカテゴリ分けをして、投信戦略に生かしているのが面白い。 zero shot分類の正しさや敷居値調整は運用担当が目で見て実施したらしい。

出典

なし

[GENZITSU]

NTT版大規模言語モデル『tsuzumi』の取組について

社会的課題解決型データサイエンス・AI研究推進体シンポジウム -大規模言語モデルLLMの最前線- における 西田京介 氏（NTT人間情報研究所）の発表

勉強になったところ

コメント

独自に言語データを収集して、1000Bトークン以上の専門文書からエンタメにわたるコーパスを構築していると言うのがためになった

出典

• 社会的課題解決型データサイエンス・AI研究推進体シンポジウム -大規模言語モデルLLMの最前線-

[GENZITSU]

ANN-Benchmarks

ANNの各種アルゴリズムの検索性能や速度、indexサイズに対する検索精度などをまとめているブログ

gloveベクトルに対する検索やfasion mnistに対する検索や距離関数に何を用いるかの比較などもある

コメント

また見返せるようにメモ

出典

• ANN-Benchmarks

[GENZITSU]

RAGに捧げるベクトル検索パフォーマンスチューニング

ANNでよく使われる指標である、HNSWのパラメータを変えた際のパフォーマンス比較をしている記事

ハイパラについて

M: 接続できるノードの数を表す 増やすと検索精度が上がるが、検索時間と消費メモリも増加する

efConstruction: インデックスの構築時に探索されるエントリポイント数 増やすと検索精度が上がるが、検索時間※とインデックス構築時間も増加する

efSearch: 検索中にレイヤー間で探索されるエントリポイント数 増やすと検索精度が上がるが、検索時間が増加する ※Mが高い場合のみ

Azure AI Searchのデフォルトは 以下で、ここよりも検索精度/検索時間性能を高められるかがポイント

HnswParameters(*, m: int = 4, ef_construction: int = 400, ef_search: int = 500, metric: str | _models.VectorSearchAlgorithmMetric | None = None, **kwargs: Any)

検索対象

検索対象として、様々なトピックのPowerpointファイルを120件用意しました。

上記のファイルをlang chainのUnstructuredPowerPointLoaderで読み込み、Text splitterで分割しています。 chunk size（分割した文章単位の文字数）: 1000 overlap size（文章のオーバーラップ）: 500

作成後のindexのサイズは1069となりました。

また、ベクトル検索に使用するembeddingはOpen AI APIのtext-embedding-ada-002を使用しました。ada-002の次元数（ベクトルのサイズ）は1536です。

結果

Azure AI Searchのデフォルトだと役6%ほど総当たりと比べて一致率が低い結果になる

ここからチューニングした結果

コメント

脳死でデフォルトパラメータを使っていたので、参考にしたい。 一旦検証する際はMを大きめにしておくことで検索精度を正しく見積もれそうである。

出典

• RAGに捧げるベクトル検索パフォーマンスチューニング

[GENZITSU]

LlamaIndex Sessions: Practical Tips and Tricks for Productionizing RAG

Jasperという企業でRAGを商用サービスに適用する際の種々のTipsを紹介している動画

勉強になったところ

PDFのParseにはAdobe APIが良かったらしい

回答に必要なドキュメントを全て取れるとは限らないので、大きめのdocument単位でindex を貼っておく。

Retrieve時は二つの粒度のことなるindexの検索スコアを合算して、大きめのdocument単位のものを取得する

RerankingにLLMを用いる。その際に、一度要約を作成してから並び替えて、元の文章を利用する (ここで利用するLLMはgpt4)

Tree Synthesizerを用いて回答を作成する

各コンポーネントにかかる時間

ユーザーからのFBを得られるような機構を残しておく

コメント

小さいchunkと大きいchunkのsummaryを一緒に突っ込む方法が斬新だった。

LLMによるRerankingは、正直使うべきではないような気はする...w (ローカルで作成するならまだしも)

出典

• LlamaIndex Sessions: Practical Tips and Tricks for Productionizing RAG (feat. Sisil @ Jasper)