少し余裕ができたのをいいことに無限にあれこれ検証してるんだけど、自分LLM無職できます、やらせてください！　みたいな気持ちになってきた（そろそろ実作業をしようね）

自分がそうでないのでよくわからんのだけど、𝕏のクリエイター収益分配プログラムで年収1000万近く得たとする。その区分が雑収入扱いだとすると、その場合、今だったらAI関係のクソ高いサブスクとかハードウェア機材費って、経費で落とせるんだろうか？ 個人事業主がAI関連で業務委託している場合には、経費化できるけど、𝕏のポストに対する分配の場合、どうなんだろう？そもそも減価償却の対象にもしにくいしな…。 そんなことを疑問に思ってたら、GPT-5.5 Proが割とまともな回答をくれた。参考になるのでまとめておこう。 仮に、AIについて発信して年1,000万円近く稼ぎ、その制作・調査に生成AIサブスクやワークステーションを常用しているなら、相当程度は経費として認められやすいと考えられる。 一方、𝕏の内容とほぼ関係なく、将来使うかもしれないという理由だけで高額GPUや多数のAIサービスを購入した場合は弱くなる。この場合、購入しただけでなく、年内に実際に業務へ投入していることが重要。要するに「欲しいから」というのは理由にならなくて、実際に業務的に使っているのがポイントになる。 なお、「100万円を経費にしたら100万円戻る」という仕組みではなく、課税対象となる所得が100万円減るだけ。 また、売上が1,000万円付近になると、所得税だけでなく消費税の1,000万円基準も問題になる。個人事業者では原則として前々年の課税売上高などで判定するが、𝕏の支払主体が国外法人の場合は取引内容の確認が必要となる。 要するに、「雑所得でもAI費用は落とせる。ただし年1,000万円規模なら事業所得の可能性が高く、事業所得＋青色申告の方が機材費の処理上も有利になりやすい」という整理とのこと。確定申告は青色でキッチリとやったほうがいいということですね。 「LLM無職」、「無職」という割にはそれなりに仕事することになりますね。

LLMに回答の自信度を数値化させるのは無意味では、という主張。 ・LLMに0から100の自信度を出力させる手法がよく見られる ・しかし、LLMに自信度を自己評価させるのは完全に無意味 ・科学的な根拠はなく、出力が信頼できそうに見えるだけの心理的なトリック ・Anthropicの研究などで、モデルが内省的な認識を持つことは確認されている ・ただ、それは実験環境での話であり、実際の出力の正しさを評価できるレベルにはない ・思考プロセスを用いて自己評価させても「その自信度の自信度は？」という無限ループに陥る ・実際にDeepMindの論文でも、外部フィードバックなしの自己修正は性能を低下させることが示されている ・現在のモデルは、自らの状態を定量化できるほど自分自身を理解していない ・そもそも、スコア化しようとする自信の定義が極めて曖昧 ・回答の正確性なのか、一貫性なのか、ユーザーの目的を満たそうとしているのか ・全く異なる次元の問題を単一の数値に押し込めるのは無理がある

LLMは数学の問題で人間より高い正解率を出せるようになりました。でもそれは「きちんと積み上げて理解している」からでしょうか？ タイトル: Do LLMs Exhibit Coherent Knowledge Structures in Mathematical Reasoning? A Perspective from Knowledge Space Theory URL: ❓ LLMは前提知識をきちんと積み上げて正解しているの？ 💡 正解率自体は人間79.6%に対しLLM最高92.5%（Qwen3-80B）と上回りますが、前提を完全に満たした上での正解の割合は人間72.7%に対しLLMは48.16%にとどまります。正解していても土台が抜けているケースが多いということです。 ❓ 前提知識をヒントとして教えてあげれば改善する？ 💡 実は前提に基づくヒントを与えても、無関係な例を与えた場合とほとんど差が出ませんでした。構造的な前提推論ではなく、表層的なパターンマッチングに頼っている可能性が高いです。 ❓ 賢いモデル同士なら、似たような知識の持ち方をしているはず？ 💡 人間の学習者グループ間では知識の重なりが0.9以上と高いのに対し、LLM同士では0.38〜0.6程度しか重なりません。強いモデルほど人間から離れていく傾向も見られました。 ❓ つまりこの研究が示しているのは？ 💡 精度という指標だけでは、LLMの「理解の仕方」のズレは見抜けないということです。知識空間理論という新しい評価レンズを使うことで、正解率の裏にある断片的な知識構造が浮かび上がります。 #LLM評価# #数学的推論#

