AIアシスタントにおけるメモリシステム
アシスタントのためのワーキングメモリ、構造化メモリ、および検索メモリ
メモリはアシスタントを反応型から永続型へと変えますが、同時に多くのシステムが静かに劣化してしまう箇所でもあります。調査では、短期的メモリと長期的メモリの二分法是では現代のエージェントメモリには不十分であると指摘されています。OpenAIやLangGraphのSDKは、よりシンプルな構成、つまりワーキングメモリ、永続的な状態、および検索による取得(リトリーブ)へと焦点を移しています。
アシスタントのためのワーキングメモリ、構造化メモリ、および検索メモリ
メモリはアシスタントを反応型から永続型へと変えますが、同時に多くのシステムが静かに劣化してしまう箇所でもあります。調査では、短期的メモリと長期的メモリの二分法是では現代のエージェントメモリには不十分であると指摘されています。OpenAIやLangGraphのSDKは、よりシンプルな構成、つまりワーキングメモリ、永続的な状態、および検索による取得(リトリーブ)へと焦点を移しています。
実際に本格的なアシスタントはどのように構築されているか
本番環境向けのAIアシスタントは「プロンプト付きのLLM」ではありません。インテント(意図)を受け付け、状態を保持し、いつ検索を実行すべきか、いつ行動すべきかを決定し、障害のデバッグに必要なランタイムの詳細を公開するシステムなのです。
AIは知識管理の目的を変えず、手法を変革する。
AIは知識管理を置き換えるものではありません。むしろ、個人およびチームにとって知識管理の形そのものを変革しています。
開発者ナレッジグラフを構築する。
開発者が通常直面するのは情報の不足ではありません。問題となるのは、情報があまりにも多すぎることです。
スター、トークン、ダウンロード—who actually wins?
オープンソースのAIエージェントフレームワークは、GitHub上でその人気を急速に高めています。セルフホスト型AIシステムのエコシステムの中核をなす2つのプロジェクト、OpenClawとHermes Agentは、他を大きく引き離し、残りのライバルたちは遠い3位の座を争う状況になっています。
RTX 4080におけるMTPと標準デコーディングの比較 — 実ベンチマーク
RTX 4080(16 GB VRAM)環境で、Qwen 3.6 27Bおよび35Bにおける推論デコーディング(マルチトークン予測、MTP)のパフォーマンスをテストしました。
llama-serverを停止せずにVRAMを解放する方法
llama.cpp ラーターモード は、llama-server における数年間で最も有用な変更の一つです。これにより、ローカルLLM運用者は、Ollamaで期待されるようなモデル管理体験に近いものをようやく手に入れることができました。同時に、llama-server を使い続ける価値がある生のパフォーマンスと低レベルの制御も維持されています。
検索は知識構造ではない
最新の知識システムのほとんどは検索(Retrieval)を最適化しています。それは理解できることです。検索は目に見えやすく、デモンストレーションも容易で、機能すると魔法のように感じられます。質問を入力すれば、答えが返ってきます。
AIシステム向けの構造化された知識
前提はシンプルです。コンパイルされた知識は、取得された断片的な情報よりも再利用性が高いというものです。 RAG(検索強化生成)は、LLM(大規模言語モデル)に外部知識へのアクセスをどのように与えるかという直接的な問いに対するデフォルトの答えとなりました。
現代の知識システムの地図
PKM、RAG、ウィキ、AIメモリシステム、そして実用的なAI支援ワークフローは、あたかも同じ問題を解決するかのように議論されることがよくあります。 しかし、そうではありません。 これらはすべて知識を扱いますが、異なるレイヤーで動作しています:
ノートは記憶であり、セカンダリブレインは計算である。
情報過多問題は、単なる情報の量というよりも、処理されていない入力(インプット)の蓄積に起因するものです。現代の知識労働は、ブラウザのタブ、チャットの履歴、ドキュメント、ハイライト、スニペット、トランスクリプト、スクリーンショット、そして書きかけのメモといった痕跡を残します。
「雰囲気」に頼る解析をやめ、契約を検証せよ。
ほとんどのLLM「構造化出力」チュートリアルは、本気度にかけるものです。 それらは、JSONを丁寧な口調でリクエストし、モデルが適切に動作することを祈る方法を教えます。 それでは検証ではありません。 それは単に括弧で囲まれた楽観主義にすぎません。
エージェント型LLMのチューニングに関する参照資料
このページは、エージェント型LLM推論チューニングの実用的なリファレンス(temperature、top_p、top_k、ペナルティ、およびマルチステップやツール多用なワークフローにおけるそれらの相互作用)です。
より広範なLLMパフォーマンスエンジニアリングハブと併せて参照し、明確なLLMホスティングとサービングの概要と組み合わせることで、モデルがリソース不足に陥った際にはスループットとスケジューリングが依然として支配的ですが、不安定なサンプリングはGPUが処理を終える前にリトライと出力トークンを消費してしまうことがわかります。
このページでは以下をまとめます:
重複する副作用を防ぐ
分散システムにおける冪等性(べきとうせい)は、ネットワークが嘘をつき、キューがリトライし、クライアントがパニックになり、オペレーターがリプレイを実行した後に、あなたを救う性質です。本番システムでは、重複配信は普通のことです。重複した副作用こそがバグです。
スマートフォンからHermesと会話する
スマートフォンからテキストでヘルメスエージェントとチャットすることはすでに可能でしょう。 今、あなたはエージェントと直接会話し、音声で返信を受け取りたいと考えています。 これは通常、正しい選択です。特にHermesを永続的な自己ホスト型アシスタントとして使用している場合には顕著です。 小さな画面で長いプロンプトをタイプするのは、時間がかかり、誤りも生じやすいものです。
セルフホスト型LLMにおけるHermesカーンボードの負荷を制御する
Hermes AgentにはKanbanスタイルのボードとHermes Gatewayが標準で搭載されていますが、一度に多数のタスクがディスパッチされると、セルフホスト型のLLMが過負荷状態に陥る可能性があります。
システム、インフラ、AIエンジニアリングの新記事をお届けします。