Reading Reflections


Paper/Blog Link My Issue
#NLP #Dataset #LanguageModel #AIAgents #Evaluation #Selected Papers/Blogs #KeyPoint Notes #AgentSkills #AgentHarness Issue Date: 2026-02-17 GPT Summary- LLMエージェントを強化する手続き知識のパッケージであるエージェントスキルの効果を測定するため、SkillsBenchを提案。これにより、86タスクを利用したキュレーション済みスキルと決定論的検証器を組み合わせたベンチマークを作成。各タスクはスキルなし、キュレーション済みスキル、自己生成スキルの3条件で評価。キュレーション済みスキルは合格率を平均16.2ポイント向上させるが、分野による効果の差が顕著。自己生成スキルは有意な利益をもたらさず、信頼性のある手続き的知識の自作が困難であることを示した。Focused Skillsは、包括的なドキュメンテーションを上回る効果を持ち、小型モデルがスキルを有することで大型モデルに匹敵する場合がある。 Comment

元ポスト:

Loading…

Agent Skillsに関するベンチマーク。11種類の多様なドメインのタスクによって構成される。コーディングやソフトウェアエンジニアリングに留めらないのが特徴的に見える。

image

評価時は
- スキルがない場合
- スキルがある場合
- 自己生成したスキルを使う場合

の3種類で評価する。

ハーネスはClaude Code, Codex CLI, Genini CLIの3種類で評価し、モデルはGPT, Claude, Gemini系列のモデルを利用。takeawayは以下:

- skillsはタスクの性能を改善するが、モデルとハーネスの組み合わせでgainが大きく異なる
- Gemini CLIとGemini Flashが最高性能を達成
- スキルを自己生成しても性能向上に寄与しない（むしろネガティブな影響も見受けられる）
- 3種類のハーネスのうち
- Claude Codeが最も多くスキルを活用し、Claudeモデルは一貫してgainを得る
- Gemini CLIは最も高いraw performanceを達成
- 性能はcompetitiveだが、Codex CLIは必要なスキルの内容を取得しても、スキルを利用せず独立して処理してしまう頻度が高い
- skillによって得られるgainはドメインによって大きく異なる。事前学習時に馴染み薄いドメインほど、skillの導入による恩恵がでかい。

image

- skillの導入によって、タスクによっては性能が悪化するものもある。これはモデルがすでにうまく処理をする能力を持っているのに、スキルが提供されることでそれらがconflictすることに起因する可能性がある。
- タスクごとに、2--3個のスキルを提供するのが性能がよく、4+になるとgainが低下する
- スキルの定義はproceduralな知識をコンパクト（compact)あるいは詳細に記述したもの(detailed)が良く（i.e., 特定のことについて集中的に記述するもの）、徹底的に記述されたドキュメント（comprehensive)は性能が悪化する。
- SLM+skillによって、スキル利用なしのより大きなモデルを性能で上回ることができる

Agent skillsの効果について定量的に分析した初めての研究な気がしており、重要な研究だと思われる。AI AgentというとClaudeが優秀な印象が強いが（コーディングやソフトウェアエンジニアリングでの性能に基づく印象）、本ベンチマークでは多様なドメインで評価をしており、Gemini CLI+Gemini Flashが最も平均的な性能が高いのが興味深い。




Paper/Blog Link My Issue
#Analysis #Pretraining #NLP #LanguageModel #Supervised-FineTuning (SFT) #Regularization #PostTraining #KeyPoint Notes #DownstreamTasks Issue Date: 2026-02-12 GPT Summary- 事前訓練での重みの減衰がモデルの可塑性に与える影響を分析。高い減衰値が微調整時に性能向上を促進し、直感に反するトレードオフを引き起こすことを示す。重みの減衰が線形分離可能な表現を促進し、過学習を抑制する役割も明らかに。ハイパーパラメータ最適化における新たな評価指標の重要性を強調。 Comment

元ポスト:

Loading…

事前学習時にWeight Decayを大きくするとPerplexityは悪化する場合があるが、Perplexityが悪化していたとしてもSFTを通じて最終的に得られるdownstream task性能のgainが高い場合がある、という話に見える。つまり、Findings2に書かれている通り、事前学習時にPerplexityを最小化するようなWeight Decayの設定はdownstream性能を高めるという観点では必ずしも必須ではない。ではなぜこのようなことが起きるかというと、Weight Decayを大きくするとAttentionのQK matricesのpseudo-rank（=行列の95%を説明するのに必要な特異値の割合）が改善されることが実験により観察され、一般的に低ランクな表現は正則化の結果として現れることから、シンプルな表現によってよりモデルがロバストになるのでは、という点が考察されている。また、実際にValidation dataとTraining dataのlossの差分を見ることで、Weight Decayが大きいことによってtraining dataへのoverfitが抑制されていることが観測された。
image

Weight DecayはもともとRegularizationとしての働きがあるので、それはそうなのだろうな、という感想を持ったのだが、特にQK matrixが正則化の影響を強く受けるというのはおもしろかった。つまり、クエリ対してよりロバストな写像を学習できているということだと思われる。

Perplexityが事前学習の良さを測るために必ずしも良いわけではないよ、という意味での関連:
- [Paper Note] Perplexity Cannot Always Tell Right from Wrong, Petar Veličković+, arXiv'26, 2026.01




Paper/Blog Link My Issue
#NLP #LanguageModel #ReinforcementLearning #Reasoning #Test-Time Scaling #PostTraining #read-later #Selected Papers/Blogs #Aggregation-aware #KeyPoint Notes Issue Date: 2026-01-19 GPT Summary- PaCoReは、固定されたコンテキストウィンドウを超えた計算量の拡張を目指すトレーニング・推論フレームワークです。逐次的パラダイムを脱し、複数のラウンドでメッセージ伝播アーキテクチャを用いた並列探索を行います。各ラウンドでは、並列推論経路を起動し、結果を圧縮して次のラウンドに統合し、最終的な答えを生成します。このアプローチにより、文脈制限を超えた実質的な計算量が実現され、特に数学推論で顕著な成果を示します。8BモデルはHMMT 2025で94.5%を達成し、オープンソース化された資源により、さらなる研究が期待されています。 Comment

元ポスト:

Loading…

- [Paper Note] STEP3-VL-10B Technical Report, Ailin Huang+, arXiv'26, 2026.01

で活用されているRLでtest time scalingを学習する手法

モデルのSequentialなReasoning能力はcontext windowに制限されてしまうので、並列にモデルにreasoningをさせてそれらを集約させて、さらに直列で思考させる、といった処理を繰り返すことで、context windowの制限を超えてreasoning能力を高めることを目的としたtest-time scaling手法。

モデルに複数個のreasoning trajectoryを生成させ、それぞれのtrajectoryにCompaction Function（式2） を適用[^1]することで各resaoning trajectoryをcompaction message M として圧縮。圧縮したtrajectoryを元のpromptとともに与えて、同様の操作をRラウンド繰り返すtest-time scaling手法。最後のラウンドでは、生成するreasoning trajectoryの数を1とすることで最終的な応答を得る。モデルをこのプロセスに最適化するために、各ラウンドにおいて (x, M) が与えられた時に、並列して生成するreasoning trajectoryに対してRLVRを適用することでモデルの性能を引き上げている。Mはベースモデルによって事前に生成し、生成した結果をキャッシュしておくことでRL中に利用する。

image

PaCoReによってベースモデル（RLVR-8B）の性能が着実に押し上げられ、一部ベンチマークにおいてフロンティアモデルには届かなないものの非常に高い性能を示している。
image

また、Parallel test-time scaling手法として代表的なSelf-Consistencyと比較しても、より少ないtoken量で、より高いgainを得ている。
image

[^1]: 本研究ではCompatction Functionとしてreasoningの特性を利用して、結論部分に関連する部分を抽出し、intermediateなreasoning tokenは破棄するような関数を適用している

Figure1においてベースモデルであるRLVR-8B (Qwen3-8B-Base) に対して、PaCoReによってpost-trainingされたモデルがより良好なtest-time scalingを示すことが図示されているが、RLVR-8Bによるtest-time scaling手法としてどのようなものが適用されたのか（parallelなのか、sequentialなのか、結果を集約したのか等）が書かれていない気がする。

何が気になっているのかというと、提案手法が効果があることは分かったのだが、これがPaCoReの枠組みに則ったRLを適用しないと発現しないものなのか、それともPaCoReに特化したpost-trainingを実施しなくても、何らかのベースモデルに同様のtest-time-scalingの枠組みを利用すれば高い性能を得られるのか、といった点が気になる。どこかに書いてあるのだろうか？

image




Paper/Blog Link My Issue
#ComputerVision #Controllable #Transformer #DiffusionModel #Architecture #PostTraining #VideoGeneration/Understandings #ICCV #Game #One-Line Notes Issue Date: 2026-04-02 GPT Summary- GameFactoryは、アクション制御とシーン一般化を両立させたゲームビデオ生成のフレームワーク。GF-Minecraftというデータセットを用いてキーボードとマウス入力を正確に制御し、自己回帰生成を可能にする。さらに、オープンドメイン生成事前知識を活用し、固定スタイルを超えた多様なゲームの創出を支援。ドメインアダプターによる学習戦略によって、アクション制御が特定ゲームスタイルに縛られず、シーン一般化が実現。実験により、GameFactoryが効果的にオープンドメインのゲームビデオを生成できることが確認された。 Comment

github: https://github.com/KlingAIResearch/GameFactory

小規模なマイクラデータでaction control moduleと呼ばれるモジュールを学習することで、動画生成モデルに対して、マウス、キーボード入力によるコントロール能力を転移し、ゲーム映像を生成できる、という話に見える。
image

4.2節に書かれているように、transformerのブロックにaction control moduleと呼ばれる、キーボードとマウスの入力をwindowでグルーピングしてエンコードするようなブロックを挿入し、エンコードされたvideo側の潜在表現に対して条件付けを行い生成を可能にしているようである(Figure 3, 4)。学習する際はFigure 6に示されているように、まずはopen domainのデータで事前学習、その後LoRAでgame video dataのドメイン情報を入れ、他モジュールはfreezeした上で、action control moduleのみを学習する。
image

transformerアーキテクチャにドメイン依存のブロックを後でplugし性能向上させるアプローチはおもしろいと感じる。




Paper/Blog Link My Issue
#NLP #Dataset #LanguageModel #Alignment #Evaluation #Selected Papers/Blogs #RewardModel #KeyPoint Notes #DownstreamTasks Issue Date: 2026-02-06 GPT Summary- 報酬モデルは、言語モデルの訓練後に好みデータを利用して指示遵守や推論、安全性を最適化するための訓練目標を提供します。新たに開発された「RewardBench 2」は、スキル領域を評価するための挑戦的なベンチマークを提供し、既存のモデルが低いスコアを示しつつも下流性能との相関が高いことを示しています。このベンチマークは人間のプロンプトを基にしており、厳格な評価プラクティスを促進しています。論文では、ベンチマークの構築プロセスと既存モデルの性能を報告し、モデルの下流使用との相関を定量化しています。 Comment

以下の6つのドメインで構成されるReward Modelの評価のためのベンチマーク:
- Factuality: hallucinationや誤りの有無の判定
- Precise Instruction Following: 細かい指示に対する追従性能
- Math: **自由記述**の数学に関するプロンプトに対する応答に関する能力
- Safety: 有害な応答に対して適切に対処できるか（応答拒否 or 適切な応答）
- Focus: 一般的なユーザのクエリに対して、トピックに沿った高品質な応答ができているか否か
- **Ties**: 「虹の色を1つ挙げて」といったような、複数の正解があり得るが、無数の不正解があるようなタスク（特定の正解にバイアスがかからず、正解と不正解を区別する能力を評価）

image

Reward Bench 2 での性能が、Best-of-N (=N個応答をサンプリングし最も良いものを採用するtest-time scaling手法)における様々なdownstreamタスクと強い相関を示すことが示されている。
image

ただし、PPOでの事後学習について焦点を当てた場合
- ベースモデルの出自がReward Modelと異なる場合
- Reward Modelの学習データが、ベースモデルと大きく異なる場合
においては、Reward Bench 2で高い性能が得られていても、PPOにおいて高い性能が得られず、特にベースモデルの出自が異なる場合の影響が顕著とのこと。

image

Reward Modelの性能が必ずしもPPOの事後学習後の下流タスクに対する性能と相関せず（ただし、Rewardベンチの性能が低い部分においてはおおまかに推定できる）、ベースモデルの出自が異なるReward Modelを使った場合や、Reward Modelとベースモデルが学習したプロンプトの分布が大きく異なる場合にこのような不整合が強く現れるというのは興味深く、おもしろかった。
Reward Modelとベースモデルの開始点が異なる場合は、RLによる学習がうまくいかないというのは、直感的でわかりやすい説明だなと感じた。

openreview: https://openreview.net/forum?id=fb0G86Dewb




Paper/Blog Link My Issue
#Tools #NLP #Supervised-FineTuning (SFT) #SelfImprovement Issue Date: 2025-03-07 GPT Summary- STARTという新しいツール統合型長いチェーン・オブ・ソウト推論LLMを提案。外部ツールを活用することで、幻覚や非効率性を克服し、複雑な計算や自己検証が可能に。主な手法は、意図的に設計されたヒントを挿入して外部ツールの活用を促すHint-inferと、推論経路にツール呼び出しを付与して微調整するHint-RFT。これにより、科学QAや数学、コードベンチマークで高い正答率を達成し、既存モデルを上回る性能を示した。 Comment

論文の本題とは関係ないが、QwQ-32Bよりも、DeepSeek-R1-Distilled-Qwen32Bの方が性能が良いのは興味深い。やはり大きいパラメータから蒸留したモデルの方が、小さいパラメータに追加学習したモデルよりも性能が高い傾向にあるのだろうか（どういうデータで蒸留したかにもよるけど）。
image

OpenReview: https://openreview.net/forum?id=m80LCW765n




