- 公開日
MarkdownとローカルQdrantでAIの記憶を育てる
- Authors

- Name
- Nguyen Hong Son (Sam)
- @samhon1459
AIと長く仕事をしていると、少しもどかしく感じることがあります。一つの会話ではとてもよく支援してくれたのに、次のタスクでは、そのとき分かったことを何も知らない状態に戻ってしまうからです。
最初は、会話、コマンド、ログ、結果をすべて保存しました。データはすぐに増えましたが、便利にはなりませんでした。古い仮説と確認済みの結論が混ざり、一時的な環境情報が長く使える事実のように見え、キーワード検索もノイズだらけになりました。
そこで、知識 と 記憶 を分けることにしました。
知識と記憶の役割を分ける
知識は、プロジェクトが今後も信頼して使えるものです。アーキテクチャ、業務ルール、技術判断、手順書、確認済みの連携仕様などが該当します。通常の文書と同じようにレビューし、正しい情報として管理します。
記憶は、あるタスクで何が起きたかを残すものです。試した方法、そのときの環境、発生したエラー、判断につながった証拠などを記録します。次の作業を続けるには役立ちますが、そのまま長期的な事実としては扱いません。
どちらもMarkdownで保存しています。人が読みやすく、Gitでレビューでき、特定のデータベースにも依存しないからです。プロジェクト、種類、日付、対象範囲、参照元といった簡単なメタデータも付けています。
Qdrantは検索用の索引
Markdownの後ろにローカルQdrantを置き、意味検索のための索引として使っています。文書を適切な長さに分け、embeddingを作り、内容の種類ごとに登録します。
タスクの開始時に関連する文章を検索できますが、利用する前には元のMarkdownを開いて確認します。類似度が高いことは良い手掛かりですが、情報が今も正しい証明にはなりません。
タスクが終わっても、会話全体は保存しません。あとで役立ちそうな環境上の制約、見つけにくかった不具合、判断とその理由、システムの動作を示す証拠だけを残します。
同じ記憶が何度も役立ち、内容も確認できたら、整理し直してプロジェクトの知識へ移します。知識は記憶より重く扱われるため、この段階では必ずレビューします。
この構成で気に入っているのは、Qdrantをいつでも作り直せることです。元の記録はMarkdownです。embedding modelが変わったりindexが壊れたりしても、プロジェクトの知識を失わずに再構築できます。
良い記憶の仕組みは、何でも保存するものではありません。必要な情報を見つけ、その出所を理解し、行動に使ってよいか判断できる仕組みだと考えています。