Kei Moriyama keimoriyama

イン・ザ・プールを読んだ。 奥田英朗さんによる作品で、精神科医伊良部シリーズの最初の話。 この医者が変わった病気を持つ人達を治療するかもしれないし、しないかもしれない話だ。

全部で五つの短編が集録されていて、読みやすかった。 集録されているのは以下の五編。

• イン・ザ・プール
• 勃ちっぱなし
• コンパニオン
• フレンズ
• いてもたっても

フレンズが一番のお気に入りの作品。 携帯依存症の高校生の話で、その高校生は日々頑張って友達関係を維持している。 この友情関係の維持のしかたが、とてもいたたまれない様子で、自分に刺さった。 こういう時期ってあるよな〜って感情移入できた。

全体的に明確に解決しているとは書かれていないが、ネガティブな終わり方もしていなくて、読後感はとても良かった。

映画化されているらしい。

ブラッド・コバルト

コンゴで行われているコバルト採掘の現場を取材したノンフィクションだった。 様々なIT企業がコバルトのサプライチェーンの健全さをアピールしているが、実態はそうなっていない。 低賃金で長時間、危険な環境で採掘の現場で搾取されている労働者が居る。 採掘時に入るトンネル内の環境が良くない事に加え、崩落して生き埋めになる可能性もある。 加えて、ウランなどの危険な鉱物が含まれている可能性がある。 これだけではなく、鉱石を洗うことで生活に使用する河川が汚れることや、児童労働の問題などがある。

この本は、普段使っているスマホやPCがコンゴ人の命の上に存在しているという事実を突きつけてきた。 今となっては、手放すことができない製品だから、この搾取に加担していると言っても過言ではないと思った。 本の中でも指摘されているが、サプライチェーンの上流に居る自分にとってとても都合が悪い。 特に、この問題が解決した時に今のスマホの値段が上がるのかなあとか考えた時の気分は最悪だった。

現在のコンゴ政府では、汚職撤廃キャンペーンが行われているらしい。 これに期待したい。

📄論文情報

• SAEs Are Good for Steering – If You Select the Right Features
• EMNLP 2025 main

🔑この論文のキーメッセージ

• （1, 2文でまとめる）

🎓どういう問題に取り組んだのか

• SAEを用いた特徴量選択において、入力と出力の特徴量のそれぞれに影響がある特徴量を見つけること

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• Sparse AutoEncoder(SAE)は介入するための特徴量を選択する時に有効な手法である
• だが、介入のために有効な特徴を選択することはまだ未知の問題である

💡問題解決に向けたキーアイデアは何か

• 特徴量を以下の二種類に分類し、分類するための指標を提案した
  • Input features：モデルに入力されたパターンを認識する特徴量
  • Output features：モデルが生成するトークンに影響する特徴量
• これらの分析には、Logit Lensが使用されている
  • Logit Lengsはモデルのパラメータを語彙空間に射影し、その出力分布を見てパラメータを分析する方法のこと
• Input featuresのスコアの計算には、任意の文章集合を用いる
  • この文章集合において最も大きくSAEのトークンを発火させたトークンと、Logit Lensにより予測されたトークンの一致率をスコアとしている
• Output Featuresのスコアの計算にはLogit Lensにより予測されたトークンのスコアと順位、確率を使用する
  • その特徴量に介入を行った時のモデルの出力分布と介入をする前の分布の差をスコアとしている
  • Logit Lensによる予測結果を用いて介入する前の出力分布を計算しているが、よく分からなかった

👀新たに分かったことは何か

• 上記のスコアをGemmaやLlamaに適用した所、Gemmaにおいては入力に近い層ではInput features、出力に近い層ではOutput Featuresのスコアが大きくなっていた。
  • それ以外のモデルにおいては、この傾向は当てはまっていない
• Output featuresが高いパラメータに介入することによる出力文章の変化を計算した
  • 実験では、スコアに閾値を用意し介入する特徴量を選択している
  • 評価には、Generation Success@Kを使用している。
  • Logit Lensにより予測されたTop-kのトークンと文章に含まれるトークンの一致率を計算している。
• 閾値を上げると、Generation Success@Kが上昇することが分かった

❓疑問点は何か

• スコアの計算結果で、きれいな結果が出ているのがGemmaだけなのが気になる
  • 介入の結果は同様の傾向を示している