Paper/Blog Link My Issue
#NLP #LanguageModel #Distillation #ICML #TeacherHacking Issue Date: 2025-02-10 GPT Summary- LMのポストトレーニングは、知識蒸留とRLHFに依存し、報酬ハッキングの課題を指摘。教師LMからの「教師ハッキング」が存在することを検証。実験では、固定オフラインデータで教師ハッキングが発生し、多項式収束法則から逸脱することを観測。オンラインデータ生成技術がハッキングを緩和できることを示し、データの多様性が重要な要因であると結論。これにより、LM構築の蒸留の利点と限界が明らかに。 Comment

元ポスト:

Loading…

自分で蒸留する機会は今のところないが、覚えておきたい。過学習と一緒で、こういう現象が起こるのは想像できる。

openreview: https://openreview.net/forum?id=qxSFIigPug¬eId=CAgFzoMVit




Paper/Blog Link My Issue
#EfficiencyImprovement #NLP #Library #Transformer #pretrained-LM #ACL #Selected Papers/Blogs #One-Line Notes Issue Date: 2024-12-20 GPT Summary- ModernBERTはエンコーダーのみのトランスフォーマーモデルで、BERTに対する大きなパレート改善を達成。2兆トークンで訓練され、長いシーケンスに対応しながら、分類タスクと検索において最先端の性能を示す。さらに、最も高速かつメモリ効率の良いエンコーダーとして設計されている。 Comment

最近の進化しまくったTransformer関連のアーキテクチャをEncodnr-OnlyモデルであるBERTに取り込んだら性能上がるし、BERTの方がコスパが良いタスクはたくさんあるよ、系の話、かつその実装だと思われる。
テクニカルペーパー中に記載はないが、評価データと同じタスクでのDecoder-Onlyモデル（SFT有り無し両方）との性能を比較したらどの程度の性能なのだろうか？

そもそも学習データが手元にあって、BERTをFinetuningするだけで十分な性能が出るのなら（BERTはGPU使うのでそもそもxgboostとかでも良いが）、わざわざLLM使う必要ないと思われる。BERTのFinetuningはそこまで時間はかからないし、inferenceも速い。

参考:
- [Paper Note] Prompt2Model: Generating Deployable Models from Natural Language Instructions, Vijay Viswanathan+, arXiv'23, 2023.08

日本語解説: https://zenn.dev/dev_commune/articles/3f5ab431abdea1?utm_source=substack&utm_medium=email




Paper/Blog Link My Issue
#NLP #LanguageModel #Reasoning #SelfImprovement #read-later Issue Date: 2024-12-16 GPT Summary- OpenAI o1がLRMの研究に注力し、伝統的な分野だけでなくRLやオープンエンドな解決にも焦点を当てる。特に、基準が不明瞭な領域への一般化の可能性を探求。Marco-o1はCoT微調整やMCTS、リフレクション機構などの手法を用いて、複雑な実世界の問題解決に最適化されている。 Comment

元ポスト:

Loading…

Large Reasoning Model （LRM）という用語は初めて見た。

日本語解説: https://www.docswell.com/s/DeepLearning2023/KV1M9P-2024-12-05-125148




Paper/Blog Link My Issue
#Multi #NLP #Dataset #LanguageModel #Evaluation #Factuality #Reasoning #ACL Issue Date: 2024-12-02 GPT Summary- 大規模言語モデル（LLMs）のマルチホップクエリに対する事実の想起能力を評価。ショートカットを防ぐため、主語と答えが共に出現するテストクエリを除外した評価データセットSOCRATESを構築。LLMsは特定のクエリにおいてショートカットを利用せずに潜在的な推論能力を示し、国を中間答えとするクエリでは80%の構成可能性を達成する一方、年の想起は5%に低下。潜在的推論能力と明示的推論能力の間に大きなギャップが存在することが明らかに。 Comment

SNLP'24での解説スライド:
https://docs.google.com/presentation/d/1Q_UzOzn0qYX1gq_4FC4YGXK8okd5pwEHaLzVCzp3yWg/edit?usp=drivesdk

この研究を信じるのであれば、LLMはCoT無しではマルチホップ推論を実施することはあまりできていなさそう、という感じだと思うのだがどうなんだろうか。




Paper/Blog Link My Issue
#Analysis #NLP #LanguageModel #Prompting Issue Date: 2024-11-27 GPT Summary- プロンプト最適化はLLMの性能に重要であり、異なるプロンプトテンプレートがモデルの性能に与える影響を調査。実験では、GPT-3.5-turboがプロンプトテンプレートによってコード翻訳タスクで最大40%変動する一方、GPT-4はより堅牢であることが示された。これにより、固定プロンプトテンプレートの再考が必要であることが強調された。 Comment

（以下、個人の感想です）
本文のみ斜め読みして、Appendixは眺めただけなので的外れなことを言っていたらすみません。

まず、実務上下記知見は有用だと思いました:
- プロンプトのフォーマットによって性能に大きな差がある
- より大きいモデルの方がプロンプトフォーマットに対してロバスト

ただし、フォーマットによって性能差があるというのは経験的にある程度LLMを触っている人なら分かることだと思うので、驚きは少なかった。

個人的に気になる点は、学習データもモデルのアーキテクチャもパラメータ数も分からないGPT3.5, GPT4のみで実験をして「パラメータサイズが大きい方がロバスト」と結論づけている点と、もう少し深掘りして考察したらもっとおもしろいのにな、と感じる点です。

実務上は有益な知見だとして、では研究として見たときに「なぜそうなるのか?」というところを追求して欲しいなぁ、という感想を持ちました。
たとえば、「パラメータサイズが大きいモデルの方がフォーマットにロバスト」と論文中に書かれているように見えますが、
それは本当にパラメータサイズによるものなのか？学習データに含まれる各フォーマットの割合とか（これは事実はOpenAIの中の人しか分からないので、学習データの情報がある程度オープンになっているOpenLLMでも検証するとか）、評価するタスクとフォーマットの相性とか、色々と考察できる要素があるのではないかと思いました。
その上で、大部分のLLMで普遍的な知見を見出した方が研究としてより面白くなるのではないか、と感じました。

image
image

参考: Data2Textにおける数値データのinput formatによる性能差を分析し考察している研究
- [Paper Note] Prompting for Numerical Sequences: A Case Study on Market Comment Generation, Masayuki Kawarada+, arXiv'24, 2024.04




Paper/Blog Link My Issue
#Analysis #InformationRetrieval #NLP #LanguageModel #RAG(RetrievalAugmentedGeneration) #One-Line Notes Issue Date: 2024-11-19 GPT Summary- 大規模言語モデルを用いた情報検索強化生成は、文脈内の文書の順序に影響を受けやすい。研究では、質問の確率がモデルのパフォーマンスに与える影響を分析し、正確性との相関関係を明らかにした。質問の確率を指標として、プロンプトの選択と構築に関する2つの方法を提案し、その効果を実証。確率に基づく手法は効率的で、少ないモデルのパスで応答を生成できるため、プロンプト最適化の新たな方向性を示す。 Comment

トークンレベルの平均値をとった生成テキストの対数尤度と、RAGの回答性能に関する分析をした模様。
image

とりあえず、もし「LLMとしてGPTを（OpenAIのAPIを用いて）使いました！temperatureは0です！」みたいな実験設定だったら諸々怪しくなる気がしたのでそこが大丈夫なことを確認した（OpenLLM、かつdeterministicなデコーディング方法が望ましい）。おもしろそう。

image

