デイリーAIダイジェスト — 2026-09-26
Hacker News シグナル
Goにおけるプラットフォーム非依存のSIMD
Goの標準ライブラリとランタイムは長い間、SIMD高速化パス（AES、SHA、CRCなど）に手書きのアセンブリを依存してきました。そのため、ターゲットアーキテクチャ（amd64、arm64、s390xなど）ごとに個別の実装が必要となります。本記事で説明する実験では、プラットフォームごとのアセンブリを必要とせず、アーキテクチャ固有のベクター命令にコンパイルされるポータブルなSIMD抽象化レイヤーを提案しています。
この設計では、固定幅のベクター型（Vector[T, N]）と組み込み関数スタイルの操作セットを持つsimdパッケージが導入されます。コンパイラバックエンドは、コード生成時にこれらを適切なISA intrinsicsに変換します――x86-64ではSSE/AVX、arm64ではNEON、といった具合です。設計上の核心的なトレードオフは表現力とポータビリティのバランスです。この抽象化は、パフォーマンスを損なわないほど十分に豊かでありながら、一部のターゲットで合理的な対応がない操作を露出しないものでなければなりません。
本記事では、新しいAPIを用いて書き直されたSHA-256の具体的な実装を詳しく解説しており、ポータブル版がamd64とarm64の両方において手書きのアセンブリのスループットに匹敵することを示しています。ベンチマークでは、既存のcrypto/sha256のアセンブリパスとほぼ同等のMB/sが得られています。
未解決の問題としては、幅可変なSIMD（AVX-512対128ビットNEON）の扱い方、水平方向のreductionを抽象化でクリーンに表現できるか、そしてコンパイラが明示的なベクター型を必要とせずにこの上でループをauto-vectorizeできるか、といった点が挙げられます。この実験はGoのツールチェーンにはまだマージされておらず、明示的に探索的なものとして位置づけられています。
システムプログラマにとって興味深い制約は、GoのCGoなし・intrinsicsなしという哲学です。この設計は<immintrin.h>への薄いラッパーとしてではなく、型システムとコンパイラIRの中に完全に収まらなければなりません。IRがアーキテクチャ固有の形に化けることなく、高度なシャッフルパターン（VPSHUFB、TBL）を表現するのに十分な表現力を持てるかどうかが、中心的な未解決問題です。
Source: https://go.dev/blog/simd-experiment
Avast アンチウイルス サンドボックスへの侵入と脱出 Part 2
これは、Avast のユーザーモード サンドボックスを標的とした CVE-2025-13032 に関する詳細なエクスプロイト チェーンの解説記事です。Part 1 ではサンドボックス内でのコード実行の取得を扱いましたが、Part 2 ではそこからの脱出に焦点を当てています。
Avast のサンドボックスは、プロセス分離とカスタムのシステムコール インターセプト レイヤーを組み合わせて使用しています。脱出テクニックは、サンドボックスのファイル ハンドル検証における TOCTOU 競合を利用しています。サンドボックス化されたプロセスがリソースへのハンドルを要求すると、ブローカーはパスを検証してからハンドルを返しますが、正規パスの解決と実際のオブジェクトのオープンはアトミックではありません。検証と使用の間にシンボリックリンクの置き換えを競合させることで、攻撃者はサンドボックス境界の外にある任意のパスへオープン操作をリダイレクトできます。
2 つ目のプリミティブはサンドボックスの IPC メカニズムに関するものです。ブローカーは、サンドボックス化されたプロセスが昇格操作を要求するための名前付きパイプを公開しています。研究者たちは、メッセージのデシリアライゼーションがオブジェクトのライフタイムを正しく検証していないことを発見しました。これにより、より高い権限で動作するブローカー プロセス内で use-after-free が発生します。ファイル ハンドルの混乱と解放された領域への制御されたアロケーションを組み合わせることで、ブローカーへの write-what-where が実現し、サンドボックス外でのコード実行につながります。
この解説記事は技術的に精密で、関連する IPC メッセージ構造体、競合ウィンドウの分析（マイクロ秒単位で計測されており、確実にヒットさせるためにはスピニング スレッドが必要）、および UAF のためのヒープ グルーミング シーケンスが含まれています。エクスプロイトにカーネルのバグは一切必要とせず、チェーン全体がユーザー空間に留まっている点がより興味深い結果です。Avast のサンドボックス モデルはブローカーをハードな境界と見なしているようですが、IPC サーフェスはシステムコール インターセプト レイヤーと同じ厳密さで監査されていませんでした。
パッチの状況: CVE に記載されたバージョンで修正済みです。
OpenAI GPT-6 AstraがEnigmaメッセージを解読——2005年以来未解決だった暗号文
MVUEHメッセージは1944年のEnigma傍受文であり、約60文字という短い暗号文で、Cipher Mysteries / crypto cellarの未解決リストに約20年間掲載されていました。その困難さは、短い暗号文（統計的攻撃には長さが必要です）、未知のインジケータ設定、そして原文の転写における曖昧さの組み合わせに起因しています。
報告された解読では、GPT-6 “Astra”を古典的なhill climbing復号エンジンとループ接続して使用しています。LLMの役割は暗号を直接解読することではありません——Enigmaは決定論的なローター機械であり、鍵空間の探索は言語モデリングの問題ではなく組み合わせ論的問題です。その代わり、LLMはヒューリスティックなfitness評価器として、また転写の曖昧さを解消するために用いられています。具体的には、hill climberから得られた候補平文に対して、モデルがドイツ軍事通信としての妥当性をスコアリングし、暗号文の統計的異常を説明しうる文字レベルの転写エラーを特定します。
主張されている平文は短い気象観測メッセージです。方法論は精査に値します。hill climberは一致指数（index of coincidence）とbigram scoringを主要なfitness関数として使用しており、LLMはトップN候補のスコアが狭い範囲に収まっている場合にのみ呼び出されます。これは合理的なアーキテクチャです——モデルは低レベルの探索ではなく、高レベルの意味的曖昧性解消のために使用されています。
主な留意点は検証可能性にあります。平文はフォーマットおよび当時の語彙として妥当に見えますが、独立した確認のためには、鍵設定を再現し、1944年半ばにそのネットワークで使用されていた既知のEnigmaバリアントと照合してローターおよびリフレクターの組み合わせを検証する必要があります。暗号解析コミュニティは、この問題を最終的に解決済みと認定する前に、そうした検証を求めるでしょう。
Source: https://www.cryptocellar.org/bgac/the-mvueh-break.html
HTTPの最も厄介な部分をサポートするようになりました：Vary
HTTPのVaryレスポンスヘッダーは、キャッシュに対して、保存されたレスポンスのキーがURLだけでなく特定のリクエストヘッダーにも基づくことを伝えます。例えば、Vary: Accept-Encodingは、gzip圧縮されたレスポンスと非圧縮のレスポンスが同一URLに対して異なるキャッシュエントリであることを意味します。CloudflareのキャッシュはこれまでVaryの処理を無視するか簡略化していましたが、この記事では正しく汎用的なVaryサポートを実装した経緯について説明しています。
このエンジニアリング上の問題は単純ではありません。URLのみをキーとするキャッシュはシンプルなキーバリューストアですが、Varyを加えると多次元的なルックアップになります。つまり、各URLに対してk個の異なるヘッダーの組み合わせが存在し、それぞれに固有のキャッシュされたレスポンスが伴います。Cloudflareのエッジは、分散キャッシュインフラ全体でこれらのバリアントを効率的に保存・検索する必要があります。
実装では、各バリアントを個別のキャッシュオブジェクトとして保存し、そのキーはURLとVaryに列挙されたヘッダーの値を正規化したハッシュから導出されます。正規化は非常に重要です。Accept-Encoding: gzip, brとAccept-Encoding: br, gzipは、オリジンがそれらを区別しない場合には理想的には同じキーにマッピングされるべきですが、仕様ではその要件はないため、Cloudflareの実装ではホワイトスペースの正規化のみを行った後にリテラルのヘッダー値をハッシュ化しています。
この記事で文書化されているエッジケースとしては、Vary: *（「キャッシュしない」を意味し、キャッシュを完全にバイパスすることで対処）、バリアント空間が爆発的に増加する可能性があるVary: Cookie（レート制限とキャップを設ける）、そしてStale-While-Revalidateとの相互作用が挙げられます。また、多数の言語バリアントを返す行儀の悪いオリジンでVary: Accept-Languageを使うとキャッシュスラッシングが発生することも指摘されており、URL単位のバリアント数に上限を設けています。
Source: https://blog.cloudflare.com/vary-support/
AIが「十分に使える」時代におけるセキュリティ監査
Trail of BitsはCVEデータセット上のベンチマークではなく、実際の運用経験に基づいて、LLMを活用したツールがセキュリティ監査ワークフローをどこで実際に変えるかについて、慎重に調整された立場を示しています。
彼らの中心的な主張は次の通りです：LLMは監査における機械的な表面カバレッジフェーズ——エントリポイントの列挙、初期のtaintフロー仮説の生成、定型的なproof-of-conceptハーネスの作成——には有用ですが、大規模なコードベースをまたいだマルチホップの状態不変条件を追跡する推論ステップには信頼性が低いというものです。失敗のパターンは「自信に満ちた誤り」であり、モデルはもっともらしい脆弱性仮説を生成する一方で、行番号が間違っていたり、データフローが誤っていたり、すでに存在して見落とされた緩和策を無視していたりします。
彼らが説明する実際のワークフローは、LLMを最初のパスにおけるトリアージ役として使用するものです。すなわち、モデルにファイルまたはサブシステムを渡し、疑わしいパターンを列挙させ、その後人間の監査者が本物の問題を検証・追跡します。このアプローチは「最初の仮説に至るまでの時間」を短縮しますが、検証ステップを短縮するわけではなく、その部分は依然として人間がボトルネックとなります。
また、攻撃と防御の非対称性に関する示唆も指摘しています。防御側がAI支援の監査を利用すれば、攻撃的な研究者も同様に利用するため、特定のクラスのバグを発見する限界コストは双方にとって同時に低下します。セキュリティ態勢への正味の影響は、どちらの側がより優れた自動化インフラストラクチャとより速いパッチからデプロイまでのサイクルを持つかによって決まります。
この投稿は、彼らが測定していないことについても正直です。社内ツールの誤検知率は公開されておらず、ベンダーのマーケティングでよく見られる「AIによってバグが30%多く発見される」という主張は、選択バイアス（簡単なバグ、既知の脆弱性クラス、キュレートされたコーパス）があると批判されています。自動脆弱性発見に関するSoK論文と並べて読む価値があります。
Source: https://blog.trailofbits.com/2026/09/18/auditing-in-the-age-of-good-enough-ai/
Postgres SELECT DISTINCT はスケールしない
PostgreSQLにおける SELECT DISTINCT は、HashAggregate または Sort + Unique のプランノードを通じて実装されています。結果セットが小さい場合はどちらも問題ありませんが、この記事では特定のスケーリング障害モードを指摘しています。それは、distinct値の数が多く、作業セットが work_mem に収まらない場合に、hash aggregateがディスクにスピルする挙動が、ハッシュベースのアプローチに期待される O(n) ではなく O(n \log n) のI/Oになるというものです。
根本原因は、PostgreSQLのhash aggregateが固定メモリバジェットを持つシングルパスのハッシュテーブルを使用していることにあります。バジェットを超過した場合、（たとえばDuckDBがradix分割aggregationで行うような）パーティション化されたhash join戦略へ滑らかに切り替わることはありません。代わりにソートベースの重複排除にフォールバックし、これは入力の完全なソートを必要とします。10^8 行と 10^7 個のdistinct値を持つテーブルでは、1億行をディスクにソートすることを意味し、2パスのパーティション化ハッシュが必要とするI/Oよりも桁違いに多くなります。
この記事ではベンチマークでこれを実証しています。50GBのテーブルに対する SELECT DISTINCT は使用ハードウェアで約8分かかる一方、streaming aggregationヒントを用いた同等の GROUP BY（またはインデックススキャンを組み合わせた UNION の使用）は、特定のアクセスパターンにおいて2分未満で完了します。
推奨されるワークアラウンドとしては、GROUP BY を代わりに使用する（セマンティクスは同じで、より良いプランが得られることがある）、すでにソートされたデータに対して Unique を使ったindex-only scanを可能にするインデックスを追加する、またはクエリを再構成して早期にフィルタリングするといった方法が挙げられています。このPostgresのプランナーの制限は既知の問題ですが、修正するにはhash aggregateがマルチパスのパーティション化実行をサポートする必要があり、これはエグゼキュータへの非自明な変更となります。
Source: https://www.dbos.dev/blog/postgres-select-distinct-does-not-scale
Git-bug: Gitに組み込まれた分散型・オフラインファーストのバグトラッカー
git-bugは、バグトラッカーのデータ（issues、コメント、ラベル、状態遷移）を作業ツリーではなく、refs/bugs/ 名前空間配下のGitオブジェクトストアに直接格納します。各バグは操作オブジェクト（作成、コメント、編集、ラベル付け、状態変更）のDAGとして、GitのblobおよびtreeとしてSHAを基点に管理され、バグのアイデンティティは最初の作成オブジェクトのSHAに根付いています。この設計は構造上append-onlyであり、操作はイミュータブルなオブジェクトとしてコミットされます。「編集」は以前の操作ノードを上書きする新たな操作ノードとして追加されます。
データモデルはCRDTに似た操作ログです。2つのクローンが乖離した場合（両方がオフラインでコメントを追加した場合など）のマージは、Git fetchの後にDAGマージを行うだけで済み、中央サーバーによる調停は不要です。コンフリクトの解決は決定的であり、操作はタイムスタンプで順序付けられ、タイブレーカーとしてSHAが使用されます。これは結果整合性を持ちますが、厳密な因果順序は保証されません。このトレードオフは設計ドキュメントで明示的に受け入れられています。
実際のワークフローとしては、git bug push と git bug pull が標準的なGitリモートプロトコルを使用してコードと並行してバグデータを転送します。サイドカーサーバーも、データベースも、webhookも不要です。これにより、完全にエアギャップされたリポジトリや、フォージ（GitHub、GitLab）が単一障害点となるシナリオに適しています。
実装はGoで書かれています。CLIが主要なインターフェイスであり、ターミナルUIおよびツール統合向けのGraphQLブリッジも提供されています。GitHubおよびGitLabのissuesへのブリッジもインポート・エクスポート用に存在しますが、集中型トラッカーとの双方向同期は、この設計が本来回避しようとしている整合性の問題を引き起こします。
主な制限は高度なクエリ機能の欠如です。バグはリレーショナルストアではなくGitオブジェクトとして格納されているため、複雑なクエリ（複数ラベルの積集合、全文検索など）はref名前空間を走査する必要があり、大規模なリポジトリでは低速です。Gitが提供する機能以外のインデックスレイヤーは存在しません。
Source: https://github.com/git-bug/git-bug
VSCodeのSSHエージェントはとんでもない
この投稿は、VSCode Remote SSHが実際にどのように動作するかについての詳細なフォレンジック分析であり、著者がFly.ioのインフラ上で異常なSSHエージェントの挙動をデバッグした後に執筆されました。
驚くべき発見：VSCodeはリモートセッションにシステムのSSHバイナリを単純な方法では使用していません。VSCodeは独自のNode.jsベースのSSHクライアント（@vscode/node-ssh-agent）を同梱しており、エージェントソケットを通じてローカルのSSHエージェントと通信した後、独立してリモートホストへの接続を確立します。これはVSCodeのSSHスタックが~/.ssh/configの解析とは非自明な形で分離されていることを意味します。一部の設定ディレクティブは反映されますが、他は暗黙的に無視され、優先順位のルールもOpenSSHとは異なります。
エージェントフォワーディングの挙動が核心です：VSCodeはssh -Aに委任するのではなく、独自のエージェントフォワーディングメカニズムを注入することでエージェントソケットをリモートホストに転送します。リモート側では、VSCodeがアップロードする小さなヘルパーバイナリによって管理されるUnixソケットに$SSH_AUTH_SOCKを設定します。このヘルパーはVSCodeの多重化チャネルを通じてエージェントリクエストをローカルマシンにプロキシします。副作用として、リモート上のエージェントソケットパスがユーザーのシェルプロファイルによって設定されたものとは異なるため、パスをハードコードまたはキャッシュするツールが壊れてしまいます。
セキュリティ上の含意として、VSCodeのエージェントプロキシはセッション期間中（そしてサーバープロセスのライフサイクルの関係で、場合によってはそれ以降も）、リモートホスト上で永続的なバックグラウンドプロセスとして実行されます。エージェントフォワーディングのスコープは単一のSSH呼び出しを超えており、VSCodeサーバーが生きている限り持続します。
この投稿にはパケットトレースとプロセスツリーのダンプが含まれています。エージェントフォワーディングのスコープが重要な環境における推奨の緩和策は、VSCodeの組み込みエージェントフォワーディングを無効にして、ソケットを明示的に管理することです。
注目の新しいリポジトリ
Nehanth/swarmllm
モデル（27Bパラメータのネットワークで実証）を同一ローカル環境内の複数のブラウザタブまたはデバイスに分散させる、ピアツーピアLLM推論システムです。実装は2つのコアコンポーネントから構成されています。1つはスクラッチから構築されたWebGPUコンピュートエンジンで、ネイティブランタイムへの依存なしにブラウザ内で直接テンソル演算と重みのロードを処理します。もう1つはWebRTCベースの通信レイヤーで、ピアの探索、重みシャードの配布、ノード間のactivation転送を管理します。各参加デバイスはモデルのレイヤーの一部を保持し、フォワードパスはメッシュ全体でパイプライン処理されるため、中間activationはサーバーを経由せずにピアツーピアでストリーミングされます。このアプローチが注目される理由は、単一デバイスがモデル全体を収めるだけのVRAMを必要とするという通常のボトルネックを回避できる点にあります。16ビット精度の27Bモデルは約54 GBを必要とし、これはコンシューマー向けGPUの容量をはるかに超えますが、そのフットプリントはWebGPU対応デバイス多数に分割することができます。取り組むべき主要なエンジニアリング課題は、WebRTCデータチャネル上の同期レイテンシと、成熟したWebGPUコンピュートシェーダーエコシステムが存在しないことです。実用的なユースケースとしては、ローカルランタイムをインストールしたりAPIアクセスに費用を支払ったりすることなく、異種コンシューマーハードウェア上でアドホックな協調推論を行うことが挙げられます。まだ初期段階であり、ノードの増減時のスループットとフォールトトレランスが明らかな未解決問題として残っています。
Source: https://github.com/Nehanth/swarmllm
2akouwu/reverify
MCPサーバー（Model Context Protocol）とCLIとして構成されたハルシネーション軽減フレームワークです。設計の核心原則は、生成ステップと検証ステップの厳密な分離にあります。LLMがクレームを提案し、Webサーチ・正規表現エクストラクター・知識ベース検索といった決定論的ツール群が、レスポンスを返す前に各クレームを取得可能なグラウンドトゥルースと照合して判定します。証拠と検証済みの事実は、セッションリセットをまたいで保持される永続的なコンテキストに格納されるため、システムはターンのたびにゼロから始まるのではなく、根拠のある知識状態を蓄積していきます。このリポジトリで主に検証対象とされているのはリバースエンジニアリングタスク（バイナリ解析、プロトコル再構築）であり、これらは多くの中間クレーム（アドレス、逆アセンブル出力、既知のシグネチャ）がチェック可能であるため、検証との親和性が高いです。アーキテクチャはpropose-then-verifyループに従います。すなわち、クレームを生成し、適切な決定論的ツールにディスパッチし、証拠レコードを付加し、検証済みのクレームのみを後続のコンテキストへ伝播させます。MCPサーバーインターフェースを採用することで、密結合なしに任意のMCP互換クライアントへ接続できます。制限事項としては、決定論的ツールにおける通常のカバレッジギャップが挙げられます。利用可能なツールでグラウンディングできないクレームは未検証のままフォールバックされるため、システムの信頼性はツールレジストリの網羅性によって上限が定まります。
Source: https://github.com/2akouwu/reverify
sno-ai/sno-station
Claude CodeとOpenAI Codexを単一マシン上で協調するチームとして動作させるローカルのマルチエージェントオーケストレーションレイヤーです。クラウドへの依存もなく、常駐デーモンプロセスも必要ありません。本システムは共有暗号化メモリを提供することで、両エージェントが共通のコンテキストストアに対して読み書きできるようにします。また、Reachと呼ばれるエージェント間メッセージングプロトコルにより、明示的なハンドオフとベンダーをまたいだレビューが可能です。例えば、一方のエージェントが変更のドラフトを作成し、もう一方がそれをレビューするといった使い方ができます。協調に関するプリミティブは「squad skills」としてパッケージ化されており、ハンドオフのロジック、レビュー基準、エスカレーションパスをエンコードした再利用可能なタスクテンプレートです。ナイトリーループにより、蓄積されたセッション履歴に基づいてこれらのskillsが再評価・書き換えられますが、すべての変更は有効化される前にユーザーの明示的な承認を必要とします。これは自己修正ループを完全自律ではなく人間が監督する設計上の選択です。デーモンが存在しないため、認証情報やファイルシステムへの永続的なアクセスを持つバックグラウンドプロセスは存在せず、セッションは明示的に開始されます。この点は、セキュリティを重視するローカル環境へのデプロイにおいて重要です。公開の場で開発が進められているため、アーキテクチャは現在も進化中であり、APIの安定性は当面低いと想定すべきです。
Source: https://github.com/sno-ai/sno-station
ollaya-dev/ollaya
Ollayaは、本質的にOllamaのパターンを特定のカテゴリ——決定モデル——に適用したものです。構造化推論タスクに特化したモデル向けの、ローカルでpull・serveが可能なランタイムを提供します。対象モデルは、Laya（汎用決定モデル）、Decider（二値/多クラス決定）、NLI（テキスト含意のための自然言語推論）、GLiClass（一般化線形分類器）です。すべてのモデルはTypeSafe互換のAPIを通じて提供されており、TypeScriptを利用する開発者はリクエストの構築からレスポンスのパースまでエンドツーエンドの型安全性を享受できます。この取り組みの動機は、決定指向のモデルが大規模パイプライン内のコンポーネント（ルーティング、分類、含意チェックなど）として頻繁に使用されながらも、有料APIや扱いにくいセルフホスティング環境を介してアクセスされることが多いという現状にあります。単一のCLIを通じてローカルで実行できる仕組みは、生成モデルにおいてOllamaを魅力的にした開発者体験を再現しています。TypeSafe APIレイヤーは、OllamaのようなGenericな推論サーバーを通じてこれらのモデルを動かすだけの場合と比較した際の主要な差別化要素であり、自由形式のテキストではなく構造化された入出力を強制します。実用上の適合シーン：外部APIコールなしに、高速・ローカル・型付き分類や含意スコアリングが必要なパイプライン。
Source: https://github.com/ollaya-dev/ollaya
Taiquan-Zhou/RunTheRepo
Docker Compose 設定を含む GitHub リポジトリの実行ライフサイクル全体を自動化する AI エージェントです。クローニング、環境セットアップ、コンテナオーケストレーション、テスト実行、および基本的なハードニングチェックを行います。エージェントはリポジトリの構造を解釈してサービスの結線方法を推論し、一般的な設定上の問題（環境変数の欠落、ポートの競合、ボリュームのパーミッション）を解決し、存在するテストスイートを実行します。ハードニングコンポーネントは、Docker Compose に関する一般的なセキュリティ上の問題（公開ポート、特権コンテナ、リソース制限の欠如）をチェックし、修正を提案または適用します。解決しようとしている実際の問題は、Docker Compose ファイルを含む公開リポジトリの大部分が、文書化が不十分な依存関係や環境の前提条件のために、ローカルで立ち上げるために非自明な手作業を必要とするという点です。この自動化は、セキュリティ研究（分析対象を迅速にスピンアップする）と、サードパーティサービスを評価する開発者の両方にとって有用です。Python で構築されており、LLM が意思決定ループを駆動し、subprocess/Docker SDK の呼び出しがアクションを実行します。主な制限はロバスト性にあり、独自のビルドパイプラインや非標準の Compose 構造を持つリポジトリでは、手動での介入が必要になる可能性が高いです。
Source: https://github.com/Taiquan-Zhou/RunTheRepo
amitshekhariitbhu/ai-system-design
LLMを中心としたアプリケーション、RAGパイプライン、および自律エージェントを基盤とするアーキテクチャに特化した、AIシステム設計に関する体系的な教育用リファレンスです。コンテンツは段階的な構成で整理されており、基礎的なパターン（prompt管理、context window、トークンバジェティング）、検索拡張アーキテクチャ（チャンキング戦略、embeddingの選択、インデックス設計、reranking）、エージェントアーキテクチャ（ツール利用、メモリ、マルチエージェント協調）、そして本番環境における課題（レイテンシ、コスト、オブザーバビリティ）へと展開されます。チュートリアル形式のハウツー解説ではなく、設計上のトレードオフに重点を置いているため、個々のコンポーネントをすでに理解しており、それらを信頼性の高いシステムへと組み上げるための指針を必要とするエンジニアにとってより有用です。これは実際のニーズを満たすリファレンスです。MLの教育資料の多くはモデル内部の仕組みに焦点を当てており、一方でシステム設計のリソースはLLM特有の制約——非決定性、リソースとしてのcontext長、推論APIのコスト構造——にほとんど言及していません。アーキテクチャレビュー時の参考資料として、あるいはシステム設計の問いがAIネイティブなパターンへとシフトしているMLエンジニアリング職の面接対策として活用できます。
Source: https://github.com/amitshekhariitbhu/ai-system-design
Adkid-Zephyr/oral-paper-skill
トップレベルの学会からオーラル採択された883本の論文アブストラクトをもとに、執筆・研究実践を蒸留したリソースです。方法論は本質的にfew-shotのパターンマイニングです。採択されたオーラル論文のアブストラクトを分析し、繰り返し現れる構造的・修辞的パターン——問題のフレーミング、貢献範囲の設定、結果の定量化——を特定し、それらを中国語と英語の両方でスキル＆プロンプトパックとして再利用可能な形にまとめています。想定される用途は双方向です。スキルパックを使ってドラフト論文を監査する（貢献の明確さ、問題の動機づけの鋭さ、結果の具体性について、抽出されたパターンと照合する）か、あるいは提出論文の構造をオーラル論文のベースラインと比較することで事後的な学習に活用するかのいずれかです。プロンプトパック形式を採用しているため、LLMを活用した執筆ワークフローに直接統合できます。「蒸留」というフレーミングは適切であり、これは生成モデルではなく、成功論文の実証的分析に基づいてキュレーションされたプロンプトライブラリです。主な注意点として、オーラル採択はアブストラクトの質と相関しているものの、それだけで決まるわけではないため、抽出されたパターンは成功したアブストラクトの表層的な規則性を捉えているに過ぎず、採択の完全な因果的説明にはなっていません。