• 結局Output featuresが高いものが良い特徴であるのか？
• 介入の方法が良く分からなかった
  • 方向を決める方法が知りたい

📄論文情報

• Gorilla: Large Language Model Connected with Massive APIs
• NeurIPS 2024

🔑この論文のキーメッセージ

• LLMのAPIを呼び出す能力は、LLM自身に与えられたAPIのドキュメントが正確であるか判断させながら学習を進めると良い
• API呼び出しの評価はASTの部分木マッチングを使用すると良い

🎓どういう問題に取り組んだのか

• LLMが外部のAPIを上手く活用するための学習方法を提案した
• また、LLMのAPI活用能力を評価するためにベンチマークデータセットを構築した

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• APIを呼び出すためのコードをLLMが生成することはまだ難しいタスクである
• APIの使用は頻繁に更新されることが原因の一つとして挙げられている

💡問題解決に向けたキーアイデアは何か

• 評価のために、APIBenchと呼ばれるベンチマークデータセットを構築した
  • TorchHubなどにアップロードされているモデルカードから仮想APIの呼び出しコードを作成している
  • このAPIについて指示をGPT-4を使用して生成している
• Retriever-Aware Training
  • プロンプトに含まれているAPIのドキュメントが不正確である可能性がある
  • 最初に、プロンプトに含まれているドキュメントが正確であるかを予測する
    • 学習データには、不正確なドキュメントを含めるように拡張している
  • 正確ではない予測した場合、そのドキュンメントを使用して推論しないように学習を促す
• 評価にはASTの部分木マッチングを使用している
  • APIの引数には、必要ではないものが存在している
  • そこで、構文木を作っておき、LLMの生成した呼び出しのコードが部分木であるかどうかを判定して評価している

👀新たに分かったことは何か

• 学習したモデル（論文中ではGorilla）がベースラインモデル（GPT-4やLLama）よりzero-shotやFew-shotで良い性能であった
  • Few-shotに使用するRetrieverを変えても同様の結果になった
• ASTによる評価は、人手評価と同様の性能を示している

❓疑問点は何か

• 実装のイメージがつかない
  • LLMが与えられたドキュメントを判断した後に、プロンプトの文言を追加するという事なのか
• Gorillaはオリジナルのモデルではないよな？
  • Llamaベースのモデルになると思うが、シンプルなSFTをした時との比較は無いのだろうか

📄論文情報

• SAE-SSV: Supervised Steering in Sparse Representation Spaces for Reliable Control of Language Models
• EMNLP 2025 main

🔑この論文のキーメッセージ

• SAEを用いた特徴量を用いて介入を行うことで、LLMをより良く制御することができる

🎓どういう問題に取り組んだのか

• 自由記述タスクにおけるLLMへのパラメータ介入手法の性能を向上すること
• 特に、介入に使用する適切なベクトルを構築することを目的する

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• LLMの生成文章を制御する方法として、中間表現を制御するステアリングがある
• 既存のステアリング手法の評価は、QAや選択問題などの制約がある
• 加えて、ヒューリスティックな方法であるため文脈などを取りこぼすことがある

💡問題解決に向けたキーアイデアは何か

• Sparse Auto Encoder(SAE)を使用して、介入する方向を決めること
  • エンコーダの出力が、入力次元数よりも大きいAuto Encoderのこと
• SAEが抽出したベクトル表現を使用して、Probingを行いそのタスクにおいて有効な特徴量を見つけている
  • 特徴量を見つけるために、F-Statisticを使用して次元削減をしているっぽい
  • これ以外にも、学習した線形モデル（Probe）の次元削減をするための工夫がある
• 複数のProbeを学習し、その平均ベクトルを介入ベクトルとする
• この介入ベクトルを最適化するために、追加の学習をすることで微調整する
  • ポジティブとネガティブに分類されたデータからSAEが抽出した特徴量に介入する
  • この介入後の特徴量が、ポジティブなデータとネガティブなデータの特徴量のセントロイドに近くなるように学習する
  • 加えて、言語モデル自体の損失関数や介入ベクトルに対するL1損失を制約として使用している

👀新たに分かったことは何か

• 性能的には、既存の介入手法よりも良いスコアになっている

• SAEにより抽出された特徴量が良くクラスを分類できる特徴量になっていることが分かった

  • SAEによる特徴量の抽出を用いた介入の有効性を示している