参考: [RAGのハルシネーションを尤度で防ぐ, sasakuna, 2024.11.19]( https://zenn.dev/knowledgesense/articles/7c47e1796e96c0)

## 参考

生成されたテキストの尤度を用いて、どの程度正解らしいかを判断する、といった話は
- [Paper Note] G-Eval: NLG Evaluation using GPT-4 with Better Human Alignment, Yang Liu+, N/A, EMNLP'23


のようなLLM-as-a-Judgeでも行われている。

G-Evalでは1--5のスコアのような離散的な値を生成する際に、これらを連続的なスコアに補正するために、尤度（トークンの生成確率）を用いている。
ただし、G-Evalの場合は実験でGPTを用いているため、モデルから直接尤度を取得できず、代わりにtemperature1とし、20回程度生成を行った結果からスコアトークンの生成確率を擬似的に計算している。

G-Evalの設定と比較すると（当時はつよつよなOpenLLMがなかったため苦肉の策だったと思われるが）、こちらの研究の実験設定の方が望ましいと思う。




Paper/Blog Link My Issue
#Survey #EfficiencyImprovement #NLP #LanguageModel #Transformer #Attention #One-Line Notes Issue Date: 2024-11-17 GPT Summary- ChatGPTの導入により、LLMsの低コストな訓練とデプロイメントへの関心が高まる。本論文では、訓練技術や推論デプロイメント技術の進化を概説し、データ前処理やモデル圧縮など多様な視点を提供。LLMsの活用についても考察し、今後の発展を示唆する。 Comment

[Perplexity（参考;Hallucinationに注意）]( https://www.perplexity.ai/search/yi-xia-nolun-wen-wodu-minei-ro-7vGwDK_AQX.HDO7j9H8iNA)

単なるLLMの理論的な説明にとどまらず、実用的に必要な各種並列処理技術、Mixed Precision、Offloadingなどのテクニックもまとまっているのがとても良いと思う。

LLM Frameworkのところに、メジャーなものが網羅されていないように感じる。たとえば、UnslothやLiger-KernelなどはTransformersの部分で言及されてても良いのでは、と感じる。




Paper/Blog Link My Issue
#NLP #LanguageModel #NumericReasoning #ICLR #numeric #In-Depth Notes Issue Date: 2024-11-09 GPT Summary- 大規模言語モデル（LLM）の数値理解・処理能力（NUPA）を調査し、41の数値タスクを含むベンチマークを導入。これにより、LLMsが多くのタスクで頻繁に失敗することが判明。NUPA向上のため、小型モデルを訓練し、ファインチューニングの効果を評価。1) ファインチューニングが多くのタスクでNUPAを向上させるが、全てに効果的ではない。2) 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の数値演算能力は人間の暗算のように限界があることを認知し、金融分野などの正確な演算や数値の取り扱うようなタスクをさせたかったら、適切なツールを使わせましょうね、という話なのかなあと思う。

image

元ポスト:

Loading…

ICLR25の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が数値を解釈できないと困ると思う。そういった説明が入った方が良いと思うなあ、感。




Paper/Blog Link My Issue
#Pretraining #Tools #NLP #LanguageModel #Supervised-FineTuning (SFT) #AIAgents #ICLR #PostTraining #KeyPoint Notes Issue Date: 2024-10-20 GPT Summary- ToolGenは、LLMとツールの統合を革新する新しいアプローチを提案する。ツールをユニークなトークンとして表現し、ツール知識を直接LLMのパラメータに組み込むことで、ツール呼び出しと生成をシームレスに実現する。このフレームワークにより、追加ステップなしで多数のツールにアクセスでき、性能とスケーラビリティが向上する。47,000以上のツールでの実験結果は、ToolGenが自律的なタスク完遂において優れた成果を示し、多様な領域に適応可能なAIエージェントの新時代を切り開くことを示唆している。さらに、エンドツーエンドのツール学習を可能にし、他の高度な技術との統合機会を提供することで、LLMsの実践的な能力を拡張する。 Comment

昔からよくある特殊トークンを埋め込んで、特殊トークンを生成したらそれに応じた処理をする系の研究。今回はツールに対応するトークンを仕込む模様。

斜め読みだが、3つのstepでFoundation Modelを訓練する。まずはツールのdescriptionからツールトークンを生成する。これにより、モデルにツールの情報を覚えさせる（memorization）。斜め読みなので読めていないが、ツールトークンをvocabに追加してるのでここは継続的事前学習をしているかもしれない。続いて、（おそらく）人手でアノテーションされたクエリ-必要なツールのペアデータから、クエリに対して必要なツールを生成するタスクを学習させる。最後に、（おそらく人手で作成された）クエリ-タスクを解くためのtrajectoryペアのデータで学習させる。
image
image

学習データのサンプル。Appendix中に記載されているものだが、本文のデータセット節とAppendixの双方に、データの作り方の詳細は記述されていなかった。どこかに書いてあるのだろうか。
imageimage

最終的な性能
image

特殊トークンを追加のvocabとして登録し、そのトークンを生成できるようなデータで学習し、vocabに応じて何らかの操作を実行するという枠組み、その学習手法は色々なタスクで役立ちそう。

openreview: https://openreview.net/forum?id=XLMAMmowdY




Paper/Blog Link My Issue
#NLP #LanguageModel #QuestionAnswering #Prompting #EMNLP #KeyPoint Notes Issue Date: 2023-10-30 GPT Summary- Re2は、質問を再読することでLLMの推論能力を高める簡潔かつ効果的なプロンプティング手法です。これは、入力を二度処理することにより理解を深め、CoTなどの思考誘発型手法とも互換性があります。Re2は単方向デコーダーのLLMに対しても双方向エンコーディングを促進し、広範な推論ベンチマークでその有効性を示しました。結果として、Re2は単純な再読戦略を通じてLLMの推論性能を一貫して向上させることが示され、異なるモデルや手法と効果的に統合可能です。 Comment

問題文を2,3回promptで繰り返すだけで、数学のベンチマークとCommonsenseのベンチマークの性能が向上したという非常に簡単なPrompting。self-consistencyなどの他のPromptingとの併用も可能。
なぜ性能が向上するかというと、
1. LLMはAuporegressiveなモデルであり、bidirectionalなモデルではない。このため、forwardパスのみでは読解力に限界がある。（たとえば人間はしばしばテキストを読み返したりする）。そこで、一度目の読解で概要を理解し、二度目の読解でsalience partを読み込むといったような挙動を実現することで、より問題文に対するComprehensionが向上する。
2. LLMはしばしばpromptの重要な箇所の読解を欠落させてしまう。たとえば、[Paper Note] Lost in the Middle: How Language Models Use Long Contexts, Nelson F. Liu+, arXiv'23, 2023.07 では、promptのmiddle partを軽視する傾向があることが示されている。このような現象も軽減できると考えられる。

image
image
image
問題文の繰り返しは、3回までは性能が向上する。
image

このpromptingは複雑な問題であればあるほど効果があると推察される。

本手法はReasoningモデル登場依然のものであり、おそらくReasoningモデルではReasoning tokenの生成を通じて動的にcontextにattentionを貼る（つまり必要な箇所は自然にre-readingされる）ため、re-readingと同等以上の効果を得ていることが推察される。
このため、直感的にはこの手法はnon-thinkingモデルに対しては依然として有効な場合はあるかもしれないが、Reasoningモデルにおいては非推奨だと個人的には考える。




Paper/Blog Link My Issue
#MachineLearning #NLP #LanguageModel #AutomaticPromptEngineering #ICLR #Selected Papers/Blogs #KeyPoint Notes Issue Date: 2023-09-09 GPT Summary- 最適化タスクを自然言語で記述するアプローチ、Optimization by PROmpting（OPRO）を提案。大規模言語モデル（LLMs）を用いて以前の解を基に新しい解を生成し、プロンプトに追加。線形回帰や巡回セールスマン問題での実証に続き、プロンプト最適化を行い、タスク精度を最大化。OPROで最適化されたプロンプトは、人間設計のものをGSM8Kで最大8%、Big-Bench Hardで最大50%上回ることを確認。 Comment

`Take a deep breath and work on this problem step-by-step. `論文



# 概要

LLMを利用して最適化問題を解くためのフレームワークを提案したという話。論文中では、linear regressionや巡回セールスマン問題に適用している。また、応用例としてPrompt Engineeringに利用している。

これにより、Prompt Engineeringが最適か問題に落とし込まれ、自動的なprompt engineeringによって、`Let's think step by step.` よりも良いプロンプトが見つかりましたという話。

image



# 手法概要

全体としての枠組み。meta-promptをinputとし、LLMがobjective functionに対するsolutionを生成する。生成されたsolutionとスコアがmeta-promptに代入され、次のoptimizationが走る。これを繰り返す。

image

Meta promptの例

image

openreview: https://openreview.net/forum?id=Bb4VGOWELI

テキスト空間上で過去の履歴とスコアが与えられ、それをgivenにスコアが良くなりそうなものをLLMがiterativeに生成していくことが可能なことが示されたのが興味深い




Paper/Blog Link My Issue
#Analysis #MachineLearning #NLP #LanguageModel #In-ContextLearning #ICLR Issue Date: 2023-09-01 GPT Summary- 最近の研究では、トランスフォーマーベースのインコンテキスト学習において、プレフィックス言語モデル（prefixLM）が因果言語モデル（causalLM）よりも優れたパフォーマンスを示すことがわかっています。本研究では、理論的なアプローチを用いて、prefixLMとcausalLMの収束挙動を分析しました。その結果、prefixLMは線形回帰の最適解に収束する一方、causalLMの収束ダイナミクスはオンライン勾配降下アルゴリズムに従い、最適であるとは限らないことがわかりました。さらに、合成実験と実際のタスクにおいても、causalLMがprefixLMよりも性能が劣ることが確認されました。 Comment

参考:

Loading…

CausalLMでICLをした場合は、ICL中のdemonstrationでオンライン学習することに相当し、最適解に収束しているとは限らない……？が、hillbigさんの感想に基づくと、結果的には実は最適解に収束しているのでは？という話も出ているし、よく分からない。




Paper/Blog Link My Issue
#NLP #LanguageModel #Chain-of-Thought #NumericReasoning #Mathematics #KeyPoint Notes Issue Date: 2023-07-11 GPT Summary- 小型トランスフォーマーが次語予測を用いて基本的な算術演算（加算、乗算、平方根）を学習できるかを調査。従来のデータが効果的でないことを示し、形式変更で精度が向上することを確認。Chain-of-Thoughtスタイルのデータで訓練することで、事前訓練なしでも精度と収束速度を改善。算術データとテキストデータの相互作用や少数ショット promptingの影響を考察し、高品質なデータの重要性を強調。 Comment

小規模なtransformerに算術演算を学習させ、どのような学習データが効果的か調査。CoTスタイルの詳細なスクラッチパッドを学習データにすることで、plainなもの等と比較して、予測性能や収束速度などが劇的に改善した

image

結局next token predictionで学習させているみたいだけど、本当にそれで算術演算をモデルが理解しているのだろうか?という疑問がいつもある

↑この3年前の感想は、現在は良質なreasoning trajectioryを用いたSFTにってreasoning能力が強化できることを考えると一部解決されている。少なくとも、next token predictionによって（汎化性能は置いておいて）特定分野でのreasoning能力を身につけさせることができることは分かっているため、真に"理解"しているかはわからないが、少なくともモデル自身の能力で思考し問題を解けることは実験的に示されている。

事前学習によって知識を学習し、中間学習や事後学習で知識の使い方や特定の能力を現在では伸ばしているが、この研究だはスクラッチパッドを用いた事前学習データを使っているようなので、数学の解き方の知識と使い方を同時に学習できていると考えられる。

（3年前の感想を今見返すとおもしろいな）

openreview: https://openreview.net/forum?id=dsUB4bst9S




Paper/Blog Link My Issue
#MachineTranslation #NLP #LanguageModel #One-Line Notes Issue Date: 2024-11-20 GPT Summary- プロンプト設計は多くのタスクで優れた性能を示すが、機械翻訳においては未検討。翻訳のためのプロンプト戦略を体系的に研究し、プロンプトテンプレートやデモ例の選択に関する要因を検討。実験の結果、プロンプト例の数と質が翻訳において重要であり、サブ最適な例は性能低下を招くことが示された。また、ゼロショットプロンプティングから得られた擬似平行プロンプト例の利用が翻訳を改善する可能性や、知識転移により性能向上が見込まれることが確認された。最後に、プロンプト設計に関する問題点についても議論。 Comment

zero-shotでMTを行うときに、改行の有無や、少しのpromptingの違いでCOMETスコアが大幅に変わることを示している。

モデルはGLM-130BをINT4で量子化したモデルで実験している。

興味深いが、この知見を一般化して全てのLLMに適用できるか？と言われると、そうはならない気がする。他のモデルで検証したら傾向はおそらく変わるであろう（という意味でおそらく論文のタイトルにもCase Studyと記述されているのかなあ）。



image




Paper/Blog Link My Issue
#NLP #LanguageModel #Supervised-FineTuning (SFT) #Chain-of-Thought #SmallModel #OpenWeight Issue Date: 2023-11-21 GPT Summary- Orca 2 は小型 LM の推論能力を高めるために、異なるタスクごとに様々な解法戦略を学習させることを目指す。段階的推論や思い出し-推論-生成などを用いて、小型モデルの潜在能力を最大化し、約100のタスクで評価を行い、同規模モデルを大きく上回る性能を達成。重みは公開され、開発研究の支援が期待される。 Comment

ポイント解説:

Loading…

HF: https://huggingface.co/microsoft/Orca-2-13b

論文を読むとChatGPTのデータを学習に利用しているが、現在は競合となるモデルを作ることは規約で禁止されているので注意




Paper/Blog Link My Issue
#Analysis #NLP #LanguageModel #Transformer #OOD #One-Line Notes Issue Date: 2023-11-06 GPT Summary- 本研究では、トランスフォーマーモデルの文脈学習（ICL）能力を調査しました。トランスフォーマーモデルは、事前学習データの範囲内で異なるタスクを特定し、学習する能力を持っています。しかし、事前学習データの範囲外のタスクや関数に対しては一般化が劣化することが示されました。また、高容量のシーケンスモデルのICL能力は、事前学習データの範囲に密接に関連していることが強調されました。 Comment

Transformerがpre-training時に利用された学習データ以外の分布に対しては汎化性能が落ちることを示したらしい。もしこれが正しいとすると、結局真に新しい分布というか関数というかタスクというか、をTransformerが創出する可能性は低いと言えるかもしれない。が、新しいものって大体は既存の概念の組み合わせだよね（スマホとか）、みたいなことを考えると、別にそれでも十分では？と思ってしまう。人間が本当に真の意味で新しい関数というかタスクというか分布を生み出せているかというと、実はそんなに多くないのでは？という予感もする。まあたとえば、量子力学を最初に考えました！とかそういうのは例外だと思うけど・・・、そのレベルのことってどんくらいあるんだろうね？




Paper/Blog Link My Issue
#NLP #LanguageModel #Evaluation #Factuality #RAG(RetrievalAugmentedGeneration) #One-Line Notes Issue Date: 2023-11-05 GPT Summary- 自動ファクトチェックは機械学習を用いて主張を検証する重要な取り組みであり、LLMs（例：GPT-4）はその能力を活用しつつ、情報の真偽を見分ける役割が増大している。本研究ではLLMエージェントがクエリを作成し、文脈データを取得し、意思決定を行うフレームワークを提案。結果、文脈情報がLLMの能力を向上させることが示されたが、正確性はクエリの言語や主張の真偽に依存し、一貫性に欠けるため慎重な運用が求められる。さらなる研究が必要で、エージェントの成功と失敗のメカニズムを探求することが提言される。 Comment

gpt3とgpt4でFactCheckして傾向を分析しました、という研究。promptにstatementとgoogleで補完したcontextを含め、出力フォーマットを指定することでFactCheckする。
promptingする際の言語や、statementの事実性の度合い（半分true, 全てfalse等）などで、性能が大きく変わる結果とのこと。
性能を見ると、まだまだ（このprompting方法では）人間の代わりが務まるほどの性能が出ていないことがわかる。また、trueな情報のFactCheckにcontextは効いていそうだが、falseの情報のFactCheckにContextがあまり効いてなさそうに見えるので、なんだかなあ、という感じである。

image
image

斜め読みしかしていないがこの研究、学術的な知見は少ないのかな、という印象。一つのケーススタディだよね、という感じがする。

まず、GPT3,4だけじゃなく、特徴の異なるOpenSourceのLLMを比較に含めてくれないと、前者は何で学習しているか分からないので、学術的に得られる知見はほぼないのではという気が。実務的には役に立つが。

その上で、Promptingをもっとさまざまな方法で検証した方が良いと思う。
たとえば、現在のpromptではラベルを先に出力させた後に理由を述べさせているが、それを逆にしたらどうなるか？（zero-shot CoT）や、4-Shotにしたらどうなるか、SelfConsistencyを利用したらどうなるかなど、promptingの仕方によって傾向が大きく変わると思う。

加えて、Retriever部分もいくつかのバリエーションで試してみても良いのかなと思う。特に、falseの情報を判断する際に役に立つ情報がcontextに含められているのかが気になる。
論文に書いてあるかもしれないが、ちょっとしっかり読む時間はないです！！




Paper/Blog Link My Issue
#Pretraining #NLP #LanguageModel #FoundationModel #Mathematics #mid-training #One-Line Notes Issue Date: 2023-10-29 GPT Summary- Llemmaという数学の大規模言語モデルを提案。Proof-Pile-2でCode Llamaの前訓練を行い、科学論文や数学コードを含む複合データセットで強化。MATHベンチマークで全ての公開モデルを凌ぎ、未公開のMinervaモデル群にも勝利。追加ファインチューニングなしでツール使用や形式的定理証明が可能。70億および340億パラメータのモデルや実験コードを公開。 Comment

CodeLLaMAを200B tokenの数学テキスト（proof-pile-2データ;論文、数学を含むウェブテキスト、数学のコードが含まれるデータ）で継続的に事前学習することでfoundation modelを構築
image

約半分のパラメータ数で数学に関する性能でGoogleのMinervaと同等の性能を達成
image

元ツイート:

Loading…

まだ4-shotしてもAcc.50%くらいなのか。




Paper/Blog Link My Issue
#ComputerVision #NLP #LanguageModel #MultiModal #EMNLP #OCR #One-Line Notes Issue Date: 2023-10-26 GPT Summary- GPT-4VのOCR機能を評価し、シーンテキスト、手書き文字、数学式や表構造認識などの幅広いタスクへの性能を検討。ラテン文字では高性能だが、多言語や複雑なタスクでは限界を示す。専門的なOCRモデルの必要性を強調し、今後の研究の指針を提供。評価結果は公開されている。 Comment

GPT4-VをさまざまなOCRタスク「手書き、数式、テーブル構造認識等を含む）で性能検証した研究。
MLT19データセットを使った評価では、日本語の性能は非常に低く、英語とフランス語が性能高い。手書き文字認識では英語と中国語でのみ評価。
image

現在では非常に性能が向上していると考えられるが、初期VLMのOCR性能を示している文献として興味深い。




Paper/Blog Link My Issue
#MachineLearning #Regularization #NeurIPS Issue Date: 2023-10-11 GPT Summary- 重み減衰は深層ネットワークの訓練に広く用いられるが、その役割は十分に理解されていない。本研究では、重み減衰が視覚タスクの深層ネットワークにおいて最適化ダイナミクスを修正し、損失安定化を通じて暗黙の正則化を強化することを示す。また、大規模言語モデルでは、重み減衰がトレードオフをバランスさせ、訓練安定性を改善することを説明。重み減衰は明示的な正則化としては有用でなく、訓練ダイナミクスを変える役割を果たすことを提案した。 Comment

参考:

Loading…

WeightDecayは目的関数に普通にL2正則化項を加えることによって実現されるが、深掘りするとこんな効果があるのね

openreview (ICLR'24) : https://openreview.net/forum?id=RKh7DI23tz

openreview (NeurIPS'24): https://openreview.net/forum?id=YrAxxscKM2&referrer=%5Bthe%20profile%20of%20Aditya%20Varre%5D(%2Fprofile%3Fid%3D~Aditya_Varre1)




Paper/Blog Link My Issue
#NLP #LanguageModel #Prompting #AutomaticPromptEngineering #ICML Issue Date: 2023-10-09 GPT Summary- Promptbreederは、LLMの推論能力を向上させる自己改善メカニズムであり、特定のドメインに対してプロンプトを進化・適応させる。タスクプロンプトの集団を突然変異させ、訓練データで評価することで、LLMが生成・改善する変異プロンプトによって統治される。これにより、Chain-of-ThoughtやPlan-and-Solve Promptingを上回り、ヘイトスピーチ分類のような複雑なタスクにも対応可能なプロンプトを進化させる。 Comment

詳細な解説記事: https://aiboom.net/archives/56319

APEとは異なり、GAを使う。突然変異によって、予期せぬ良いpromptが生み出されるかも…？




Paper/Blog Link My Issue
#NLP #LanguageModel #Chain-of-Thought #Prompting #In-ContextLearning #ICLR #KeyPoint Notes Issue Date: 2023-10-07 GPT Summary- アナロジー的プロンプティングを用いて、言語モデルに問題解決前に関連する例示を生成させる新手法を提案。ラベリング不要で汎用性が高く、適応性もある。実験では、GSM8K、MATH、Codeforces、BIG-Benchの推論タスクで0ショットおよび少数ショットCoTを上回る性能を示した。 Comment

以下、著者ツイートのざっくり翻訳:

Loading…


人間は新しい問題に取り組む時、過去に解いた類義の問題を振り返り、その経験を活用する。これをLLM上で実践できないか?というのがアイデア。
Analogical Promptingでは、問題を解く前に、適切なexamplarを自動生成（problemとsolution）させ、コンテキストとして利用する。

これにより、examplarは自己生成されるため、既存のCoTで必要なexamplarのラベリングや検索が不要となることと、解こうとしている問題に合わせてexamplarを調整し、推論に対してガイダンスを提供することが可能となる。

実験の結果、数学、コード生成、BIG-Benchでzero-shot CoT、few-shot CoTを上回った。

image
image

LLMが知っており、かつ得意な問題に対してならうまく働きそう。一方で、LLMが苦手な問題などは人手作成したexamplarでfew-shotした方が（ある程度）うまくいきそうな予感がする。うまくいきそうと言っても、そもそもLLMが苦手な問題なのでfew-shotした程度では焼石に水だとは思うが。

openreview: https://openreview.net/forum?id=AgDICX1h50




Paper/Blog Link My Issue
#NLP #LanguageModel #Evaluation #Bias #NAACL #read-later #Selected Papers/Blogs #Findings #One-Line Notes #needs-revision Issue Date: 2023-08-28 GPT Summary- 多肢選択問題におけるLLMsの性能は選択肢の順序に敏感であり、配置を変えることで最大75%の性能差が見られる。特に、上位選択肢間の不確実性がこの感度を引き起こし、バイアスが影響することを示唆する。最適な配置は、バイアスを増幅させるためにトップ選択肢を両端に置くこと、緩和するためには隣接させることが推奨される。実験を通じて、予測のキャリブレーションにより最大8ポイントの改善が達成された。 Comment

これはそうだろうなと思っていたけど、ここまで性能に差が出るとは思わなかった。
image

これがもしLLMのバイアスによるもの（2番目の選択肢に正解が多い）の場合、
ランダムにソートしたり、平均取ったりしても、そもそもの正解に常にバイアスがかかっているので、
結局バイアスがかかった結果しか出ないのでは、と思ってしまう。
そうなると、有効なのはone vs. restみたいに、全部該当選択肢に対してyes/noで答えさせてそれを集約させる、みたいなアプローチの方が良いかもしれない。




Paper/Blog Link My Issue
#NLP #ChatGPT #Evaluation Issue Date: 2023-07-22 GPT Summary- GPT-3.5とGPT-4の2023年版を、数学、敏感な質問、意見調査、知識集約型質問、コード生成、医師免許試験、視覚推論のタスクで評価した結果、両者の性能が時間とともに大きく変化することが明らかになった。特に、GPT-4（3月版）が素数識別では84%の正答率を示したが、6月版では51%に低下。GPT-3.5は6月にこのタスクで向上し、GPT-4は敏感な質問への回答意欲が減少した。全体として、LLMの挙動は短期間で変化し得るため、継続的な監視が必要であることを示唆している。 Comment

GPT3.5, GPT4共にfreezeされてないのなら、研究で利用すると結果が再現されないので、研究で使うべきではない。

↑(2025.10追記)
当時の私はこのように感じたようだが、以下を確認した方が良いと思う:

- 実験設定として、エンドポイントのモデル名にはタイムスタンプが付与されているが、同じモデルシリーズの異なるタイムスタンプモデル間の比較なのか、それとも全く同じタイムスタンプのモデルでの比較なのか
- サンプリングパラメータの設定や推論の試行回数なとがreliableな比較ができうる設定になっているか。

あとは上記を確認したとしても、研究で使うべきではない、は言い過ぎで、実験の比較対象の一部として使う分には良いと思う（ただし、実験結果の主要な知見は再現可能な設定から得られるべきと考える。

（当時は随分脊髄反射的にコメントを書いていますね…）




Paper/Blog Link My Issue
#MachineLearning #LanguageModel #In-ContextLearning #NeurIPS #needs-revision Issue Date: 2023-07-11 GPT Summary- トランスフォーマーが勾配降下法を実装できるかを探る研究。線形トランスフォーマーを線形回帰のランダムインスタンスで訓練し、単一アテンション層が前条件化勾配降下法の反復を実装することを理論的に示す。$L$層のトランスフォーマーは、特定の臨界点で$L$回の反復を実行。結果は、トランスフォーマーを学習アルゴリズムとして訓練する新たな理論研究を促進する。 Comment

参考:

Loading…

つまり、事前学習の段階でIn context learningが可能なように学習がなされているということなのか。
それはどのような学習かというと、プロンプトとそれによって与えられた事例を前条件とした場合の勾配降下法によって実現されていると。

つまりどういうことかというと、プロンプトと与えられた事例ごとに、それぞれ最適なパラメータが学習されているというイメージだろうか。条件付き分布みたいなもの？

なので、未知のプロンプトと事例が与えられたときに、事前学習時に前条件として与えられているものの中で類似したものがあれば、良い感じに汎化してうまく生成ができる、ということかな？

いや違うな。1つのアテンション層が勾配降下法の1ステップをシミュレーションしており、k個のアテンション層があったらkステップの勾配降下法をシミュレーションしていることと同じ結果になるということ?
そしてその購買降下法では、プロンプトによって与えられた事例が最小となるように学習される（シミュレーションされる）ということなのか。

つまり、ネットワーク上で本当に与えられた事例に基づいて学習している（のと等価な結果）を得ているということなのか？😱

openreview: https://openreview.net/forum?id=LziniAXEI9




Paper/Blog Link My Issue
#NLP #LanguageModel #Alignment #Supervised-FineTuning (SFT) #DataDistillation #NeurIPS #KeyPoint Notes #needs-revision Issue Date: 2023-05-22 GPT Summary- LIMAは65BパラメータのLLaMaモデルで、1,000件の慎重に選定されたプロンプトで微調整された。モデルは汎用表現を学び、未知のタスクに対しても良好に一般化。人間評価では、LIMAの性能がGPT-4より43%、Bardより58%、DaVinci003より65%優れていることが示され、事前学習が知識の大半を構築する重要性を強調している。 Comment

LLaMA65Bをたった1kのdata point（厳選された物）でRLHF無しでfinetuningすると、旅行プランの作成や、歴史改変の推測（？）幅広いタスクで高いパフォーマンスを示し、未知のタスクへの汎化能力も示した。最終的にGPT3,4,BARD,CLAUDEよりも人間が好む回答を返した。

image

LLaMAのようなオープンでパラメータ数が少ないモデルに対して、少量のサンプルでfinetuningするとGPT4に迫れるというのはgamechangerになる可能性がある

openreview: https://openreview.net/forum?id=KBMOKmX2he




Paper/Blog Link My Issue
#NLP #Explanation #ChatGPT #InformationExtraction #Evaluation #KeyPoint Notes Issue Date: 2023-04-25 GPT Summary- 本研究では、ChatGPTの能力を7つの情報抽出（IE）タスクを通じて評価し、パフォーマンス、説明可能性、キャリブレーション、信頼性を分析しました。標準IE設定ではパフォーマンスが低い一方、オープンIE設定では人間評価で優れた結果を示しました。ChatGPTは高品質な説明を提供するものの、予測に対して過信する傾向があり、キャリブレーションが低いことが明らかになりました。また、元のテキストに対して高い信頼性を示しました。研究のために手動で注釈付けした7つのIEタスクのテストセットと14のデータセットを公開しています。 Comment

情報抽出タスクにおいてChatGPTを評価した研究。スタンダードなIEの設定ではBERTベースのモデルに負けるが、OpenIEの場合は高い性能を示した。
また、ChatGPTは予測に対してクオリティが高く信頼に足る説明をしたが、一方で自信過剰な傾向がある。また、ChatGPTの予測はinput textに対して高いfaithfulnessを示しており、予測がinputから根ざしているものであることがわかる。（らしい）

あまりしっかり読めていないが、Entity Typing, NER, Relation Classification, Relation Extraction, Event Detection, Event Argument Extraction, Event Extractionで評価。standardIEでは、ChatGPTにタスクの説明と選択肢を与え、与えられた選択肢の中から正解を探す設定とした。一方OpenIEでは、選択肢を与えず、純粋にタスクの説明のみで予測を実施させた。OpenIEの結果を、3名のドメインエキスパートが出力が妥当か否か判定した結果、非常に高い性能を示すことがわかった。表を見ると、同じタスクでもstandardIEよりも高い性能を示している（そんなことある？？？）

つまり、選択肢を与えてどれが正解ですか?ときくより、選択肢与えないでCoTさせた方が性能高いってこと？比較可能な設定で実験できているのだろうか。promptは付録に載っているが、output exampleが載ってないのでなんともいえない。StandardIEの設定をしたときに、CoTさせてるかどうかが気になる。もししてないなら、そりゃ性能低いだろうね、という気がする。




Paper/Blog Link My Issue
#AdaptiveLearning #EducationalDataMining #KnowledgeTracing #Surface-level Notes #ICCE Issue Date: 2022-08-29 Comment

# 概要

ざっくりとしか読めていないが

- DeepLearningBasedなKT手法は、latentな学習者の知識を推定しているわけではなく、「正誤」を予測しているだけであることを指摘

- → 一方BKTはきちんとlatent knowledgeがモデリングされている

- → 昔はknowledge inferenceした結果を、post-testで測定したスキルのmasteryとしっかり比較する文化があったが、近年のDeepLearningベースな研究では全く実施されていないことも指摘

- → learning systemの中でどのようなパフォーマンスが発揮されるかではなく、learning systemの外でどれだけスキルが発揮できるか、というところにBKTなどの時代は強い焦点が置かれていたのだと思われる

- DeepLearningBasedなKT手法でもknowledgeのinferenceが行える手法を提案し、BKTやPFAによるknowledge estimateよりもposttestのスコアと高い相関を示すことを実験した

- → 手法: それぞれの問題のfirst attemptに対する正誤データの「全て」をtraining dataとし、DKT, DKVMN, BKT, PFAを学習。

　-（おそらく）学習したモデルを用いてある生徒AのスキルBのknowledgeをinferenceしたい場合、生徒Aが回答したスキルBと紐づいた問題に対する平均正答率を推定した習熟度とした

　- 生徒Aはtraining dataに含まれている生徒

- すなわち、生徒Aにとって未知の問題の正答率を予測しているわけではなく、モデルがパラメータを推定するために利用した既知の問題-回答ペアデータに対して、モデルがパラメータをfittingした後にinferenceできる正答率の平均値を習熟度としている



# 結果

- 4種類のスキルに対するpost-testのスコアと相関係数をモデルごとに比較した結果、DKT, DKVMNなどは、BKTよりも高い相関を示し、PFAとはcomparableな結果となった

image



# 所感

- この手法のリアルタイムな運用は難しいと思った（knowledgeをinferするために毎回モデルをtrainingしなおさなければならない）

- BKTが推定するスキルのmasteryはこのcase studyだけ見ると全くあてにならない・・・

- ユーザが回答した問題と紐づいたスキルのknowledgeしか推定できないところもlimitationの一つだと思う

- この手法がtraining dataに含まれていない「未知の問題」に対する正答率予測を平均することで、knowledgeをinferenceできるという話だったのであれば、非常に興味深いと思った。

　- 実際どうなんだろうか？




Paper/Blog Link My Issue
#RecommenderSystems #NeuralNetwork #CollaborativeFiltering #Evaluation #RecSys #Selected Papers/Blogs #Reproducibility #KeyPoint Notes Issue Date: 2022-04-11 GPT Summary- 深層学習技術はレコメンダーシステムの研究で広く用いられているが、再現性やベースライン選択に問題がある。18のトップnレコメンデーションアルゴリズムを分析した結果、再現できたのは7つのみで、6つは単純なヒューリスティック手法に劣っていた。残りの1つはベースラインを上回ったが、非ニューラル手法には及ばなかった。本研究は機械学習の実践における問題を指摘し、改善を呼びかけている。 Comment

RecSys'19のベストペーパー

日本語解説： https://qiita.com/smochi/items/98dbd9429c15898c5dc7

TopN推薦におけるDNNを用いた研究を追試した研究で、トップ会議の手法のうち18本の追試を試みたところ、追試のための現実的な努力や著者に連絡をするといったことを実施した上で再現できたものは7本であり、そのうち6/7が適切なハイパーパラメータ調整を行なったkNNベースのシンプルな手法に勝てなかった（かつ残りの一つも線形モデルに対して負ける場合もあった）、という話で、業界における評価における再現性の問題（ハイパーパラメータ調整の記載がない等）や、適切な実験設定の欠如（ベースラインのハイパーパラメータチューニングをせずに先行研究の記述内容をそのまま踏襲等、テストデータを用いたエポック数の調整、ランダムサンプリングのはずなのに明らかに提案手法に有利となるような偏ったサンプリングを実施...）、ベースラインの適切な選定（多くの研究がNeural Collaboraive Filteringをベースラインにしているが果たしてそれが適切か）などについて警鐘を鳴らす内容になっている。

過去の先行研究（[Paper Note] Sequence-Aware Recommender Systems, Massimo Quadrana+, ACM Computing Surveys (CSUR), Volume 51, Issue 4, 2018.02 )でも、研究者の間でデータセットの分割に関して、標準化されていない旨が記述されている。また、管理人が研究を追う中でも、共通のフレームワークで評価がされているとは言い難い印象を持っている（**このコメントは論文を読んだ当時を思い起こし2026年に追記しているが、この頃から業界はどのようにシフトしただろうか？最近は追えていない**）。

たとえば評価をする際には、データセットの選択だけでなく、データセットの中でどの規模感のデータセットを使うのか（MovieLens一つとっても様々なバリエーションがある）、leave-one-outをするのか、時系列性を考慮した履歴の分割をするのか、negative samplingをする際の件数やサンプリング方法、なんらかのstratifiedなk-fold cross validationをするのか否か、coldstartなデータを排除するのか否か、排除する際の足切りの基準、ハイパーパラメータ。最適化する際のメトリックと最適化をするパラメータ、平均を取る際の実験の試行回数、性能を測るメトリック（Precision, Recall, NDCG, MAP, MRR, AUC, HITS@N...)など様々な変数が存在し、これらの設定が異なると性能は確かに大きく変化すると思われる。実際に推薦モデルの検証をする際には適切な検証となるよう細心の注意を払いたい。

私個人としては本研究を知った以後、オフラインでの実験のみでなくらA/Bテストが実施されている研究に対する信頼性をより高めるようになった。

おそらくこれを受けてRecboleのようなフレームワークが登場したと思うが、現在は更新がされていないという認識である。いまはどのように再現性に関する取り組みがされているだろうか？
- Autonomously Generating Hints by Inferring Problem Solving Policies, Piech+, Stanford University, L@S'15




Paper/Blog Link My Issue
#RecommenderSystems #NeuralNetwork #CollaborativeFiltering #FactorizationMachines #CTRPrediction #SIGKDD #One-Line Notes Issue Date: 2021-05-25 GPT Summary- 特徴量の自動生成が求められる中、因子分解モデルは相互作用を学習し一般化するが、DNNは暗黙的である。本研究では、明示的に相互作用を生成する圧縮相互作用ネットワーク（CIN）を提案し、DNNと統合したeXtreme Deep Factorization Machine（xDeepFM）を開発。xDeepFMは低次・高次の相互作用を学習し、実データセットで最先端モデルを超える性能を示した。 Comment

DeepFM: A Factorization-Machine based Neural Network for CTR Prediction, Guo+, IJCAI’17 DeepFMの発展版

[Paper Note] Factorization Machines, Steffen Rendle, ICDM'10, 2010.12 にも書いたが、下記リンクに概要が記載されている。

DeepFMに関する動向： https://data.gunosy.io/entry/deep-factorization-machines-2018



DeepFMの発展についても詳細に述べられていて、とても参考になる。




Paper/Blog Link My Issue
#NeuralNetwork #ComputerVision #CVPR #Selected Papers/Blogs #Backbone #KeyPoint Notes #ResidualStream Issue Date: 2021-11-04 GPT Summary- 残差学習フレームワークを提案し、深いニューラルネットワークのトレーニングを容易にする。参照層の入力に基づいて残差関数を学習することで、最適化が容易になり、精度が向上。152層の残差ネットはImageNetで低い複雑性を保ちながら高い性能を示し、ILSVRC 2015で1位を獲得。COCOデータセットでも28%の改善を達成。 Comment

ResNet論文

ResNetでは、レイヤーの計算する関数を、残差F(x)と恒等関数xの和として定義する。これにより、レイヤーが入力との差分だけを学習すれば良くなり、モデルを深くしても最適化がしやすくなる効果ぎある。数レイヤーごとにResidual Connectionを導入し、恒等関数によるショートカットができるようにしている。



image



ResNetが提案される以前、モデルを深くすれば表現力が上がるはずなのに、実際には精度が下がってしまうことから、理論上レイヤーが恒等関数となるように初期化すれば、深いモデルでも浅いモデルと同等の表現が獲得できる、と言う考え方を発展させた。



（ステートオブAIガイドに基づく）

同じパラメータ数でより層を深くできる（Plainな構造と比べると層が1つ増える）Bottleneckアーキテクチャも提案している。



image

今や当たり前のように使われているResidual Connectionは、層の深いネットワークを学習するために必須の技術なのだと再認識。




Paper/Blog Link My Issue
#NeuralNetwork #EducationalDataMining #LearningAnalytics #StudentPerformancePrediction #EDM #KeyPoint Notes Issue Date: 2021-05-29 Comment

Knewton社の研究。IRTとIRTを拡張したモデルでStudent Performance Predictionを行い、3種類のデータセットでDKT [Paper Note] Deep Knowledge Tracing, Piech+, NIPS'15 と比較。比較の結果、IRT、およびIRTを拡張したモデルがDKTと同等、もしくはそれ以上の性能を出すことを示した。IRTはDKTと比べて、trainingが容易であり、パラメータチューニングも少なく済むし、DKTを数万のアイテムでtrainingするとメモリと計算時間が非常に大きくなるので、性能とパフォーマンス両方の面で実用上はIRTベースドな手法のほうが良いよね、という主張。



AUCを測る際に、具体的に何に大してAUCを測っているのかがわからない。モデルで何を予測しているかが明示的に書かれていないため（普通に考えたら、生徒のquizに対する回答の正誤を予測しているはず。IRTではquizのIDをinputして予測できるがDKTでは基本的にknowledge componentに対するproficiencyという形で予測される（table 1が各モデルがどのidに対して予測を行なったかの対応を示しているのだと思われる））。



image



image

knewton社は自社のアダプティブエンジンでIRTベースの手法を利用しており、DKTに対するIRTベースな手法の性能の比較に興味があったのだと思われる。

なお、論文の著者であるKnewton社のKevin H. Wilson氏はすでにknewton社を退職されている。

https://kevinhayeswilson.com/




Paper/Blog Link My Issue
#NeuralNetwork #EducationalDataMining #LearningAnalytics #StudentPerformancePrediction #KnowledgeTracing #EDM #KeyPoint Notes Issue Date: 2021-05-28 Comment

BKT, PFA, DKTのinputの違いが記載されており非常にわかりやすい



image

image



BKT, PFA, DKTを様々なデータセットで性能を比較している。また、ASSISTmentsデータに問題点があったことを指摘し（e.g. duplicate records問題など）、ASSSTmentsデータの問題点を取り除いたデータでも比較実験をしている。結論としては、ASSISTmentsデータの問題点を取り除いたデータで比較すると、DKTがめっちゃ強いというわけではなく、PFAと性能大して変わらなかった、ということ。



KDD cupのデータではDKTが優位だが、これはPFAをKDD Cupデータに適用する際に、難易度を適切に求められない場面があったから、とのこと（問題+ステップ名のペアで難易度を測らざるを得ないが、そもそも1人の生徒しかそういったペアに回答していない場合があり、難易度が1.0 / 0.0 等の極端な値になってしまう。これらがoverfittingの原因になったりするので、そういった問題-ステップペアの難易度をスキルの難易度で置き換えたりしている）。

ちなみにこの手のDKTこれまでのモデルと性能大して変わんないよ？系の主張は、当時だったらそうかもしれないが、2020年のRiiiDの結果みると、オリジナルなDKTがシンプルな構造すぎただけであって、SAKT+RNNみたいな構造だったら多分普通にoutperformする、と個人的には思っている。

ASSISTmentsデータにはduplicate records問題以外にも、複数種類のスキルタグが付与された問題があったときに、1つのスキルタグごとに1レコードが列挙されるようなデータになっている点が、BKTと比較してDKTが有利だった点として指摘している。スキルA, Bが付与されている問題が２問あった時に、それらにそれぞれ正解・不正解した場合のASSISTments09-10データの構造は下図のようになる。DKTを使ってこのようなsequenceを学習した場合、スキルタグBの正誤予測には、一つ前のtime-stempのスキルタグAの正誤予測がそのまま利用できる、といった関係性を学習してしまう可能性が高い。BKTはスキルタグごとにモデルを構築するので、これではBKTと比較してDKTの方が不当に有利だよね、ということも指摘している。

image



複数タグが存在する場合の対処方法として、シンプルに複数タグを連結して新しいタグとする、ということを提案している。

image




Paper/Blog Link My Issue
#Article #EfficiencyImprovement #NLP #LanguageModel #AIAgents #Blog #One-Line Notes Issue Date: 2026-04-11 Comment

元ポスト:

Loading…

Strong Modelをツールとして登録（Advisor)しておき、意思決定が困難になった場合はstrong modelにレビュー依頼をしてcontextを受け取り実行可能な枠組み。

Sonnetで12パーセント程度省コストで、SWE Bench Multilingual のスコアを2.7%向上、とのこと。

SWE Benchの結果は、Claute Opus 4.6をAdvisorとして利用した旨が脚注に書かれている。

下記システムカードによると、Opus 4.6 の SWE Bench Multilingualのスコアは77.83程度（細かい設定は追えていない）、元ポストのSonnet+Advisorのスコアは74.8%なので、near Opusな性能が出るとポストに記載されているが、そのくらいのgapがあるという点には注意が必要。

https://www-cdn.anthropic.com/6a5fa276ac68b9aeb0c8b6af5fa36326e0e166dd.pdf




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #AIAgents #Blog #Safety #Selected Papers/Blogs #One-Line Notes #Reference Collection #Safeguard Issue Date: 2026-04-08 Comment

元ポスト:

Loading…

Claude Mythos Previewが、ソフトウェアの脆弱性を見つける能力において、トップクラスの人間を除けば、あらゆる人間以上の能力を獲得してしまっており、これがサイバーセキュリティの概念を根本的に変化させてしまう危険がある。

実際、同モデルは数千にも及ぶ深刻な脆弱性を発見しており、それはOSやブラウザにも及び、これが経済や国家安全保障などに影響を及ぼすため、緊急のproject Glasswingを立ち上げており、まずは今回挙げたパートナーにClaude Mythos Previewにアクセス可能な無料のクレジットを与え、セキュリティに関する脆弱性を改善することで、セーフガードを確立し、その結果得られた知見をAnthropicがまとめて公表する、そしてその後パートナーはさらに拡大していく、という感じらしい。

しかし最近中国のOpenWeightモデルは、2ヶ月程度で米国のFrontier Modelに追いつく。では2ヶ月あとに中国系のOpenWeightモデルがClaude Mythos Previewの性能に追いついてOpenWeightとして公開された場合、世界はどうなってしまうのだろうか？

また、現在は以下の企業と連携してセーフガードを構築するようだが、これらグローバル企業以外の日本の企業はどうなるのだろうか？今後40以上の組織とも連携するようにする予定とのことだが、日本の社会を支えている企業群と連携するのはいつなのか？

image

所見:

Loading…

所見:

Loading…

しかしこれ、Claude Mythos Previewによって初めてこのようなことが起きたかのように書かれているけど、既知の脆弱性を見つけて悪用するというのは、既に公開されているOpenWeightモデルや、プロプライエタリモデルでも十分可能なのでは？
なぜいまさらこのようなことを言い始めたのだろうか。

所見:

Loading…




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #Alignment #Blog #Bias #Japanese #PostTraining Issue Date: 2026-03-24 Comment

技術的な詳細は不明で、
> 事後学習では、日本の文化的・社会的文脈におけるバイアス是正のための独自データセットを構築し、以下のベンチマークに示す結果を得ました。

と記述されている。おそらく構築したデータセットに基づいてAlignmentをとるための事後学習（ベースモデルの能力を落としていないため Catastrophic Forgettingは起きておらず、同社がLoRA系の技術に力を入れていることを鑑みるとおそらく何らかのPEFT手法ではないかと推察）を実施しているのだと思われる。

元ポスト:

Loading…




Paper/Blog Link My Issue
#Article #Pretraining #NLP #LanguageModel #SyntheticData #read-later #Selected Papers/Blogs #KeyPoint Notes Issue Date: 2026-03-17 Comment

元ポスト:

Loading…

- インターネットのデータ枯渇問題が指摘されながらも、合成データによって事前学習は進化を続けている
- LLMは事後学習で性能を向上させられるが、事前学習時点で伸ばせる上限が決まっているとされている
- 事前学習データの投入量はChinchilla則のパラメータ量の20倍から現在は60倍まで増加
- MoEは過学習しやすくパラメータ数の40倍は必要
- 学習データの多様性が重要で繰り返し同じデータを見ても性能は改善しない
- 合成データをそのまま用いるとmode collapseが生じ出力が単調化するため、実データを混ぜるか言い換えをしたデータで是正する（弱めのdata augmentationで良い)
- 最近重要な合成データはコードと推論過程を含むデータで、これらが事前学習データに含まれていると汎用な表現、思考能力、推論能力を事前学習時点から獲得できる可能性がある