【LLM時代のデータ基盤アーキテクトを募集】 - 1,000万人超えの大規模データを活用 - 経営陣含め、データ利活用の文化が根付く組織 「データを使って事業を伸ばす」その意思決定を支える基盤開発に携わってみませんか？ 👇Findyで求人をチェック（登録無料）

【LLM時代のデータ基盤アーキテクトを募集】 - 1,000万人超えの大規模データを活用 - 経営陣含め、データ利活用の文化が根付く組織 「データを使って事業を伸ばす」その意思決定を支える基盤開発に携わってみませんか？ 👇Findyで求人をチェック（登録無料）

LLMにおけるハルシネーションは、大きく真偽接地問題と汎化の問題から生じていると整理できる。 真偽接地問題とは、生成した命題の真偽を外界の事実とどのように結びつけるかという問題である。なお、真偽接地問題はここで用いる私の造語である。 言語的なもっともらしさと、外界における命題の真偽は異なる。しかし、通常の言語モデルは主として言語分布を学習しており、この二つを直接区別するようには学習されていない。 これと関連する概念として、記号接地問題がある。記号接地問題とは、記号の意味を外界にどのように結びつけるかという問題である。例えば「りんごは赤い」という文の意味は、単なる「りんご」「赤い」という記号同士の関係だけで決まるのではなく、それらが実世界の対象や知覚とどのように対応しているかによって定まる。 これに対して、ここでいう真偽接地問題は、ある命題の真偽を外界の事実にどう結びつけるかという問題である。例えば、ある会社の代表者として無関係な人物を挙げたり、存在しない製品名を生成したりする場合、その出力は単語列としてはもっともらしくても、外界の事実とは対応していない。 概念的には、 p(true | 命題, 外界) を推定できるかどうかの問題と捉えることができる。 もう一つは、汎化、あるいは平滑化の問題である。言語モデルは有限の訓練データから学習するため、訓練中に観測していない系列に対しても適切に確率を割り当て、汎化する必要がある。 従来の言語モデルでも、一度も学習中に観測していない単語列に確率0を与えてしまうことは大きな問題だった。そのため、頻度ディスカウントや平滑化によって、既観測系列に割り当てられた確率の一部を未観測系列へ移していた。 ニューラル言語モデルは、分散表現による汎化によって、この平滑化問題を驚くほど自然に解決した。訓練中に一度も見ていない単語列であっても、その意味や文脈が既知のものと似ていれば、もっともらしい確率を割り当てることができる。 しかし、この強力な汎化能力は、事実を扱う場合には副作用を持つ。正解が一意に定まる事実についても、観測していない誤った候補に確率を与えてしまうからである。汎化する能力そのものが、ハルシネーションの原因にもなりうる。 さらに、この二つの問題は独立というより、相互に関係している。真偽が十分に接地されていないために正しい候補を識別できず、その不確実性の中で平滑化・汎化が働くことで、もっともらしい誤った候補にも確率が乗る。 真偽接地問題については、学習時に言語表現と外界の状態や検証可能な事実との対応を明示的に与えることで、ある程度解決できる可能性がある。 ただし、外界そのものの定義も単純ではない。現実世界だけでなく、あるゲーム世界、ある人物が信じている世界など、命題の真偽は前提とする世界や文脈によって変わりうる。この点まで含めて、どの世界に対する真偽なのかを接地する必要がある。 一方、汎化の問題も本質的にどこまで解決できるかは分からない。未観測例への汎化は、有限データから学習するために不可欠である。そのため、未知の対象にも確率を与えるという性質そのものをなくすことはできない。 必要なのは、汎化に任せる領域と、厳密な制約や構造化された情報によって扱う領域を組み合わせることだろう。 特にロングテールの情報、すなわち学習中に一度から数回しか観測されない事実を扱う場合、汎化だけによって高い網羅性とほぼ完全な正確性を同時に実現することは難しい。この領域では、ある程度の誤りを受け入れるのか、それとも外部知識・検証器を利用して回答範囲を制限するのか、という選択が必要になる。