• Ablation Studyにより損失関数の必要性が示されている

  • Probeの学習を行わないと、出力文章の整合性や論理性が無くなる

  • 言語モデルの損失を無くすと、ベースになる言語モデルの応答を保持することが難しくなる

• 介入の方向については提案手法で良い方向を見つけることができたが、大きさについては未知である

❓疑問点は何か

• 手法が複雑だと思った
• SAEの学習やProbingの調整に必要な計算コストがどれくらいなのが気になる
• 評価にLLMを使用するのが適切であるかどうか分からない
  • 生成された文章が対象の文章を適切に反映できているのかを評価させている
• ベースモデルの評価が無いのが気になる
  • Ablation Studyに一応あった

📄論文情報

• APIGen: Automated PIpeline for Generating Verifiable and Diverse Function-Calling Datasets
• NeurIPS2024
• Salesforceの著者らによるもの

🔑この論文のキーメッセージ

• LLMのFunction Callingの性能向上のためには、多くのAPIに関する情報があると良い

🎓どういう問題に取り組んだのか

• Function Callingとは、自然言語の指示にの応答を生成するために必要なAPIを叩き、必要な情報を得るタスクのことを指す
• この論文では、このタスクの学習に必要なデータを自動生成するためのパイプラインを提案している

🧑‍🎓その問題に取り組むことがなぜ重要なのか

• 既存のfunction callingデータセットは実用のためには不十分である
  • 例えば、学習データ内で使用されているAPIが一部のカテゴリに偏っている場合、そのデータで学習されたLLMエージェントは他のAPIからのデータの取得ができなくなるという課題がある。
• そのため、多様なAPIを扱うデータセットが必要になる

💡問題解決に向けたキーアイデアは何か

• 提案手法は、データの生成と多段階によるフィルタリングから構成されている
• データの生成
  1. 既存のAPIを用いたQAペアをJSON形式に変する。
  2. プロンプトはデータ生成の目的になるテンプレートを選択し、QAペアを生成させる
  3. 生成されたペアをJSON形式に変換する
• 生成されたデータをフィルタするために以下の3つの方法を用いる
  1. フォーマットの検証：生成されたJSONのフォーマットが正しいか、APIの呼び出し時に適切な引数を指定しているか検証する
  2. 実行可能性の検証：データに含まれたAPIが実行可能であるか検証する、実行可能ではない場合、フィルターする
  3. 文法の検証：複数のLLMを用いて、目的を達成するための関数を呼び出すことができるかなどを総合的に評価する
• データの多様性を確保するために、テンプレートを複数用意することや、基データからどのようなデータをサンプリングするかを工夫している

👀新たに分かったことは何か

• ToolBenchを基データとして生成を行った

  • 基データとして活用するために、いくつかのフィルターを適用したの3500件を使用している

• 生成パイプラインを様々なLLMを用いて検証した所、小規模なモデルは無効なAPIを呼び出る例が多い

• 学習したモデルの評価はBerkley Function-Callingデータセットを使用している

• FCのために学習されたLLMはGPT-4oなどよりも良い性能を示している

  • 学習に使用しているLLMは1Bと7Bのモデルなので、より小規模なパラメータになっているかも？

• 各フィルタリングステップにおいて、フィルター後のデータを用いてモデルを学習し、評価した

  • 上の説明において、フォーマットの検証のみを適用したデータ、1と2を適用したデータ、全てを適用したデータに分けている
  • 評価結果としては、全てを適用したデータにより学習されたLLMの性能が最も良かった
  • このことから、提案したフィルター方法の有効性が分かる

❓疑問点は何か

• GPTとかのモデルの比較って平等な比較になっているのか疑問だった
• 生成されたデータの多様性の評価は行われていないのが気になった
  • プロンプトのテンプレやデータの持ってき方の工夫で十分なのかな

嫉妬という感情を巡る議論についての本だった。 とりわけ、嫉妬が類似している者同士の間に生じるものという指摘はとても分かるなあと思った。

妬まれないための戦略に、ロゴがデザインに組み込まれているハイブランドが嫌いである理由が言語化されている気がした。 戦略として、「隠蔽」「否認」「賄賂」「共有」という4つの戦略が挙げられていた。 この中の隠蔽については、妬みの対象となるものを隠す行動を指す。 ロゴが入っていることにより、隠蔽という戦略が無効になり、妬みが想起されてしまう。 これまでは上手く言語かできていなかったけど、上手く言語化されていて、腑に落ちた。