というような話が元ポストに書かれている。

- Scaling Data-Constrained Language Models, Niklas Muennighoff+, NeurIPS'23

のようにrepetitionは4回までが効果的といった知見が報告されているが、現在はどこまで当てはまるのだろうか？

後ほど関連するissueのリンクを貼りたい

うーんおもしろそう、p.15, p.20, p.26, p.28, p.35, p.36 あたりが気になる。

てかこれが大学の講義...?楽しすぎでは。




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #AIAgents #Blog #Selected Papers/Blogs #LongHorizon #AgentHarness Issue Date: 2026-03-08 Comment

本ブログで定義されているAgent Harnessは、これまでのAI Agent研究で利用されてきた Scaffold（＝実行基盤）とEvaluation Harness（＝評価基盤）のように、実行と評価を区別してきたLiteratureとは異なる、より包括的な概念に見える（言葉としてHarnessが用いられているので、最初に読んだときは困惑した）。

先行研究:
- [Paper Note] Holistic Evaluation of Language Models, Percy Liang+, arXiv'22, 2022.11
- [Paper Note] Lessons from the Trenches on Reproducible Evaluation of Language Models, Stella Biderman+, arXiv'24, 2024.05
- [Paper Note] Holistic Agent Leaderboard: The Missing Infrastructure for AI Agent Evaluation, Sayash Kapoor+, arXiv'25, 2025.10