長いコンテキストのLLM推論、KVキャッシュをディスクに逃がすべきかGPUで再計算すべきか、実は「常に正解」は存在しません。それを定量的に判断する仕組みを作った論文です。 タイトル: Building py-kvcache: A Performance Characterization of External KV Caching for vLLM with NVMe SSDs URL: 📝 概要 vLLM向けの外部KVキャッシュシステム「py-kvcache」を提案。io_uringによる非同期I/OでPython実装ながらSSDの読取帯域13.5GB/sをほぼフルに引き出します。 ❗ 解決する課題 既存の外部KVキャッシュ（LMCacheなど）は「いつ使うべきか」の判断基準を持たず、短いプリフィクスや高速GPUでは再計算の方が速いのに無条件にディスクから読み込んでしまう問題がありました。 ⚙️ 方法論 リクエストの待機時間中にディスク読込を先行させる「スケジューラ認識プリロード」と、TTFT改善が見込めない場合はロードを拒否する「ブレークイーブンゲート」を導入しています。 📊 実験結果 LongBenchのマルチ文書QAでGPU再計算比6.02〜7.43倍、LMCache比2.77〜3.64倍高速化。マルチターンのSCBenchでは、ネイティブvLLMのディスク読取3.4TBに対しpy-kvcacheは85GBに抑え、完了時間も1200秒超から480秒へ短縮しました。 🖥️ ユースケース H100のような高性能GPUでは外部キャッシュなしでも十分高速なのに対し、RTX 4000 Adaのような手元のGPUでは外部キャッシングが明確に有効という、ハードウェア次第の判断指針も提供しています。 #LLM推論# #vLLM#

# AIエージェントをソフトウェアに組み込むプラクティス # メモリ書込ゲート 🎯 LLMの推測がそのまま長期メモリに入り、次のセッションで「事実」として参照される。メモリ汚染は沈黙のうちに蓄積します。 長期メモリへの書込にバリデーションを設けるのは、DBへの入力検証と同じ原則です。 🔥 解決する課題 長期メモリへの書込は「一度入ったら長く残る」不可逆に近い操作です。書込ゲートがなければ3つの問題が連鎖します。エージェントが生成した誤情報がそのまま保存されハルシネーションが自己強化する。外部入力に埋め込まれた悪意ある指示がメモリに書き込まれ、将来のセッションまで攻撃が持続する。同じ事実が微妙に異なる表現で何度も保存され、検索時に矛盾が返って応答品質が劣化する。メモリ汚染はログにエラーを残さないため、発見が特に遅れます。 💡 提案パターン 長期メモリへの書込を無条件に許可せず、信頼度スコアリング・重複検出・PII/機微情報フィルタ・ソース検証のゲートを設けます。ユーザが直接述べた事実は自動書込、推測や未検証情報は隔離領域に留め置き、人間または上位エージェントの承認を待ちます。重複検出ではコサイン類似度0.90〜0.95を閾値とし、同一エンティティ×同一属性なら上書きします。input_trustが低いほど信頼度閾値を上げ、failure_costが高い領域ではさらに厳格にします。 ✅ 選定条件 使うとき： - セッションを跨いで持続する長期メモリを持つ - エンドユーザの自由入力や外部ドキュメントからメモリ候補を抽出する - 誤った記憶が金銭的判断・医療助言・法的回答など後続の意思決定に影響する 使わないとき： - メモリがセッション内スクラッチパッドのみで、セッション終了時に破棄される場合 - メモリが完全に管理者管理でエージェントは読取専用の場合 ⚠️ 落とし穴 - 隔離領域は承認フローが回らないと肥大化します。TTL（7〜30日）を設け未承認は自動破棄してください - エンベディングの類似度だけでは「同じ人物の異なる属性」と「同一属性の更新」を区別できません。構造化メタデータを併用しましょう - メモリストアへの直接書込パスが残っていると、ゲートが完全に無意味になります 🔧 実装方針 - 書込ゲートを重複検出→信頼度スコアリング→PII/機微情報フィルタの3段パイプラインとして構成し、全書込を必ずこのゲートを経由させます - 信頼度スコアリングではソース（ユーザ直接/エージェント推論/外部文書）とグラウンディング（引用あり/なし）の組み合わせで分類し、閾値未満は隔離領域に留め置きます - 重複検出ではコサイン類似度に加えてエンティティID×属性キーの構造化メタデータを併用し、更新と新規を正確に区別します - 隔離領域にはTTLを設けて未承認エントリを自動破棄し、メモリストアへの直接書込APIはアーキテクチャ制約として禁止します #AIエージェント# #ソフトウェアアーキテクチャ#

