トピック別にノート整理するのは理にかなっているように思えます。しかし、PostgreSQLに関するノートが5つの異なるフォルダに散らばり、今日の課題に必要な特定のノートが見つからない状況に陥ると、その方法は通用しなくなります。

工学に関するメモのほとんどは、一度書かれると忘れ去られます。デバッグセッションで得た知見を記録し、どこかに貼り付け、2年後に見つけたときには、なぜそれが重要だったのかという文脈が一切ありません。

LLM（大規模言語モデル）は予測不可能です。幻覚（ハルシネーション）を起こし、データを漏洩させ、有害なコンテンツを生成したり、正当なリクエストを拒否したりします。ガードレール（防護策）は、機能を損なわずにモデルの動作を制限します。

700億パラメータのモデルで200語のメール要約を行うのは無駄です。30億パラメータのモデルで本番コードのレビューを行うのは無謀です。大多数のシステムは、これら2つの極端の間に位置しています。まさにそこが、モデルルーティングの出番です。

単一モデルのシステムはシンプルです。マルチモデルのシステムは強力です。課題はモデルの選択ではなく、それらをオーケストレートするアーキテクチャの設計にあります。

LLMのコストは使用量に比例して線形に増加します。1日に10,000件のリクエストを処理し、1件あたり$0.01のシステムの場合、日次コストは$100、年間コストは$365になります。エンタープライズ規模になると、コストは$10,000を超えます。

メモリはアシスタントを反応型のシステムから持続的なシステムへと変えますが、同時に多くのシステムが静かに腐敗していく場所でもあります。最近の調査では、現代的なエージェントのメモリに対して、短期記憶と長期記憶の二元論はもはや十分ではないと指摘されています。OpenAIやLangGraphのSDKは、よりシンプルなスタックを提唱しています。すなわち、ワーキングメモリ、永続状態、そして検索（リトリーバル）です。

本番環境で運用されるAIアシスタントは、「プロンプトを与えたLLM」ではありません。ユーザーの意図を受け取り、状態を保持し、検索やアクションを行うタイミングを判断し、障害のデバッグに必要なランタイムの詳細情報を公開するシステムです。

AIは知識管理を置き換えるものではありません。むしろ、個人およびチームにとって知識管理の形そのものを変革しています。

開発者は通常、情報の不足に悩まされるわけではありません。むしろ、情報が過多であることに苦しんでいます。

オープンソースの AI エージェントフレームワークが、GitHub 上で人気が爆発しています。 セルフホスト型 AI システム エコシステムの核心に位置する 2 プロジェクト——OpenClaw と Hermes Agent——は、他のどのプロジェクトよりも大きく差を広げており、残りの競合プロジェクトは遠く離れた 3 位争いを行っています。

Qwen 3.6 27B と 35B において、RTX 4080（16 GB VRAM）上で投機的デコーディング（マルチトークン予測、MTP）のパフォーマンスをテストしました。

llama.cpp ラーターモード は、llama-server における数年間で最も有用な変更の一つです。これにより、ローカルLLM運用者は、Ollamaで期待されるようなモデル管理体験に近いものをようやく手に入れることができました。同時に、llama-server を使い続ける価値がある生のパフォーマンスと低レベルの制御も維持されています。

最新の知識システムのほとんどは検索（Retrieval）を最適化しています。それは理解できることです。検索は目に見えやすく、デモンストレーションも容易で、機能すると魔法のように感じられます。質問を入力すれば、答えが返ってきます。

前提はシンプルです。コンパイルされた知識は、取得された断片的な情報よりも再利用性が高いというものです。 RAG（検索強化生成）は、LLM（大規模言語モデル）に外部知識へのアクセスをどのように与えるかという直接的な問いに対するデフォルトの答えとなりました。

PKM、RAG、ウィキ、AIメモリシステム、そして今実用化が進むAI支援ワークフローは、しばしば同じ問題を解決するかのように論じられます。 しかし、実際にはそうではありません。 これらはすべて知識を扱いますが、動作するレイヤーは異なります。