これまでのLiteratureでは、エージェントがタスクを遂行するためのエコシステム全般（言い換えるとLLMをエージェントの脳とした時の、エージェントの実装そのもの）のことをScaffold（ツール利用やコンテキスト管理、サブエージェントの実行、エラー時の挙動、プロンプト構成など）と呼び、

評価をする際の評価基盤となるインフラ（エージェントを動作させる仮想マシン等の実行環境やそのオーケストレーション、Scaffoldの構成、評価ベンチマーク、コストやtrajectoryのロギング等の評価全体に関わるエコシステム）のことをEvaluation Harnessと呼んできたと認識している。

（私の認識違いの可能性もあるが）このLiteratureを理解しておかないと、今後Harnessという言葉がバズワードと化して、思わぬ誤解を生むかもしれないので注意した方が良いかなと感じた。

つまり世の中には
- Scaffold
- Evaluation Harness
- Agent Harness

の3種類の定義があり、特に後者二つは省略してHarnessと呼ばれそう、という気がするが、後者二つは呼称が似ているが異なる概念を指しているので注意した方が良いかも（あくまで個人の感想）。

たとえば下記OpenAIのブログでも「Harness Engineering」という言葉がタイトルで用いられており、Harnessの定義がなされずに記述されているように見える。実際ブログ後半にはEvaluation HarnessというこれまでのLiteratureと同じ意味合いでの用語も登場している。今後どのような用語が何を指すのようになるかは分からないが、ハーネスという言葉の定義が人によって異なる可能性があるという点は認識しておいた方が良さそうである。
- Harness engineering: leveraging Codex in an agent-first world, Ryan Lopopolo, 2026.02