これまでの思想家が嫉妬についてどのように論じてきたかもまとめられていた。 会話の0.2秒を言語学するという本で、著者が哲学について、当たり前のことに理屈っぽく取り組んでいる様を面白がると良いとあった。 この本自体ぶ厚くないから、この面白さをを味わうのにとても良かった。

Emacsのlsp-modeでlua-language-serverを動かそうとしたら、ハマったのでメモ。

モテるターミナルにカスタマイズしよう（WezTerm）を見て、weztermを設定しようとした。

設定ファイルである wezterm.lua をEmacsで編集するためにluaの環境を整えようとしたら、Lua-language-serverを lsp-mode が認識しなかった。

加えて、自動でインストールしようとしたら、emacsがフリーズしてしまった。

動作させるために必要だった設定は以下の通り。

(setq lsp-clients-lua-language-server-bin (format "%s/.nix-profile/bin/lua-language-server" (getenv "HOME"))
      lsp-clients-lua-language-server-main-location (format "%s/.lua-language-server/main.lua" (getenv "HOME")))
; reference : https://github.com/emacs-lsp/lsp-mode/issues/4688#issuecomment-3138937688
(defun my/lsp-clients-lua-language-server-test ()
  "(Improved) Test Lua language server binaries and files."
  (or (and (f-exists? lsp-clients-lua-language-server-main-location)
           (f-exists? lsp-clients-lua-language-server-bin))
      (f-exists? (car (split-string lsp-clients-lua-language-server-command)))))

(advice-add #'lsp-clients-lua-language-server-test
            :override #'my/lsp-clients-lua-language-server-test)

lsp-mode自体にもIssueが上っていたためそれを参考にして設定したら動作した。

私はnixを使用してlua-language-serverをインストールしている。 インストールする時に、lua-language-serverの main.lua を適当な場所に配置する。

この main.lua の場所を lsp-clients-lua-language-server-main-location に設定し、 lsp-clients-lua-language-server-bin にlua-language-serverをインストールしたPathを設定する。

最後に、このIssueコメントにある関数をコピペしたら動いた。

参考 : Externally provided lua-language-server is not recognized #4688

このブログはHugoのGithub Styleを少し設定している。

デフォルトだと、自己紹介などがブログに埋もれてしまうためメニューバーに追加した。

現状、一つ加える度にhtmlを触らないといけない実装になっているのが気になるが、動いているからヨシ!

config.toml に以下の要素を追加して、設定ファイルに追記すれば要素が追加されるようにした。

[[params.self]]
  name = 'Self'
  url="introduction/introduction"

そして、作成したHugoプロジェクト以下に layouts/partial/menu.html を作る。

menus.html の追加のメニューとして以下の変更を加えた。

{{ range .Site.Params.projects }}
<a class="UnderlineNav-item
          {{ if .IsSection }}  selected  {{ end }}
          {{ if eq .Type " tags" }} selected {{ end }}"
   href="{{ absURL .url }}">
  {{ .name}}
</a>
{{ end }}

既存の実装では、リンクを貼る実装が {{urls.JoinPath .Site.BaseURL url}} になってる。

だが、上手く動作してくれなかったので {{absURL .url}} という実装にしている。

チェーンソーマン レゼ編を見た

漫画では分からなかったシーンが補完されていて、面白かった。

この映画では、爆弾の悪魔であるレゼと主人公であるデンジが出会い、戦うまでが描かれている。

デンジがレゼと祭りに行く辺りから戦闘に移行するまでの音楽の変化が印象的で、戦闘シーンの派手さが強烈だった。

デンジとレゼが祭りに言っている時は幸せそうな音楽なのに、戦闘が近づくにつれて不協和音が混ざっていく様子が、く、くる。。。という雰囲気がした。

祭り以外にも、戦闘中の曲にマキシマム・ザ・ホルモンの刃渡り二億センチがとてもマッチしていたのを覚えている。

戦闘シーンの派手さは強烈だった。

爆弾の悪魔だけあって、爆発のエフェクトや音、鮫の魔人が頑張って移動する様子が映像化されていて、より漫画を読むのが楽しめるようになったのが良かった。

鮫の魔人の移動の仕方が気持ち悪かったなあ。

この先の話もきっと映像化されるだあろうし、楽しみだ。