NumericReasoning
#Pocket
#NLP
#LanguageModel
Issue Date: 2024-11-09 Number Cookbook: Number Understanding of Language Models and How to Improve It, Haotong Yang+, arXiv'24 Summary大規模言語モデル（LLMs）の数値理解および処理能力（NUPA）を調査し、41の数値タスクを含むベンチマークを導入。多くのタスクでLLMsが失敗することを確認し、NUPA向上のための技術を用いて小規模モデルを訓練。ファインチューニングによりNUPAが改善されるが、すべてのタスクには効果がないことが判明。思考の連鎖技術の影響も探求。研究はLLMsのNUPA改善に向けた初歩的なステップを示す。 Commentんー、abstしか読んでいないけれども、9.11 > 9.9 については、このような数字に慣れ親しんでいるエンジニアなどに咄嗟に質問したら、ミスして答えちゃう人もいるのでは？という気がする（エンジニアは脳内で9.11 > 9.9を示すバージョン管理に触れる機会が多く、こちらの尤度が高い）。
LLMがこのようなミス（てかそもそもミスではなく、回答するためのcontextが足りてないので正解が定義できないだけ、だと思うが、、）をするのは、単に学習データにそういった9.11 > 9.9として扱うような文脈や構造のテキストが多く存在しており、これらテキスト列の尤度が高くなってこのような現象が起きているだけなのでは、という気がしている。
instructionで注意を促したり適切に問題を定義しなければ、そりゃこういう結果になって当然じゃない?という気がしている。
（ここまで「気がしている」を3連発してしまった…😅）
また、本研究で扱っているタスクのexampleは下記のようなものだが、これらをLLMに、なんのツールも利用させずautoregressiveな生成のみで解かせるというのは、人間でいうところの暗算に相当するのでは？と個人的には思う。
何が言いたいのかというと、人間でも暗算でこれをやらせたら解けない人がかなりいると思う（というか私自身単純な加算でも桁数増えたら暗算など無理）。
一方で暗算ではできないけど、電卓やメモ書き、計算機を使っていいですよ、ということにしたら多くの人がこれらタスクは解けるようになると思うので、LLMでも同様のことが起きると思う。
LLMの数値演算能力は人間の暗算のように限界があることを認知し、金融分野などの正確な演算や数値の取り扱うようなタスクをさせたかったら、適切なツールを使わせましょうね、という話なのかなあと思う。
元ポスト: https://x.com/omarsar0/status/1854528742095458337?s=46&t=Y6UuIHB0Lv0IpmFAjlc2-QICLR25のOpenReview。こちらを読むと興味深い。
https://openreview.net/forum?id=BWS5gVjgeY
幅広い数値演算のタスクを評価できるデータセット構築、トークナイザーとの関連性を明らかにした点、分析だけではなくLLMの数値演算能力を改善した点は評価されているように見える。
一方で、全体的に、先行研究との比較やdiscussionが不足しており、研究で得られた知見がどの程度新規性があるのか?といった点や、説明が不十分でjustificationが足りない、といった話が目立つように見える。
特に、そもそもLoRAやCoTの元論文や、Numerical Reasoningにフォーカスした先行研究がほぼ引用されていないらしい点が見受けられるようである。さすがにその辺は引用して研究のcontributionをクリアにした方がいいよね、と思うなどした。>I am unconvinced that numeracy in LLMs is a problem in need of a solution. First, surely there is a citable source for LLM inadequacy for numeracy. Second, even if they were terrible at numeracy, the onus is on the authors to convince the reader that this a problem worth caring about, for at least two obvious reasons: 1) all of these tasks are already trivially done by a calculator or a python program, and 2) commercially available LLMs can probably do alright at numerical tasks indirectly via code-generation and execution. As it stands, it reads as if the authors are insisting that this is a problem deserving of attention --・I'm sure it could be, but this argument can be better made.
上記レビュワーコメントと私も同じことを感じる。なぜLLMそのものに数値演算の能力がないことが問題なのか?という説明があった方が良いのではないかと思う。
これは私の中では、論文のイントロで言及されているようなシンプルなタスクではなく、
・inputするcontextに大量の数値を入力しなければならず、
・かつcontext中の数値を厳密に解釈しなければならず、
・かつ情報を解釈するために計算すべき数式がcontextで与えられた数値によって変化するようなタスク（たとえばテキスト生成で言及すべき内容がgivenな数値情報によって変わるようなもの。最大値に言及するのか、平均値を言及するのか、数値と紐づけられた特定のエンティティに言及しなければならないのか、など）
（e.g. 上記を満たすタスクはたとえば、金融関係のdata-to-textなど）では、LLMが数値を解釈できないと困ると思う。そういった説明が入った方が良いと思うなあ、感。 #NaturalLanguageGeneration #Pocket #NLP #DataToTextGeneration #Prompting
Issue Date: 2024-04-04 Prompting for Numerical Sequences: A Case Study on Market Comment Generation, Masayuki Kawarada+, N_A, arXiv'24 SummaryLLMsは、構造化データに対するプロンプト生成に関する研究が進んでいるが、時系列数値データに関する詳細な調査が不足している。本研究では、株価の数値系列を入力として市場コメントを生成するタスクに焦点を当て、さまざまな入力表現を探究する。実験結果は、プログラミング言語に似たプロンプトがより良い結果をもたらすことを示しており、数値系列からテキストを生成する際の効果的なプロンプト作成について示唆を提供している。 CommentData-to-Text系のタスクでは、しばしば数値列がInputとなり、そこからテキストを生成するが、この際にどのようなフォーマットで数値列をPromptingするのが良いかを調査した研究。Pythonリストなどのプログラミング言語に似たプロンプトが高い性能を示し、自然言語やhtml, latextなどのプロンプトは効果が低かったとのこと
#Pocket #NLP #Dataset #LanguageModel #InstructionTuning #Mathematics
Issue Date: 2023-09-30 MAmmoTH: Building Math Generalist Models through Hybrid Instruction Tuning, Xiang Yue+, N_A, arXiv'23 SummaryMAmmoTHは、数学の問題解決に特化した大規模言語モデルであり、厳密にキュレーションされた教育データセットで訓練されています。このモデルは、CoTとPoTのハイブリッドな根拠を提供し、さまざまな数学の分野を包括的にカバーしています。MAmmoTHは、既存のオープンソースモデルを大幅に上回り、特にMATHデータセットで高い精度を示しています。この研究は、多様な問題のカバレッジとハイブリッドな根拠の使用の重要性を強調しています。 Comment9つのmath reasoningが必要なデータセットで13-29%のgainでSoTAを達成。
260kの根拠情報を含むMath Instructデータでチューニングされたモデル。
project page: https://tiger-ai-lab.github.io/MAmmoTH/
Issue Date: 2024-11-09 Number Cookbook: Number Understanding of Language Models and How to Improve It, Haotong Yang+, arXiv'24 Summary大規模言語モデル（LLMs）の数値理解および処理能力（NUPA）を調査し、41の数値タスクを含むベンチマークを導入。多くのタスクでLLMsが失敗することを確認し、NUPA向上のための技術を用いて小規模モデルを訓練。ファインチューニングによりNUPAが改善されるが、すべてのタスクには効果がないことが判明。思考の連鎖技術の影響も探求。研究はLLMsのNUPA改善に向けた初歩的なステップを示す。 Commentんー、abstしか読んでいないけれども、9.11 > 9.9 については、このような数字に慣れ親しんでいるエンジニアなどに咄嗟に質問したら、ミスして答えちゃう人もいるのでは？という気がする（エンジニアは脳内で9.11 > 9.9を示すバージョン管理に触れる機会が多く、こちらの尤度が高い）。
LLMがこのようなミス（てかそもそもミスではなく、回答するためのcontextが足りてないので正解が定義できないだけ、だと思うが、、）をするのは、単に学習データにそういった9.11 > 9.9として扱うような文脈や構造のテキストが多く存在しており、これらテキスト列の尤度が高くなってこのような現象が起きているだけなのでは、という気がしている。
instructionで注意を促したり適切に問題を定義しなければ、そりゃこういう結果になって当然じゃない?という気がしている。
（ここまで「気がしている」を3連発してしまった…😅）
また、本研究で扱っているタスクのexampleは下記のようなものだが、これらをLLMに、なんのツールも利用させずautoregressiveな生成のみで解かせるというのは、人間でいうところの暗算に相当するのでは？と個人的には思う。
何が言いたいのかというと、人間でも暗算でこれをやらせたら解けない人がかなりいると思う（というか私自身単純な加算でも桁数増えたら暗算など無理）。
一方で暗算ではできないけど、電卓やメモ書き、計算機を使っていいですよ、ということにしたら多くの人がこれらタスクは解けるようになると思うので、LLMでも同様のことが起きると思う。
LLMの数値演算能力は人間の暗算のように限界があることを認知し、金融分野などの正確な演算や数値の取り扱うようなタスクをさせたかったら、適切なツールを使わせましょうね、という話なのかなあと思う。
https://openreview.net/forum?id=BWS5gVjgeY
幅広い数値演算のタスクを評価できるデータセット構築、トークナイザーとの関連性を明らかにした点、分析だけではなくLLMの数値演算能力を改善した点は評価されているように見える。
一方で、全体的に、先行研究との比較やdiscussionが不足しており、研究で得られた知見がどの程度新規性があるのか?といった点や、説明が不十分でjustificationが足りない、といった話が目立つように見える。
特に、そもそもLoRAやCoTの元論文や、Numerical Reasoningにフォーカスした先行研究がほぼ引用されていないらしい点が見受けられるようである。さすがにその辺は引用して研究のcontributionをクリアにした方がいいよね、と思うなどした。>I am unconvinced that numeracy in LLMs is a problem in need of a solution. First, surely there is a citable source for LLM inadequacy for numeracy. Second, even if they were terrible at numeracy, the onus is on the authors to convince the reader that this a problem worth caring about, for at least two obvious reasons: 1) all of these tasks are already trivially done by a calculator or a python program, and 2) commercially available LLMs can probably do alright at numerical tasks indirectly via code-generation and execution. As it stands, it reads as if the authors are insisting that this is a problem deserving of attention --・I'm sure it could be, but this argument can be better made.
上記レビュワーコメントと私も同じことを感じる。なぜLLMそのものに数値演算の能力がないことが問題なのか?という説明があった方が良いのではないかと思う。
これは私の中では、論文のイントロで言及されているようなシンプルなタスクではなく、
・inputするcontextに大量の数値を入力しなければならず、
・かつcontext中の数値を厳密に解釈しなければならず、
・かつ情報を解釈するために計算すべき数式がcontextで与えられた数値によって変化するようなタスク（たとえばテキスト生成で言及すべき内容がgivenな数値情報によって変わるようなもの。最大値に言及するのか、平均値を言及するのか、数値と紐づけられた特定のエンティティに言及しなければならないのか、など）
（e.g. 上記を満たすタスクはたとえば、金融関係のdata-to-textなど）では、LLMが数値を解釈できないと困ると思う。そういった説明が入った方が良いと思うなあ、感。 #NaturalLanguageGeneration #Pocket #NLP #DataToTextGeneration #Prompting
Issue Date: 2024-04-04 Prompting for Numerical Sequences: A Case Study on Market Comment Generation, Masayuki Kawarada+, N_A, arXiv'24 SummaryLLMsは、構造化データに対するプロンプト生成に関する研究が進んでいるが、時系列数値データに関する詳細な調査が不足している。本研究では、株価の数値系列を入力として市場コメントを生成するタスクに焦点を当て、さまざまな入力表現を探究する。実験結果は、プログラミング言語に似たプロンプトがより良い結果をもたらすことを示しており、数値系列からテキストを生成する際の効果的なプロンプト作成について示唆を提供している。 CommentData-to-Text系のタスクでは、しばしば数値列がInputとなり、そこからテキストを生成するが、この際にどのようなフォーマットで数値列をPromptingするのが良いかを調査した研究。Pythonリストなどのプログラミング言語に似たプロンプトが高い性能を示し、自然言語やhtml, latextなどのプロンプトは効果が低かったとのこと
#Pocket #NLP #Dataset #LanguageModel #InstructionTuning #Mathematics
Issue Date: 2023-09-30 MAmmoTH: Building Math Generalist Models through Hybrid Instruction Tuning, Xiang Yue+, N_A, arXiv'23 SummaryMAmmoTHは、数学の問題解決に特化した大規模言語モデルであり、厳密にキュレーションされた教育データセットで訓練されています。このモデルは、CoTとPoTのハイブリッドな根拠を提供し、さまざまな数学の分野を包括的にカバーしています。MAmmoTHは、既存のオープンソースモデルを大幅に上回り、特にMATHデータセットで高い精度を示しています。この研究は、多様な問題のカバレッジとハイブリッドな根拠の使用の重要性を強調しています。 Comment9つのmath reasoningが必要なデータセットで13-29%のgainでSoTAを達成。
260kの根拠情報を含むMath Instructデータでチューニングされたモデル。
project page: https://tiger-ai-lab.github.io/MAmmoTH/
#Survey
#NLP
Issue Date: 2023-07-18
A Survey of Deep Learning for Mathematical Reasoning, ACL'23
Summary数学的な推論とディープラーニングの関係についての調査論文をレビューし、数学的な推論におけるディープラーニングの進歩と将来の研究方向について議論しています。数学的な推論は機械学習と自然言語処理の分野で重要であり、ディープラーニングモデルのテストベッドとして機能しています。また、大規模なニューラル言語モデルの進歩により、数学的な推論に対するディープラーニングの利用が可能になりました。既存のベンチマークと方法を評価し、将来の研究方向についても議論しています。
#NLP
#LanguageModel
#Chain-of-Thought
Issue Date: 2023-07-11
Teaching Arithmetic to Small Transformers, Nayoung Lee+, N_A, arXiv'23
Summary本研究では、GPT-4のような大規模言語モデルが、教師なしのトークン予測目的に明示的にエンコードされていないにもかかわらず、算術演算や基本的な関数を効率的に学習できることを示しています。訓練データのフォーマットの変更やchain-of-thoughtスタイルのデータの使用により、精度や収束速度が改善されます。また、訓練中の算術とテキストデータの相互作用やモデルのスケールの影響も研究されています。この研究は、高品質な指導的なデータが算術能力の引き出しにおいて重要であることを強調しています。
Comment小規模なtransformerに算術演算を学習させ、どのような学習データが効果的か調査。CoTスタイルの詳細なスクラッチパッドを学習データにすることで、plainなもの等と比較して、予測性能や収束速度などが劇的に改善した
結局next token predictionで学習させているみたいだけど、本当にそれで算術演算をモデルが理解しているのだろうか?という疑問がいつもある