`Agent Harness` という用語の起源が気になっており、アンテナを張っているが、下記AnthropicブログでAgent Harnessという用語が登場している。
- Effective harnesses for long-running agents, Anthropic, 2025.11

下記文献でも
- [Paper Note] Building Effective AI Coding Agents for the Terminal: Scaffolding, Harness, Context Engineering, and Lessons Learned, Nghi D. Q. Bui, arXiv'26, 2026.03

Effective harnesses for long-running agents, Anthropic, 2025.11 が引用され `harness` という用語が用いられている。このブログが起源なのだろうか（勉強不足）。

- [Paper Note] SkillsBench: Benchmarking How Well Agent Skills Work Across Diverse Tasks, Xiangyi Li+, arXiv'26, 2026.02

でも Agent Harness という用語が使われている。




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #AIAgents #ChatGPT #Coding #Proprietary #Reference Collection Issue Date: 2026-03-06 Comment

元ポスト:

Loading…

Artiflcial Analysisによる評価:

Loading…

所見:

Loading…

所見:

Loading…

評判が良い。管理人も利用しているが、指示で曖昧な点をきちんと質問してくれる点が便利。かつ応答として、選択可能なオプションを提示し、自由記述もできる。実装の内容はClaude 4.6 Opusと比べるとコードがシンプルな印象を受けるが、これも指示次第な気はする。

曖昧な点があったら質問を投げかけるという挙動はopenhandsのPosition Paperとも整合する流れである。

- [Paper Note] Position: Humans are Missing from AI Coding Agent Research, Wang+, 2026.02




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #AIAgents #Coding #Post #SoftwareEngineering Issue Date: 2026-02-28 Comment

やっぱ英語で指示ださないとあかんか...（小並感）

関連:

Loading…


LLM/VLA等の学習ライブラリ回りでは、人間が細かく実装方針分析を指示した上で、実装部分のみを移譲すると今のところ一番うまくいくとのこと。




Paper/Blog Link My Issue
#Article #NLP #AIAgents #Blog #Selected Papers/Blogs #KeyPoint Notes #Surface-level Notes #AGENTS.md Issue Date: 2026-02-27 Comment

元ポスト:

Loading…

本ブログは CLAUDE.md について記述されているものだが、ブログ冒頭で記述されており、AGENTS.mdに一般的に適用できる話だと考えられるため、以下本文中でCLAUDE.mdとして記述されている部分も、AGENTS.mdと読み替えて記述している。

要するに
- `AGENTS.md` はAI Agentの **全ての会話に対してコンテキストをユーザが明示的に挿入する唯一の手段** であり、
- `AGENTS.md` にはプロジェクトのあらゆるタスクで **普遍的に必要な情報を、過不足なく、簡潔に記述されるべき** であり
- プロジェクトが大規模な場合は、`AGENTS.md` は目次として利用し、必要な情報は個別のファイルに別々に記述し、`AGENTS.md` 内にはその **ポインターのみを記載** する
- `AGENTS.md` の **自動生成は非推奨** であり、理由としては1行でも誤った記述が含まれていた場合全てのエージェントの挙動に影響が出るためであり、全ての内容について慎重に検討をしたうえで記述されるべきである。

という話のようである。

-----

- 原則
- AI Agentはstatelessであり、あなたのコードベースについて何も知らない。このため利用者がコンテキストとしてコードベースの情報を伝える必要があり、そのために有用なツールがAGENTS.mdである
- AGENTS.mdはすべての会話にデフォルトでコンテキストとして含まれる **唯一の** ファイルである
- AGENTS.mdでどのような情報が網羅されるべきか？
- **WHAT**: 技術スタック、プロジェクト構造、コードベースの構成等のリポジトリの基本情報を記述し、Agentが適切に情報を検索できるようにする
- **WHY**: プロジェクトの役割と、リポジトリ内の要素の役割
- **HOW**: Agentがどのような作業をすべきに関する明確な指示を記述し、その指示を実施するために必要な情報を全て含める
- AGENT.md はしばしば無視される
- たとえばClaude CodeではCLAUDE.md (Claudeが利用するAGENTS.md) をコンテキストに含める際に以下のシステムリマインダーを自動的に挿入する:
- つまり、AGENTS.mdに普遍的に利用可能な情報が含まれていない場合は、現在実施しようとしているタスクと関係ないとエージェントが判断し、AGENTS.mdが無視されることがある点に注意が必要

```

IMPORTANT: this context may or may not be relevant to your tasks.
You should not respond to this context unless it is highly relevant to your task.

```
- 優れたAGENTS.mdを作成するベストプラクティス
- **less (instructions) is more**:
- AI Agentが順守できる指示の数には限界があり、指示の数が増えれば増えるほど、指示を遵守できない割合が高まっていく。
- これはモデル依存であり、パラメータ数が大きいモデルほど多くの指示を遵守できる（150--200など）。
- AGENTS.mdがすべての会話に付与されることを考えると、たとえば50個の指示をAGENTS.mdに含めた場合、150個の指示を遵守できるAgentを利用していたら、AGENTS.mdだけで1/3だけを消費することになる。
- また、指示が増えれば増えるほど、均一に指示追従の能力が低下する。
- つまり、ある指示が冒頭・末尾に書かれていようとも、位置に関係なく何らかの指示に追従しない可能性が高まる。
- これらの性質から、可能な限り少ない指示を記述することが必要で、特に冗長性を排除し、あらゆるタスクに普遍的に適用可能な指示のみを記述することが肝要であることが示唆される。
- length & applicability:
- AGENTS.mdは、300行未満などが推奨されているが、要は **適切な普遍的に適用可能な情報が** 簡潔で短く記述されていることが好ましい[^1]。
- Progressive Disclosure
- プロジェクトが大規模化した場合、必要な全ての情報を簡潔にAGENTS.mdに含めることがそもそも困難になる
- この場合はAGENTS.mdに目次を記述し、機能ごとの必要な情報は個別のファイルに記述し、それがどこに格納されているかのポインタを記述することによって解決する
- AGENTS.mdに全ての情報を書いてしまってはいけない。この場合上記の less is more や length の原則に反することになる。
- AGENT (CLAUDE) is not an expensive linter
- コーディング規約を書いている人が多いがやめた方が良いという話で、
- コーディング規約を無視しているか否かを判断させるにはもっと決定論的で安価なツールがあるのでそちらに任せましょうという話と、
- コーディング規約を明示していなくてもAgentはコードスニペットを解釈する過程で暗黙的にどのようなコーディング規約に従っているかは理解できるので、わざわざ明示的に挿入して不要で無関係なコンテキストで埋め尽くす必要はないよね、という話が書かれている。
- `/init` コマンドや、`AGENTS.md (CLAUDE.md)` の**自動生成は非推奨**
- AGENTS.md はAgentの全ての挙動に影響を与えるため、1行でも誤りがあると全ての作業に影響が出る非常にクリティカルなファイルであるため、自動生成等に頼らずに、慎重に検討をした上で記述されるべきである、という話
- 実際、下記研究にてLLMが自動生成したAGENTS.mdでは、タスク性能は劣化しトークン消費量が増えるだけ、という結果が示されている
- [Paper Note] Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?, Thibaud Gloaguen+, arXiv'26, 2026.02

[^1]: 根拠として、ブログ中では、無関係な情報がコンテキストで埋め尽くされているよりも、関連性のある情報が埋め尽くされる場合が一般的に性能が向上すると書かれている。が、文献などは引用されていないように見える。たとえば、この記述に対して、「初期のRAGの研究でrelevantな情報に対してirrelevantな情報が周囲で埋め尽くされていた場合に実は性能が向上します、といった話があったじゃないか」といった鉞を飛ばすことができそうだが、これは古い研究でおそらく当時（数年前）のLLMではcontext中のrelevantな情報を見分ける能力が低かったことに起因する。つまり、このような現象は明らかにirrelevantな情報が混在することで、相対的にrelevantな情報が際立つことによってLLMのcontextの理解力が乏しい部分を補っていた、と管理人は推察しており、現代のLLMではcontextを解釈する性能は大幅に向上していると考えられるため、わざわざirrelevantな情報をcontextに含める必要はなく、この見解には私も同意する。そもそもこの私の見解があまりにも重箱の隅すぎて蛇足すぎるがなんかそういうことを思い出しちゃったので書いた :)

ここで記載されている内容はAGENTS.mdのみならず、そもそものプロンプトエンジニアリング全般で言える話でもある。




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #SmallModel #Slide Issue Date: 2025-05-28 Comment

元ポスト:

Loading…

関連
- Training Compute-Optimal Large Language Models, Jordan Hoffmann+, NeurIPS'22
- Scaling Laws for Neural Language Models, Jared Kaplan+, arXiv'20
- Distillation Scaling Laws, Dan Busbridge+, ICML'25
- [Paper Note] Textbooks Are All You Need, Suriya Gunasekar+, arXiv'23, 2023.06

先行研究を元に仮説を立てて、有望なアプローチを取る意思決定が非常に勉強になる。
Scaling Lawsが不確実性のある意思決定において非常に有用な知見となっている。

同じようにPruningとKnowledge Distilationを実施した事例として下記が挙げられる
- Llama-3_1-Nemotron-Ultra-253B-v1, Nvidia, 2025.04




Paper/Blog Link My Issue
#Article #Tutorial #Slide #ACL #One-Line Notes Issue Date: 2025-05-11 Comment

業界のトレンドを把握するのに非常に参考になる:
- Reasoning, KnowledgeGraph, KnowledgeEditing, Distillation
- PEFT, Bias, Fairness, Ethics
- Multimodal(QA, Benchmarking, Summarization)
などなど。

投稿数5000件は多いなあ…




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #ReinforcementLearning #Reasoning #OpenWeight Issue Date: 2025-03-06 Comment

元ポスト:

Loading…

- [Paper Note] START: Self-taught Reasoner with Tools, Chengpeng Li+, arXiv'25, 2025.03

Artificial Analysisによるベンチマークスコア:

Loading…

おそらく特定のタスクでDeepSeekR1とcomparable, 他タスクでは及ばない、という感じになりそうな予感




Paper/Blog Link My Issue
#Article #LanguageModel #Blog Issue Date: 2025-01-05 Comment

LLMを（呼び出す|呼び出される）SaaS企業が今後どのような戦略で動いていくかが考察されており興味深かった。



LLMを数学タスクにアラインする手法の系譜 - GPT-3からQwen2.5まで, bilzard, 2024.12


Paper/Blog Link My Issue
#Article #Tutorial #NLP #LanguageModel #Alignment #Supervised-FineTuning (SFT) #Chain-of-Thought #Reasoning #Mathematics #PostTraining Issue Date: 2024-12-27 Comment

- [Paper Note] Training Verifiers to Solve Math Word Problems, Karl Cobbe+, arXiv'21, 2021.10

において、数学においてモデルのパラメータ数のスケーリングによって性能改善が見込める学習手法として、モデルとは別にVerifierを学習し、モデルが出力した候補の中から良いものを選択できるようにする、という話の気持ちが最初よくわからなかったのだが、後半のなぜsample&selectがうまくいくのか？節を読んでなんとなく気持ちが理解できた。SFTを進めるとモデルが出力する解放の多様性が減っていくというのは、興味深かった。

しかし、特定の学習データで学習した時に、全く異なるUnseenなデータに対しても解法は減っていくのだろうか？という点が気になった。あとは、学習データの多様性をめちゃめちゃ増やしたらどうなるのか？というのも気になる。特定のデータセットを完全に攻略できるような解法を出力しやすくなると、他のデータセットの性能が悪くなる可能性がある気がしており、そうするとそもそもの1shotの性能自体も改善していかなくなりそうだが、その辺はどういう設定で実験されているのだろうか。

たとえば、
- [Paper Note] Beyond Full Fine-tuning: Harnessing the Power of LoRA for Multi-Task Instruction Tuning, Xin+, LREC-COLING'24

などでは、

- [Paper Note] Super-NaturalInstructions: Generalization via Declarative Instructions on 1600+ NLP Tasks, Yizhong Wang+, EMNLP'22, 2022.04

