関連リンク

• 「9.11 > 9.9」から始めるLLMの計算間違い探索 / 開発者向けブログ・イベント GMO Developers

この記事は、GMO Developersのブログ記事で、大規模言語モデル（LLM）が簡単な数値計算で誤答する事例とその原因、そして改善策について解説しています。 ChatGPTなどのLLMが「9.11 > 9.9」といった単純な大小比較を間違える現象を検証しています。

複数のLLM（GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro、Llama3 70b Instruct）を用いた実験では、LLMは小数点以下の桁数や、文字列中の特定文字の数を正確に数えることに苦手意識を示しました。 例えば、「strawberry」の「r」の数を数える問題でも、多くのLLMが誤答しました。

この原因として、トークナイゼーション（テキストを意味を持つ最小単位に分割する処理）の影響が考えられますが、記事では、LLMが数値計算を理解していないことが本質的な原因だと主張しています。LLMは過去の学習データから「それらしい」回答を生成しているだけで、真の意味で計算をしているわけではない、というのです。 これは、桁数の大きな掛け算でも確認されており、LLMは学習データに多く含まれる3桁以下の数値計算は得意ですが、それ以上の桁数になると誤答が多くなります。 さらに、誤答を指摘しても、LLMはそれを容易に受け入れてしまう傾向が見られました。

改善策として、LLMに直接計算させるのではなく、LLMにプログラムを作成させ、そのプログラムを実行させる方法が提案されています。 「プログラムを実行して回答してください」というシンプルな指示で、LLMは正確な計算結果を返すコードを生成し、実行することが可能です。

結論として、この記事は、LLMの能力と限界を理解し、適切な道具として使いこなすことの重要性を強調しています。 LLMは万能ではなく、数値計算のような正確性が求められるタスクには、プログラムとの連携が不可欠であることを示しています。 新人エンジニアは、LLMの特性を理解し、その能力を最大限に活かすための適切な活用方法を学ぶ必要があります。

引用元: https://developers.gmo.jp/technology/48648/

• UNIQUE制約の理解が甘くて二重にインデックスを張りそうになった件

PostgreSQLを用いたデータベース設計において、UNIQUE制約とインデックスの理解不足からパフォーマンス問題に遭遇した事例です。新人エンジニアが、採用管理システムの機能開発中に、オペレータとセミナーの多対多関係を表すassigned_seminarsテーブルを作成する必要に迫られました。 このテーブルには、website_id, operator_id, seminar_idといったカラムが含まれます。

複数のオペレータが担当するセミナーを検索するクエリと、特定セミナーの担当者を検索するクエリの両方を想定し、website_idとoperator_idの組み合わせにUNIQUE制約とインデックスを作成しました。しかし、上司からのレビューで、インデックスが重複している可能性を指摘されました。

そこで、以下の5パターンで実験を行いました。

1. 制約・インデックスなし


2. UNIQUE制約のみ(website_id, operator_id, seminar_id)


3. インデックスのみ(website_id, operator_id)


4. UNIQUE制約とインデックス(website_id, operator_id, seminar_idとwebsite_id, operator_id)


5. UNIQUE制約のみ(website_id, seminar_id, operator_id)

大量のテストデータを用いて、特定のオペレータが担当するセミナーを検索するクエリの実行時間を比較しました。その結果、インデックスがない場合(1, 5)は実行時間が非常に長く、UNIQUE制約のみ(2)、インデックスのみ(3)は実行時間に大きな差がないことが分かりました。 さらに、UNIQUE制約とインデックスの両方を持つ場合(4)も、UNIQUE制約のみの場合(2)と実行時間に差がありませんでした。これは、PostgreSQLがUNIQUE制約を宣言したカラム順にインデックスを自動生成しているため、重複したインデックスを作成していたことを意味します。

さらに、新規データ挿入時のパフォーマンスも検証しました。 複数の担当者をセミナーに追加するINSERTクエリを実行した結果、インデックスが重複している場合、挿入にかかる時間が増加することが確認されました。ただし、このテーブルでは項目数が少なく、その影響は限定的でした。しかし、項目数が多いテーブルや、複雑なインデックスを持つテーブルでは、より顕著なパフォーマンス低下が予想されます。

この事例から、PostgreSQLではUNIQUE制約によって自動的にインデックスが作成されるため、重複したインデックスを作成しないよう注意が必要であることが分かりました。 テーブル設計時には、想定されるクエリを考慮し、適切なインデックスを作成することが重要です。 また、インデックスの重複はデータの挿入コスト増加につながるため、注意深く設計する必要があります。 この経験を通して、データベース設計におけるインデックスの重要性を再認識し、今後の設計やレビューに活かしていくと結論付けられました。

引用元: https://developers.techouse.com/entry/unique-index-conflict

• VSCodeでホバー時のTypeScriptの型ヒントをすべて表示する

この記事は、Visual Studio Code (VSCode) でTypeScriptの型ヒントをホバー表示する際に、プロパティが多いと型ヒントが省略されてしまう問題の解決策を説明しています。

問題の原因は、VSCodeのTypeScript言語サーバが、型ヒントの表示行数をデフォルトで160行に制限しているためです。 tsconfig.json に noErrorTruncation: true を追加しても解決しません。これはエラー時の型ヒント省略を防ぐオプションであり、今回の問題とは関係ありません。

解決策として、Node.jsスクリプトを用いて、言語サーバが参照するファイル内の defaultMaximumTruncationLength の値を直接変更する方法が提示されています。 このスクリプトは、VSCodeのTypeScript拡張機能のインストールディレクトリを指定し、表示行数の最大値を指定することで動作します。例えば、VSCodeのインストールディレクトリが~/.vscodeの場合、最大表示行数を1000行に設定するには、以下のコマンドを実行します。

node changeTypeScriptHover.js ~/.vscode 1000

このスクリプトは、vscode-typescriptを含む拡張機能ディレクトリを検索し、該当するJavaScriptファイル内のdefaultMaximumTruncationLengthを指定した値に書き換えます。 スクリプトの内容は、ファイル読み込み、置換、書き込みを行うシンプルなものです。 記事では、VSCodeの拡張機能を利用する方法もあると触れられていますが、自身で管理できる方法に焦点を当てています。

新人エンジニア向けに補足すると、この方法はVSCodeの内部ファイルの書き換えを伴うため、注意が必要です。 バックアップを取ってから実行し、問題が発生した場合は、元の状態に戻す準備をしておきましょう。 また、VSCodeの更新などによってスクリプトが動作しなくなる可能性があるため、その際はスクリプトの修正が必要になるかもしれません。 より安全な方法として、VSCode拡張機能の利用を検討することもできます。

引用元: https://zenn.dev/karan_coron/articles/dcab49bed5b2ff

• お便り投稿フォーム

（株式会社ずんだもんは架空の登場組織です）