Lossless-Memory: 要約なしの個人用AI長期記憶層

TL;DR

Lossless-Memoryは、タイムスタンプ付きでAIと人間の発話すべてを正確に保存し、時間順にインデックス化し、モデルのコンテキストにわずかな「現在の状況」インデックスを注入することで、単一のユーザーが単一のマシン上で完全な記憶を保持できるようにします。


プロジェクトの概要

Lossless-Memoryは、個人用AIアシスタント用のローカルでファイルベースの長期記憶層です。以下の構成要素からなります:

  • 生のJSONLログ(1日分1つ):各会話のターンごとに7フィールドの記録を保持し、一切要約しません。
  • SQLiteインデックス – 時刻と単語を併記する正確一致FTS5インデックスと、意味検索用のフォールバックベクトルインデックス(sqlite‑vec)。
  • 時系列バックボーン – 時間表現(相対的な日本語表現や絶対日付)を抽出し、ランキング前に検索範囲を制限するクエリパーサー。
  • LLLインデックス – 人間が会話のトピックが変わったときに手書きで記録する短いトピックマーカーのリスト。このインデックスは毎ターンモデルのコンテキストに注入され、会話の流れを保持します。

このシステムは意図的に単一ユーザー・単一マシンに限定されており、汎用的なベクトルデータベースラッパーでも、要約機能でもありません。


コア設計の柱

1. 要約なしの生ログ

各ターンは、以下のフィールドを含む1日分のJSONLファイルに追加されます:

ts        ISO‑8601 UTCタイムスタンプ
actor     発話者識別子
role      user | assistant | system
type      text | action | meta
text      元の内容
model     モデル識別子(オプション)
session   セッションID

これらのログが真実のソースであり、すべてのインデックスはこれから再構築可能です。

2. 時系列バックボーン

時間は単なるメタデータではなく、主軸です:

  • FTS5インデックスは各行にタイムスタンプを保存します。
  • パーサーは日本語の相対表現(例:「昨日」、「先週」)と任意の絶対日付(ISO形式)を理解し、ランキングの前に具体的な時間範囲に変換します。
  • 時間表現が含まれる場合、結果はその範囲に制限され、時系列順に返されます。正確なインデックスで結果が少なすぎる場合にのみ意味検索が使用され、その使用は明示的に報告されます。

これにより、「先週の火曜の夜に何を決めた?」といったクエリが、その夜に発話された正確な行を順番に返すことが可能になります。

3. LLL – 「現在の状況」インデックス

LLLはトピックマーカーの軽量インデックスです。人間が会話のトピックが変わったときに手書きで記録する短い、タイムスタンプ付きの行です。モデルはこのインデックスを読み取るが、編集は行わないため、コンテキストウィンドウの圧縮後でもAIが現在の会話スレッドを常に把握できます。


アーキテクチャ図

生の会話ログ (JSONL, 1日分)  ← 真実のソース、一切要約されない
            │
            ▼
   インジェスト ──► 7フィールドレコード
            │
            ├──► index_exact   SQLite FTS5 + タイムスタンプ   (単語 + 時間)
            ├──► index_vector  sqlite‑vec埋め込み       (意味、最終手段)
            └──► state_index   LLLトピックマーカー           (現在の状況)
                        │
                        ▼
                    リカール  ── 1つのエントリポイント:時間表現を解析 → 範囲制限 → ランキング → 元の行を返却
                        │
                        ▼
        モデルのコンテキストに注入(必要に応じて、またはLLL用に毎ターン)

デーモンが10分ごとに増分的に再インデックス化します。変更された日次ファイルのみ処理されるため、完全再構築は不要です。


実世界のパフォーマンス数値

メトリクス 値
日次運用 2026年7月より稼働中(2026年6月分のログ)
正確検索インデックス再構築時間(リデザイン前 vs 後) 40秒 → 1.24秒
ベクトルインデックス行数(最悪ケース) 865,588行(2026年9月4日)→ 修正後124,174行
ベクトルストアサイズ 2.54GB → 337MB
再インデックス間隔 10分

これらの数値は著者の単一ユーザー環境からのものであり、リデザインの実用的影響を示しています。


要約なしアプローチの理由

著者は、毎日AIアシスタントと会話する人物のためにこのシステムを構築しました。要約による徐々な記憶喪失の経験から、要約は正確な表現、トーン、タイムスタンプといった、記憶を個人的にする要素を捨ててしまいます。要約を拒否することで、システムは追加のディスク容量と強力な時系列インデックスの必要性を犠牲にしながらも、会話の完全なテクスチャを保持します。目標は、あなたが人間のように記憶する、あなたが所有するハードウェア上で完全に動作するコンパニオンです。


制限事項と未解決課題

  • 単一ユーザー・単一マシン – マルチテナント対応なし。
  • 日本語優先の時間解析 – 相対時間表現は日本語のみ対応;英語ユーザーは絶対ISO日付を手動で指定する必要あり。
  • ログフォーマット – Claude CodeのJSONLに最適化;汎用的な {ts, role, text} インポーターは存在するが、実戦検証は不十分。
  • 公開されたベンチマークなし – 提供された数値は比較性能データではなく、運用測定値。
  • 意味検索はローカル埋め込みモデル(sentence‑transformers)に依存;GPU加速はオプション。

コミュニティのフィードバック(Hacker Newsコメント)

"情報検索の洗練されたアプローチに見えます。時系列/バージョン付きの日時順序は絶対に有用です。" – alansaber

"これは https://github.com/obra/episodic-memory とどう違いますか?" – schainks

"相対時間パーサーは日本語にハードコードされています;英語セッションでは手動のISO日付に頼るしかありません。dateparserやducklingを統合するのは1晩で可能なので、それをロードマップに残すのは奇妙な選択です。" – TimByte

"一見有用に思えるかもしれませんが、最終的にはこの方法が通用しなくなる壁にぶつかり、別の記憶技術を追加する必要があります。最終的には、『記憶』という言葉が実際には10種類の異なるものであり、それぞれに独自の解決策が必要であることがわかります。" – 0xbadcafebee

"この仕組みはキャッシュを頻繁に破壊する可能性があります。特定のプロバイダーでは請求額が増加し、ローカルモデルでは特に長時間のエージェントセッションでは応答生成に時間がかかります。" – theresLand

これらのコメントは、時系列に焦点を当てたアプローチへの関心と、言語対応、スケーラビリティ、既存のキャッシュや記憶フレームワークとの統合に関する懸念を浮き彫りにしています。


はじめ方

git clone https://github.com/aru-labs/lossless-memory
cd lossless-memory
pip install -e .
cp config.example.json config.json   # 名前とパスを必要に応じて編集

examples/quickstart.mdガイドに従い、サンプル会話をインジェストし、インデックスを構築し、時間範囲クエリを実行します(約5分)。pytestによるラウンドトリップテストで全パイプラインの検証が可能です。


ドキュメントと追加リーディング

ドキュメント 概要
docs/memory-system.md コンセプトと仕様
docs/temporal-backbone.md 時系列優先インデックスと表現解析
docs/lll.md トピックマーカーインデックスと人間/AIの責任
docs/philosophy.md 要約を避ける理由
docs/lessons.md 失敗、修正、パフォーマンス数値
docs/ja/ 元の日本語テキスト

ライセンス

MIT License (c) 2026 Aru & Cece。

Sources

関連

  • プロジェクト
  • プロジェクト
  • プロジェクト
  • プロジェクト
  • プロジェクト