のような1600を超えるようなNLPタスクのデータでLoRAによりSFTすると、LoRAのパラメータ数を非常に大きくするとUnseenタスクに対する性能がfull-parameter tuningするよりも向上することが示されている。この例は数学に特化した例ではないが、SFTによって解法の多様性が減ることによって学習データに過剰適合して汎化性能が低下する、というのであれば、この論文のことを鑑みると「学習データにoverfittingした結果他のデータセットで性能が低下してしまう程度の多様性の学習データしか使えていないのでは」と感じてしまうのだが、その辺はどうなんだろうか。元論文を読んで確認したい。
とても勉強になった。

記事中で紹介されている
> LLMを使って複数解法の候補をサンプリングし、その中から最適な1つを選択する

のルーツは
- [Paper Note] Training Verifiers to Solve Math Word Problems, Karl Cobbe+, arXiv'21, 2021.10

とのことなので是非読みたい。

この辺はSelf-Consistency
- [Paper Note] Self-Consistency Improves Chain of Thought Reasoning in Language Models, Xuezhi Wang+, ICLR'23, 2022.03

あたりが最初なのかと思っていた。




Paper/Blog Link My Issue
#Article #Survey #NLP #LanguageModel #Evaluation #Blog #LLM-as-a-Judge #KeyPoint Notes Issue Date: 2024-12-25 Comment

- A Survey on LLM-as-a-Judge, Jiawei Gu+, arXiv'24

を読んだ結果を日本語でまとめてくださっている。

モデル選択について、外部APIに依存するとコストやプライバシー、再現性などの問題があるためOpenLLMをFinetuningすることで対応していることが論文中に記載されているようだが、評価能力にはまだ限界があるとのこと。
記事中ではLlama, Vicunaなどを利用している旨が記述されているが、どの程度のパラメータサイズのモデルをどんなデータでSFTし、どのようなタスクを評価したのだろうか（あとで元論文を見て確認したい）。

また、後処理としてルールマッチで抽出する必要あがるが、モデルのAlignmentが低いと成功率が下がるとのことである。
個人的には、スコアをテキストとして出力する形式の場合生成したテキストからトークンを抽出する方式ではなく、G-Eval のようにスコアと関連するトークン（e.g. 1,2,3,4,5）とその尤度の加重平均をとるような手法が後処理が楽で良いと感じる。

ICLR2025の査読にLLM-as-a-Judgeが導入されるというのは知らなかったので、非常に興味深い。

LLMが好む回答のバイアス（冗長性、位置など）別に各LLMのメタ評価をしている模様。また、性能を改善するための施策を実施した場合にどの程度メタ評価で性能が向上するかも評価している。特に説明を出力させても効果は薄く、また、複数LLMによる投票にしても位置バイアスの軽減に寄与する程度の改善しかなかったとのこと。また、複数ラウンドでの結果の要約をさせる方法がバイアスの低減に幅広く寄与したとのこと。

うーん、バイアスを低減するうまい方法がまだ無さそうなのがなかなか厳しい感じがする。
そもそも根本的に人間に人手評価をお願いする時もめちゃめちゃマニュアルとかガイドラインを作り込んだりした上でもagreementが高くなかったりするので、やはり難しそうである。

ただ、MTBenchでは人間の評価結果とLLMの評価結果の相関（agreementだっけか…？）が高かったことなどが報告されているし、LLMあるあるのタスクごとに得意不得意があります、という話な気もする。




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #GenerativeAI #Blog #One-Line Notes Issue Date: 2024-12-24 Comment

様々な有識者の見解をまとめつつ、文献を引用しつつ、かつ最終的に「人間が知能というものに対してなんらかのバイアスを持っている」可能性がある、という話をしており興味深い。
一部の有識者はARC-AGIの一部の、人間なら見た瞬間に分かるようなパターン認識の問題でも解けていないことから、AGIではないと主張しているとのことだったが、人間目線で簡単な問題が解けることはAGIとして必須な条件ではないよね、といった話が書かれており、そもそも有識者がどのようなものさしや観点でAGIを見ているのか、どういう視点があるのか、ということが感覚的に分かる内容であり、おもしろかった。

しかし、そもそも何がどうなったらAGIが実現できたと言えるのだろうか？定義がわからない（定義、あるのか…？）



Netflixの推薦＆検索システム最前線 - QCon San Francisco 2024現地レポート, UZABASE, 2024.12


Paper/Blog Link My Issue
#Article #RecommenderSystems #Blog #KeyPoint Notes Issue Date: 2024-12-20 Comment

インフラ構成の部分が面白い。モデルの構築方法などは、まず軽量なモデルやヒューリスティックで候補を絞り、その後計算量が重いモデルでリランキングする典型的な手法。

Netflixのインフラによって、以下のようなことを
>1～2秒前の最新データを参照でき、推薦生成に反映させることが可能です

latencyを40msに抑えつつ実現しているとのこと。直前のアクションをinferenceで考慮できるのは相当性能に影響あると思われる。

また、検索と推薦をマルチタスク学習しパラメータをシェアすることで両者の性能を挙げているのが興味深い。
モデル自体は近年のLLMを用いた推薦では無く、Deepなニューラルネットに基づくモデルを採用
（まあLLMなんかにリアルタイムで推論させたらlatency 40ms未満という制約はだいぶきついと思われるしそもそも性能向上するかもわからん。予測性能とかよりも、推薦理由の生成などの他タスクも同時に実施できるのは強みではあるとは思うが…）。

まあしかし、すごい目新しい情報があったかと言われると基本的な内容に留まっているのでそうでもないという感想ではある。




Paper/Blog Link My Issue
#Article #Blog #KeyPoint Notes Issue Date: 2024-11-18 Comment

具体的だがシンプルに知見がまとまっていてとても分かりやすい。

顧客開発モデルに基づいた考え方のみならず、仮設整理のために実際に使われているシートなどの実用的なツール群や、
顧客とのチャネル構築方法、プロダクトのスケールするための知見、チームビルディング、カルチャーの作り方の作法など（他にも透明性とかサンクコストを恐れずシンプルさを保つことのコスト削減効果などここには書ききれない）、
実体験を具体的に交えながら説明されており、盛りだくさんで非常に勉強になる。




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #Evaluation #Coding Issue Date: 2024-11-13 Comment

元ポスト:

Loading…

- ChatBot Arena, lmsys org, 2023.05 も参照のこと

Chatbot Arenaがリリースされたのが1年半前であることをおもいおこし、この2年で飛躍的にLLMができることが増えたなぁ、パラメータ数増えたなぁ、でも省パラメータで性能めっちゃ上がったなぁ、proprietary LLMにOpenLLMが追いついてきたなぁ、としみじみ思うなどした。




Paper/Blog Link My Issue
#Article #Infrastructure #GPU-Platform #KeyPoint Notes Issue Date: 2024-11-09 Comment

元ポスト:

Loading…


A100を1時間あたり1.29$で使えるぽいので、安価である。8BのLLMをLoRAでちょろっとSFTするくらいなら、数ドルくらいでいけそう。

AWSだと、A100を8基、vCPU96、VRAM320G、RAM1152GiBのインスタンス（p4d24xlarge）が、1時間あたりオンデマンドで32.77$なのに対し、

LambdaではA100 1基あたり1.29$なので、8基で10.32$となる。したがって、コストはだいたいAWSのおよそ1/3くらいに見える（他にも安価なAWSインスタンスあるかもだが）。
ちなみにLambdaでは、vCPU124、RAM1800GiBである。

AWS参考: https://aws.amazon.com/jp/ec2/instance-types/p4/

こちらのポストも参照のこと:

Loading…


