株式会社ずんだもん技術室AI放送局 podcast 20250513
内容紹介
Byte Latent Transformer: Patches Scale Better Than Tokens、LLMフレームワークのセキュリティリスク - LangChain, Haystack, LlamaIndex等の脆弱性事例に学ぶ、Embeddings are underrated
出演者
関連リンク
大規模言語モデル（LLM）の多くは、テキストを処理する際に、文章を「トークン」と呼ばれる単語や文字のまとまりに区切ります。この論文では、そういった事前準備としての「トークン化」を行わず、テキストの最小単位である「バイト」レベルで直接処理する新しい技術、「Byte Latent Transformer (BLT)」が提案されています。
BLTのポイントは、バイト列を固定長のトークンとして扱うのではなく、「パッチ」という単位で扱うことです。このパッチのサイズが特徴的で、データの内容に応じて自動的に長さを変えます。例えば、次に続くバイトが簡単に予測できるような、パターン化された情報が多い部分ではパッチを長くし、予測が難しい複雑な情報が多い部分ではパッチを短くするといった具合です。これは、次に予測すべきバイトの「予測しにくさ」を示す情報エントロピーに基づいて行われます。
このようにパッチのサイズを動的に変えることで、モデルは計算リソースを効率的に割り当てることができ、結果として推論（モデルを使って新しいテキストなどを生成する処理）の効率が向上します。また、特定のトークンセットに縛られないため、より多様なデータに対応しやすくなる（頑健性が高まる）と考えられます。
研究では、最大80億パラメータを持つBLTモデルを膨大なデータ（4兆バイト）で学習させ、その有効性を検証しました。実験から、トークン化なしで生バイトから学習できること、そして同じ計算コストで比較した場合、従来のトークンベースのモデルよりも性能を効率的に向上させられる（スケーリング性能が良い）ことが示されました。
この技術は、従来のLLMの仕組みに一石を投じるものであり、将来的にテキストだけでなく、バイト列で表現可能なあらゆる種類のデータ（プログラムコード、もしかすると画像や音声など）を効率的に扱えるようになる可能性を秘めています。LLMの基盤技術の進化として注目に値する研究です。
引用元: https://arxiv.org/abs/2412.09871
この記事は、近年普及しているLLM（大規模言語モデル）を使ったアプリケーション開発を効率化する「LLMフレームワーク」に潜むセキュリティリスクと対策について、新人エンジニア向けに分かりやすく解説しています。
LangChainやLlamaIndexといったLLMフレームワークは非常に便利ですが、その機能の裏には新たなセキュリティリスクが生まれています。特に注意すべき点は二つあります。一つは、フレームワークが提供する「実験的な機能」や「非推奨のオプション」を安易に使うことです。例えば、LangChainにはLLMにPythonコードを実行させる機能や、危険なリクエストを許可するオプションがあり、これらを不用意に使うと、攻撃者にサーバー上で任意のコードを実行されてしまう（RCE：Remote Code Execution）脆弱性につながる可能性があります。この教訓として、実験的な機能や非推奨オプションは、本当に必要か設計段階でよく考え、可能な限り使わないことが重要です。
もう一つは、LLMフレームワークそのものの実装に潜む脆弱性です。記事では、LangChain, Haystack, LlamaIndexなどの実際の脆弱性事例を挙げて解説しています。
- SSRF (Server Side Request Forgery): 外部から指定されたURLにサーバーがリクエストを送信してしまう脆弱性。LangChainのWebクロール機能で、URLの検証が不十分だった事例があります。対策は、外部URLは許可リスト方式で厳しくチェックすることです。
- Path Traversal: 外部入力値を使ってサーバー上のファイルに不正にアクセスされてしまう脆弱性。LangChainjsのファイル読み込み機能で、パス名の検証が漏れていた事例があります。対策は、パス指定には「../」のような特殊文字を制限することです。
- SQL Injection: 外部入力値で意図しないSQLを実行されてしまう脆弱性。LangChainのSQL操作機能で、LLMが生成したSQLの検証が不十分だった事例があります。対策は、Prompt Injectionを防ぎ、LLMに与える権限を最小限にし、入力値をしっかり検証することです。
- RCE: 外部コマンド実行機能で、危険なインポートなどができてしまう脆弱性。LangChainのPythonコード実行機能で、特定の関数が禁止されていなかった事例があります。対策は、外部コマンド呼び出しが本当に必要か再検討し、使う場合はサンドボックス化や安全な関数を使うことです。
- Server-Side Template Injection (SSTI): テンプレートエンジンに不正なコードを注入され、サーバーで実行されてしまう脆弱性。Haystackのプロンプトテンプレート機能で、テンプレートの検証やサンドボックス化が不十分だった事例があります。対策は、テンプレート構文とユーザーデータを分離し、データは適切にエスケープすることです。
- DoS (Denial of Service): サーバーのリソースを大量消費させてサービス停止に追い込む攻撃。LlamaIndexのストリーミング処理で、型チェックやタイムアウト処理がなかった事例があります。対策は、リクエストやプロセスが使用できるリソースに上限（タイムアウト含む）を設けることです。
これらの事例から、LLMフレームワークを利用するだけでなく、独自に機能を実装する際にも、従来のWebアプリケーション開発で注意すべきセキュリティ対策（入力値の検証、出力値のエスケープなど）が引き続き非常に重要であることが分かります。フレームワークの機能を使う際も、その内部でどのような処理が行われるかを理解し、ユーザーからの入力やLLMの出力が想定外の挙動を引き起こさないよう、アプリケーション側でも多層的な防御策を講じることが不可欠です。
LLMフレームワークは開発効率を高めますが、セキュリティリスクを理解し、適切に対策を講じながら使うことが、安全なAIアプリケーション開発には欠かせません。
引用元: https://blog.flatt.tech/entry/llm_framework_security
** この記事は、技術文書作成においてAIが革新をもたらす可能性に触れつつ、テキスト生成モデル（GPTなど）ではなく、Embeddingsという技術が秘める大きな力について解説しています。
Embeddingsを一言でいうと、「テキストを数値の配列（ベクトル）に変換する技術」です。例えば、「Hello, world!」という短い文章でも、文書全体のような長いテキストでも、Embeddingsモデルにかけると、同じ数の数値が並んだ配列が得られます。この数値配列が、そのテキストの意味的な特徴を表しているのです。
この数値配列は、まるで地図上の「座標」のようなものだと考えると分かりやすいです。ただし、私たちが普段考える2次元や3次元ではなく、数百〜数千次元の空間における座標です。この「意味の多次元空間」では、意味的に似ているテキストは近い場所に、そうでないテキストは遠い場所に配置されます。
重要なのは、この多次元空間における「座標間の距離」を計算することで、どんなテキスト同士でも、数学的に意味的な近さを比較できるようになる点です。「王様 - 男性 + 女性 ≒ 女王様」という有名な例のように、Embeddingsは単語だけでなく、文章やドキュメント間の複雑な意味的な関係も捉えることができます。
Embeddingsは、GeminiやVoyage AIなどのAPIを使えば比較的簡単に生成でき、コストも高くありません。モデルによって対応できるテキストの長さなどが異なるため、目的に合ったモデルを選ぶことが大切です。
具体的な応用例としては、大量のドキュメントがある場合に、あるドキュメントと意味的に関連性の高いドキュメントを自動で見つけ出す、といったことが可能になります。記事では、技術ドキュメント作成ツールであるSphinxを使って、各ドキュメントのEmbeddingsを生成し、関連性の高いドキュメントを推薦する実験結果を紹介しています（例: ある変更履歴のページに関連する別の変更履歴ページが見つかるなど）。
このようにEmbeddingsは、テキストの意味的な関連性を大規模に発見・比較する強力なツールであり、技術文書作成のような分野でも、コンテンツの整理や関連コンテンツの推薦など、様々な可能性を秘めています。
引用元: https://technicalwriting.dev/ml/embeddings/overview.html
（株式会社ずんだもんは架空の登場組織です）