# AIエージェント開発の意思決定ポイント # トレース・サンプリング率｜Trace Sampling Rate 🎯 ポイント エージェントのトレース、全量記録していますか？それとも全く記録していませんか？ 「全量か無か」ではなく「何を全量にするか」が正しい問いです。AIエージェントの1リクエストは数千〜数万トークンのトレースデータを生成します。全量記録すると観測コストが爆発し、記録しなければ障害時に原因究明が不可能。条件付きサンプリングがこのジレンマを解決します。 📋 概要 トレース・サンプリング率は、エージェントの実行トレース（各LLM呼び出し、ツール実行、意思決定のステップごとの記録）をどの割合で収集・保存するかを制御するパラメータです。100%ならすべてのリクエストのトレースを記録し、1%なら100リクエストに1件だけ記録します。 AIエージェントのトレースは従来のWebサービスのログとは質的に異なります。プロンプト全文、出力全文、ツール引数・戻り値、中間的な推論ステップなどを含めると、1リクエストで数十KB〜数百KBのデータが生成されます。さらにLLMの出力は確率的なため、「同じ入力を再投入すれば再現できる」という前提が成り立ちません。 🔍 意思決定のポイント サンプリング率はaccountability（説明責任）とcost_sensitivity（コスト感度）のバランスで決まりますが、最も重要なのは条件付きサンプリングの設計です 🎯 一律の確率ではなく、リクエストの属性に応じて率を変えます。 判定基準の優先順位: 1. エラー/例外が発生したリクエスト → 100%記録（必須） 2. HITL（人間介在）が発生したリクエスト → 100%記録 3. 高リスク操作（副作用あり、不可逆）を含むリクエスト → 100%記録 4. レイテンシがP95を超えたリクエスト → 100%記録 5. コストが閾値を超えたリクエスト → 100%記録 6. 成功したリクエスト → 標本率で記録（1〜10%） 💡 要点と詳細 目安値 📊 - エラー/例外発生 → 100%。再現性のない障害のデバッグに不可欠 - HITL発生（人間承認/エスカレーション） → 100%。承認判断の妥当性を事後検証 - 高リスク操作（送金、データ削除等） → 100%。不可逆操作の監査に必須 - レイテンシP95超過 → 100%。性能劣化の根本原因分析に必要 - 成功かつ低リスク → 1〜10%。品質の統計的モニタリングに十分 - 開発・ステージング環境 → 100%。コストが問題にならない範囲で全量記録 トレースの粒度をサンプリング率とは別に制御するのも重要です 📦 全量記録するリクエストでも、プロンプト全文はコールド層に、メタデータ（モデル名、トークン数、レイテンシ、ステータス）はホット層に分離します。 ⚖️ トレードオフ サンプリング率が低すぎると、障害の再現が不可能になります 🔍 LLMの出力は確率的なため、同じプロンプトを再投入しても同じエラーが再現するとは限りません。品質劣化の見逃し、監査要件の不達成、コスト異常の遅延検知も深刻なリスクです。 サンプリング率が高すぎると、観測コストが本番のLLM呼び出しコストに匹敵するか上回ることがあります 💸 パフォーマンスへの影響、PII（個人情報）の拡散リスク、大量データ中の信号がノイズに埋もれる問題も発生します。 サンプリング率は運用開始後に段階的に下げてください。最初は高い率（50〜100%）で始め、安定性を確認してから成功リクエストの率を徐々に下げます。 🛠️ ユースケース サンプリング判定はリクエストの終了時に行うことも検討してください 🔄 head-based sampling（開始時に決定）は実装が簡単ですが、エラーが発生するかどうかは事前に分かりません。tail-based sampling（完了後に決定）なら結果に基づいて判定できます。ただし中間データを一時的にバッファする必要があります。 correlation ID（trace ID）の伝播を確実にしてください 🔗 マルチステップのエージェント実行では、最初のリクエストから最後のツール呼び出しまで一貫したtrace IDが紐づいていないと、部分的なトレースしか得られません。非同期処理やキューを介する場合にIDが途切れやすいので要注意です。 ホット/コールド分離と組み合わせるのが効率的です。サンプリングされたトレースはコールド層に全文を、それ以外はホット層にメタデータのみを記録する構成が実用的です。 #AIエージェント# #ソフトウェアアーキテクチャ#