Lambdaに加え
- [runpod.io]( https://www.runpod.io)
- [vast.ai]( https://vast.ai/)

というサービスも紹介されている。

[Perplexityで3つを比較させた結果（参考; Hallucinationに注意）]( https://www.perplexity.ai/search/runpod-io-vast-ai-lambdatea100-vJgXn4osSfCqxPsxuJEPKA)

>これらのサービスの中では、Vast.aiが最も安価ですが、セキュリティと安定性に注意が必要です。RunPodは多機能で使いやすいものの、やや高価です。Lambdaは安定性が高いですが、柔軟性に欠ける面があります。選択する際は、予算、セキュリティ要件、必要な機能性を考慮して判断することが重要です。




Paper/Blog Link My Issue
#Article #NLP #SpeechProcessing #Blog #Japanese #AutomaticSpeechRecognition(ASR) #KeyPoint Notes Issue Date: 2024-11-07 Comment

whisper large-v3を蒸留したkotoba-whisper-v1.0に対して、日本語のオーディオデータで追加学習をしたモデル、kotoba-whisper-v2.0を利用するための環境構築方法やコードの例が記述されている。

公式によると、whisper-large-v3よりも6.3倍のスループットとのこと。また、qiita記事中ではwhisper large-v2に対して約6.0倍のスループットであることが言及されている。

学習に用いられたデータは、ReasonSpeechデータ（日本語のテレビの録音データ）
- ReazonSpeech: A Free and Massive Corpus for Japanese ASR, Yin+, NLP'23

をWERに基づくフィルタリングによって良質なデータのみを抽出することで作成されたデータの模様

公式のモデルカードも参照のこと: https://huggingface.co/kotoba-tech/kotoba-whisper-v2.0

日本のテレビ番組のデータで学習されているので、それを念頭に置いた上で、自分が適用したいデータとの相性を考えると良さそうである。

また、動作速度が速いのはシンプルにありがたい。




Paper/Blog Link My Issue
#Article #Survey #GenerativeAI #Blog #KeyPoint Notes Issue Date: 2024-10-01 Comment

ソフトウェア開発で利用され始めている生成AIのプロダクト群と、それらに関連するソースコード生成やテストコード生成、エージェントによる自動システム開発等の研究動向、今後の展望について具体的に記述されている。

SIerやITベンダー内では、実際に活用しているところも一部あるようだが、まだ検証や改革の途中の模様。要件定義に対するLLMの活用も模索されているようだが、産業側もアカデミックも研究段階。

web系では、サイバーやLINEヤフーが全社的にすでにGithub Copilotを導入しているとのこと。

Devin AIのように、Github上のオープンソースのIssueをもとにしたベンチマークで、2294件中13.86%のIssueを解決した、みたいな話を見ると、そのうちコードを書く仕事はIssueを立てる仕事に置き換わるんだろうなあ、という所感を得た（小並感

Claude Opus 4.6あたりが一つの節目で、明らかに2026年頭にかけてCoding Agentの質が上がって完全なる実用レベルに到達したという感がある。




Paper/Blog Link My Issue
#Article #Blog #Management #KeyPoint Notes Issue Date: 2024-09-30 Comment

プロダクトマネジメントについて初心者向けに書かれた記事。勉強になった。

JTBDフレームワークは顧客開発モデルなどでも出てくるので、もう一度復習しておきたい。

>When (Situation) I want to (Motivation) So I can (Expected outcome)

ビルドトラップについても勉強になった。ミニマムでユーザの課題（ニーズ）を解決（満たす）する価値を提供することが重要。この辺は、技術にこだわりや興味、自信がある人ほど作り込みすぎてしまう印象がある。
https://product-managers-club.jp/blog/post/build-traps-fall

レベル2生産性の簡易的な計算方法のフレームワーク。知っておくと役に立つ場面がありそう。考え方として知っておくだけでも良い。confidenceの定義が難しそう。
>・Reach: どれだけ多くの顧客/ユーザーにとっての問題か
・Impact: その問題は個々の顧客/ユーザーにとってどれだけ深刻か
・Conficence: ReachとImpactがどれだけ確からしいか (Effortの確からしさも含むことがある)
・Effort: 問題解決の実装に必要な工数
計算式は以下の通りです。
RICEスコア = Reach * Impact * Confidence / Effort

と思ったが、一応参考として以下のようなものが紹介されている。この辺はプロダクトやチームごとにより具体的なものを決めていくと良いのだろうと思う。特に発案者やその同僚が信じている、の部分は深掘りできそうな気がする。その人にしか見えておらず、定量化できない感覚のような部分があったとしたら、この基準では低いスコアを付与してしまう。ユーザに近しい人ほどそういう感覚を持っており、軽視すべきでないと個人的には考える（が、発言者によって熱量のオフセットが異なるのでその辺も考慮しないといけないから判断難しそう）。
>・発案者やその同僚が信じている (0.01 - 0.2)
・複数の顧客からリクエストがあった (0.5 - 1)
・市場リサーチ結果 (1 - 2)
・一定量以上のユーザーインタビュー結果 (3)
・実際のプロダクト上での検証結果 (5 - 10)

記事のまとめ
>・ソリューションよりも問題の明確化にフォーカスしよう。そのための手法の1つにJTBDフレームワークがある。
・問題解決の優先度を評価するための観点を知ろう。その観点リストの1つにRICEフレームワークがある。
・PBIの相対的な優先順位づけも大事だが、その前に必ずプロダクト戦略へのアラインを確認しよう。




Paper/Blog Link My Issue
#Article #RecommenderSystems #Slide #KeyPoint Notes Issue Date: 2024-09-15 Comment

おもしろそうなので後で読む

クリック率やコンバージョン率に最適化することが従来のやり方だが、クリックベイトのため粗悪なコンテンツを推薦してしまったり、人気のあるアイテムに推薦リストが偏ってしまい、長期的なユーザの利益を害するという話。

20年くらい前からこの辺をなんとかするために、推薦のセレンディピティや多様性を考慮する手法が研究されており、それらのエッセンスが紹介されている。また、Calibrated Recommendation [Paper Note] Calibrated Recommendation, Herald Steck, Netflix, RecSys'18 （ユーザの推薦リストがのジャンルの比率がユーザの好む比率になるように最適化する方法で、劣モジュラ関数を最適化するためgreedyに解いてもある程度良い近似解が保証されている）などの概要も説明されていて非常に勉強になった。

セレンディピティのある推薦アルゴリズムをGoogle上でA/Bテストしたら、ユーザの満足度とコアユーザー転換率が大幅に向上したと言う話や、推薦はフィルターバブル問題を実は悪化させないといった研究がGroupLensのKonstan先生のチームから出ているなど、興味深い話題が盛りだくさんだった。




Paper/Blog Link My Issue
#Article #RecommenderSystems #NeuralNetwork #CTRPrediction #NewsRecommendation #MLOps #Evaluation #Blog #A/B Testing #One-Line Notes Issue Date: 2024-08-31 Comment

>推薦モデルの良し悪しをより高い確度で評価できる実験を、より簡単に実行できる状態を作ることでした。平たく言えば「いかにA/Bテストしやすい推薦システムを設計するか」が最も重要だった訳です。

オフライン評価とオンライン評価の相関がない系の話で、A/Bテストを容易に実施できる環境になかった、かつCTRが実際に向上したモデルがオフライン評価での性能が現行モデルよりも悪く、意思決定がなかなかできなかった、という話。

うーんやはり、推薦におけるオフライン評価ってあまりあてにできないよね、、、
そもそも新たなモデルをデプロイした時点で、テストした時とデータの分布が変わるわけだし、、、

Off-Policy Evaluationの話は勉強したい。

あと、定性評価は重要




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #OpenWeight #needs-revision Issue Date: 2024-07-09 Comment

>LLMの日本語能力を評価するNejumi LLM リーダーボード3においては、700億パラメータのMeta-Llama-3-70B-Instructと同等の性能となっており、スクラッチ開発のオープンな日本語LLMとしてはトップクラスの性能となります（2024年7月現在）。
モデルは商用利用可能なApache License 2.0で提供されており

これはすごい




Paper/Blog Link My Issue
#Article #RecommenderSystems #MLOps #Slide #One-Line Notes Issue Date: 2023-12-19 Comment

DeNAでのRecSysのアーキテクチャ（バッチ、リアルタイム）が紹介されている。バッチではワークフローエンジンとしてVertex AI Pipelineが用いられている。リアルタイムになるとアーキテクチャが非常に複雑になっている。
複雑なアーキテクチャだが、Generative Recommendation使ったらもっとすっきりしそうだなーと思いつつ、レイテンシと運用コストの課題があるのでまだ実用段階じゃないよね、と思うなどした。

リアルタイム推薦によって、バッチで日毎の更新だった場合と比べ、入札率、クリック率、回遊率が大きく改善したのは面白い。




Paper/Blog Link My Issue
#Article #LanguageModel #Blog #One-Line Notes Issue Date: 2023-12-05 Comment

StabilityAI Japan秋葉さん（元PFN）のW&B Conferenceでの発表に関する記事。
LLM構築タイムアタックでLLMをもし構築することになったら！？
のざっくりとしたプロセスや、次ページでOpenAIのGPT4のテクニカルレポートのクレジットから各チームの規模感を推定して、どの部分にどの程度の人員が割かれていたのかというのをベースに、各パートでどんなことがやられていそうかという話がされている。

LLM構築タイムアタックで、まずGPUを用意します！（ここが一番大変かも）の時点で、あっ察し（白目　という感じがして面白かった。




Paper/Blog Link My Issue
#Article #Tutorial #Dataset #LanguageModel #Evaluation #One-Line Notes Issue Date: 2023-11-16 Comment

JGLUEのexample付きの詳細、構築の経緯のみならず、最近の英語・日本語LLMの代表的な評価データ（方法）がまとまっている（AlpacaEval, MTBenchなど）。また、LLMにおける自動評価の課題が興味深く、LLM評価で生じるバイアスについても記述されている。Name biasなどはなるほどと思った。

日本語LLMの今後の評価に向けて、特にGPT4による評価を避け、きちんとアノテーションしたデータを用意しfinetuningした分類器を用いるという視点、参考にしたい。




Paper/Blog Link My Issue
#Article #NLP #Infrastructure #MLOps #RAG(RetrievalAugmentedGeneration) #Blog #KeyPoint Notes Issue Date: 2023-11-15 Comment

低コストで社内文書に対するRAGを実現することに注力している。
以下、図はブログから引用。

image

基本的にはバッチジョブで社内文書をベクトル化しS3へ格納。アプリ起動時にS3から最新データを読み込み検索可能にしRAGするという流れ。
低コスト化のために、Embedding作成にOpenWeightの言語モデル（text-edbedding-ada002と同等の性能）を利用している。実装は基本的にllamaindexを利用している。

特に日本語テキストにおいてはtext-embedding-ada002は OpenAI の Embeddings API はイケてるのか、定量的に調べてみる, akeyhero (Akihiro Katsura), Qiita, 2023.04 において、JSTSタスクにおいてあまり性能が高くない（ただし、OpenAI の Embeddings API はイケてるのか、定量的に調べてみる, akeyhero (Akihiro Katsura), Qiita, 2023.04 での報告値は基本的にJSTSデータでfinetuningされてた結果と思われる）と言われているので、お金かけて無理して使う必要はないのかなという印象はある。




Paper/Blog Link My Issue
#Article #Tutorial #NLP #LanguageModel #Alignment #GenerativeAI #Hallucination #Blog #Safety Issue Date: 2023-11-03 Comment

この資料をスタートにReferしている論文などを勉強すると、GenerativeAIのリスク周りに詳しくなれそう。この辺は疎いので勉強になる。
しかし、LLMのAlignmentが不十分だったり、Hallucinationを100%防ぐことは原理的に不可能だと思われるので、この辺とどう付き合っていくかがLLMと付き合っていく上で難しいところ。この辺は自分たちが活用したいユースケースに応じて柔軟に対応しなければならず、この辺の細かいカスタマイズをする地道な作業はずっと残り続けるのではないかなあ




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #Prompting #Blog Issue Date: 2023-10-29 Comment

ざっと見たが現時点で主要なものはほぼ含まれているのでは、という印象
実際のプロンプト例が載っているので、理解しやすいかもしれない。




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #Evaluation #Blog #KeyPoint Notes Issue Date: 2023-10-27 Comment

LLM.jpによる日本語LLMのリーダーボード。4-shotsでの結果、かつinstructionを与えた場合の生成テキストに対する評価、という点には留意したい。たとえばゼロショットで活用したい、という場合にこのリーダーボードの結果がそのまま再現される保証はないと推察される。

日本語LLMベンチマークと自動プロンプトエンジニアリング, PFN Blog, 2023.10 の知見でもあった通り、promptingの仕方によってもLLM間で順位が逆転する現象なども起こりうる。あくまでリーダーボードの値は参考値として留め、どのLLMを採用するかは、自分が利用するタスクやデータで検証した方がbetterだと思われる。

あとはそもそも本当にLLMを使う必要があるのか? [Paper Note] Prompt2Model: Generating Deployable Models from Natural Language Instructions, Vijay Viswanathan+, arXiv'23, 2023.08 のような手法ではダメなのか?みたいなところも考えられると良いのかもしれない。

以下サイトより引用
> 評価手法・ツール
このダッシュボードの内容はllm-jpで公開している評価ツール、llm-jp-evalで各モデルに対して評価を行なった結果である。llm-jp-evalは、既存のリーダボードとは行われている評価とは、主に以下のところで違っている。
AlpacaやBig-Benchなどを参考にした、インストラクションチューニングよりのプロンプトを入力として与えて、その入力に対するモデルの生成結果を評価する
>評価は基本、モデルが生成した文字列だけを使って行う
>Few shotでの評価を行っており、このダッシュボードには4-shotsでの結果を載せている

>評価手法・ツールの詳細はllm-jp-evalを是非参照されたい。

>評価項目・データセット
評価項目として、まず4つのカテゴリーにおける平均スコアを算出した。さらにその4カテゴリーの平均値の平均値をとった値がAVGである。
MC (Multi-Choice QA)：jcommonsenseqa
NLI (Natural Language Inference)：jamp、janli、jnli、jsem、jsick
QA (Question Answering)：jemhopqa、niilc
RC (Reading Comprehension)：jsquad

>それぞれのカテゴリの平均を出す方法に言語学的な意味はないため、最終的な平均値はあくまで参考値ということに注意されたい。

JGlueを利用した日本語LLMのリーダーボードとして Nejumi LLMリーダーボード, Weights & Biases などもある




Paper/Blog Link My Issue
#Article #NLP #LanguageModel #SyntheticData #Distillation #Slide #Finetuning #One-Line Notes #DownstreamTasks Issue Date: 2023-09-05 Comment

GPT3でデータを作成したら、タスクごとに有効なデータ作成方法は異なったが、人手で作成したデータと同等の性能を達成するデータ（BERTでfinetuning）を、低コストで実現できたよ、という研究

この辺の話はもはや [Paper Note] Prompt2Model: Generating Deployable Models from Natural Language Instructions, Vijay Viswanathan+, arXiv'23, 2023.08 を使えばいいのでは、という気がする。




Paper/Blog Link My Issue
#Article #NeuralNetwork #Tutorial #NLP #Transformer #Slide #Selected Papers/Blogs Issue Date: 2022-09-06 Comment

Transformerの動作原理を直感的に理解するのに非常にわかりやすい説明で、とても勉強になる。
以下のような内容が解説されており、あまりにも盛りだくさんで最高。

- Positional Encoding
- autoregressive vs. non-autoregressive
- residual connection
- multi-head attention
- RNN（O(N)だけど長い系列苦手）, CNN（O(N)だけど近傍しか見れない）との対比
- Vision & Languageの話題とVision Transformerとのつながり
- Swin Transformer
- 基盤モデルの定義
- ある目的関数のもと、自己教師あり学習された、巨大なモデル（様々なタスクに容易に転用できる）
- gMLP, MLP-MixerなどのMLP likeなアーキテクチャとの比較
- Transformerと本質的にやっていることはあまり変わらず、ベクトルの混ぜ方（attention vs. 行列積）と位置情報の保持をベクトルがするのかindexに基づいてネットワークが保持するのか、が変わっているのみ
- Transformer性能向上の軌跡
- pre-Norm / post-Norm / 活性化関数(GLU等) / MoE等 / RoPE
- Scaling Law
- CNNとViTの性質（CNNはハイパスフィルタ、ViTはローパスフィルタ）




Paper/Blog Link My Issue
#Article #Tutorial #BeamSearch #Blog #One-Line Notes Issue Date: 2021-06-24 Comment

ビームサーチについて、コード付きで説明してくれており、大変わかりやすい。

heapqを使って実装している。また、ビームサーチをbatchに対して行う方法についても書いてある（ただ、一部に対してしかbatchでの処理は適用できていない）。

自分もバッチに対して効率的にビームサーチするにはどのように実装すれば良いのかよくわからないので、誰か教えて欲しい。




Paper/Blog Link My Issue
#Article #NeuralNetwork #MachineTranslation #NLP #NAACL #KeyPoint Notes Issue Date: 2021-06-03 Comment

Transformerに基づいたNMTにおいて、Encoderが入力を解釈し、Decoderが翻訳をしている、という通説を否定し、エンコーディング段階、さらにはinput embeddingの段階でそもそも翻訳が始まっていることを指摘。
エンコーディングの段階ですでに翻訳が始まっているのであれば、エンコーダの層を増やして、デコーダの層を減らせば、デコーディング速度を上げられる。
通常はエンコーダ、デコーダともに6層だが、10-2層にしたらBLEUスコアは変わらずデコーディングスピードは2.3倍になった。
18-4層の構成にしたら、BLEUスコアも1.42ポイント増加しデコーディング速度は1.4倍になった。

この研究は個人的に非常に興味深く、既存の常識を疑い、分析によりそれを明らかにし、シンプルな改善で性能向上およびデコーディング速度も向上しており、とても好き。




Paper/Blog Link My Issue
#Article #RecommenderSystems #Survey #SequentialRecommendation Issue Date: 2020-11-13 GPT Summary- レコメンドシステムは、機械学習を用いた成功したデータマイニングの応用であり、従来は単一のユーザー-アイテムインタラクションに基づいていましたが、実際のアプリケーションでは時間とともに多様なインタラクションが記録されます。本研究は、これらの逐次的なインタラクションを考慮した推薦プロセスに関する既存研究を概観し、関連するタスクと目標の分類を提案。さらに、シーケンス情報を利用したレコメンダーシステムのベンチマーク方法論と未解決の課題について議論します。 Comment

評価方法の議論が非常に参考になる。特に、Survey執筆時点において、コミュニティの中でデータ分割方法について標準化されたものがないといった話は参考になる。




Paper/Blog Link My Issue
#Article #Tutorial #NLP #LanguageModel #Slide #Reference Collection Issue Date: 2020-01-13 Comment

自然言語処理の王様「BERT」の論文を徹底解説

https://qiita.com/omiita/items/72998858efc19a368e50

Transformer関連 [Paper Note] Attention Is All You Need, Ashish Vaswani+, NeurIPS'17, 2017.07 あたりを先に読んでからが読むと良い



要は

・Transformerをたくさん積んだモデル

・NSPとMLMで双方向性を持った事前学習タスクを実施することで性能向上

・pooler layer（Transformer Encoderの次にくっつくlayer）を切り替えることで、様々なタスクにfine-tuning可能（i.e. pooler layerは転移学習の対象外）

・予測する際は、[CLS]トークンに対応する位置の出力を用いて分類問題や複数文間の関係性を問う問題を解いたり、各トークン位置に対応する出力を用いてQAの正解spanを予測したり、色々できる

・gMLP MLP-like Architecture あたりの研究が進んでくると使われなくなってくる可能性有

こっちの記事もわかりやすい。



BERTについて勉強したことまとめ (2)モデル構造について

https://engineering.mobalab.net/2020/06/12/bert%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E5%8B%89%E5%BC%B7%E3%81%97%E3%81%9F%E3%81%93%E3%81%A8%E3%81%BE%E3%81%A8%E3%82%81-2%E3%83%A2%E3%83%87%E3%83%AB%E6%A7%8B%E9%80%A0%E3%81%AB%E3%81%A4%E3%81%84/