PKM、RAG、Wiki、メモリシステムを明確に解説

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

• PKMは人間の思考を支援します。
• ウィキはグループが共有知識を保存するのを支援します。
• RAGは機械が外部知識を取得するのを支援します。
• メモリシステムはAIエージェントが文脈を時間経過とともに維持するのを支援します。

これらのシステムを混同することは、不良なアーキテクチャの原因となります。

個人のメモだらけのウィキ、真実の源を持たないRAGシステム、データベースを装うメモリレイヤー、そして処理のために設計されなかった自動化で過負荷状態にあるPKMツールが生み出されます。

より良いモデルは、これらを知識システムスペクトルの異なる部分として捉えることです。

この記事では、PKM、RAG、ウィキ、およびAIメモリシステムを、構造、取得、所有権、進化、および実世界のユースケースによって比較します。 これらの抽象概念が、具体的な日常のノート-taking、ドキュメント作成、ランブックの保守に適用された様子を見たい場合は、補足記事「[知識管理のためのAI：持ちこたえる実用的なワークフロー](https://www.glukhov.org/ja/knowledge-management/ai-augmented-knowledge/ai-for-knowledge-management-workflows/ “知識管理のためのAI：持ちこたえる実用的なワークフロー）」で、PKMやウィキの基盤を置き換えるのではなく、それらの上に構築される要約、抽出、リンクパイプラインについて解説しています。

簡潔なまとめ

システム	主なユーザー	主な目的	最も適した用途
PKM	個人	個人知識の習得	思考、学習、統合
ウィキ	チームまたは公開グループ	共有知識の維持	ドキュメント、ポリシー、参照
RAG	機械システム	生成のための文脈取得	外部データに基づくAI回答
AIメモリ	AIエージェント	時間経過に伴う文脈の維持	長期間実行されるエージェントとパーソナライゼーション

最も重要な違いは次の通りです：

PKMとウィキは知識を構造化します。RAGは知識を取得します。メモリシステムはエージェントの文脈を進化させます。

これが核心的なメンタルモデルです。

なぜこれらのシステムは混同されるのか

それらは目に見える挙動で重複しています。

すべてが以下を行うことができます：

• ノートを保存する
• 情報を取得する
• 質問に答える
• 参照を整理する
• アイデアを接続する

しかし、意図は異なります。

PKMシステムは単なるプライベートなウィキではありません。 ウィキは単なるRAGデータベースではありません。 RAGパイプラインはAIメモリではありません。 AIメモリシステムは構造化されたドキュメントの代替ではありません。

混乱は「知識」を一つのものと扱っていることから来ます。

実際には、知識には複数のレイヤーがあります：

1. 捕捉
2. 構造化
3. 取得
4. 解釈
5. 再利用
6. 進化

異なるシステムは異なるステージを最適化します。

4つのパラダイム

1. PKM

PKMは個人知識管理を意味します。

それは、個人的な仕事のために知識を捕捉、整理、接続、使用する実践です。

典型的なPKMシステムには以下が含まれます：

• Obsidian
• Logseq
• Notion
• プレーンなMarkdownフォルダ
• Zettelkastenシステム
• セカンドブレインシステム

PKMは人間主導です。

その目標は単なる保存ではありません。より良い思考こそが目標です。

PKMが得意なこと

PKMは以下に有効です：

• 新しい分野の学習
• 独自アイデアの開発
• 時間経過に伴うノートの接続
• 記事や本の執筆
• 個人研究の追跡
• セカンドブレインの構築

良いPKMシステムは、有用な意味での「混沌」として機能します。未完成の思考、部分的なアイデア、プライベートな文脈、進化し続ける概念をサポートします。

これがPKMがドキュメント作成と同じではない理由です。

ドキュメント作成は明確さを求めます。 PKMは曖昧さを受け入れます。

PKMの失敗モード

PKMは以下のような状態になるとしばしば失敗します：

• ダンプグラウンド（捨てる場所）になる
• フォルダ分類プロジェクトになる
• 生産性の美学になる
• ツール最適化の趣味になる
• 誰も使わないプライベートアーカイブになる

主なリスクは、統合なしの収集です。

情報を保存するだけでは、知識システムは持ちません。個人の埋立地を持つことになります。

意見に基づく見解

PKMは捕捉ではなく、再利用を最適化するべきです。

すべてを捕捉することは生産的に感じられますが、負債を生み出します。真の価値は、ノートが接続され、書き換えられ、圧縮され、出力で使用されるときに現れます。

2. ウィキ

ウィキは、共有参照用に設計された構造化された知識ベースです。

典型的なウィキシステムには以下が含まれます：

• DokuWiki
• MediaWiki
• Confluence
• BookStack
• Gitベースのドキュメントサイト
• 社内企業の知識ベース

ウィキは通常、PKMよりも正式です。

それは以下に答えるべきです：

私たちは何を知らなければならず、現在のバージョンはどこにあるのか？

ウィキが得意なこと

ウィキは以下に有効です：

• チームドキュメント
• 運用ランブック
• 製品知識
• ポリシー文書
• 技術参照
• オンボーディング資料
• 安定したドメイン知識

ウィキは社会的契約です。

それは以下を意味します：

このページは、この知識が存在する場所です。

それにより、所有権と保守が重要になります。

ウィキの失敗モード

ウィキは古くなることでしばしば失敗します。

一般的な問題：

• ページの所有者不在
• 古いスクリーンショット
• 重複ページ
• 不明確な標準バージョン
• 階層が多すぎる
• 保守のリズムがない

古い情報を持つウィキは、偽の安心感を生み出すため、ウィキがないことよりも悪い状態です。

意見に基づく見解

ウィキは退屈であるべきです。

それは褒め言葉です。

良いウィキはアイデアが生まれる場所ではありません。それは、他者に有用になった後、安定した知識が保存される場所です。

3. RAG

RAGは検索拡張生成を意味します。

それは、システムが言語モデルに回答の生成を依頼する前に、関連する外部情報を取得するAIアーキテクチャです。

基本的なRAGパイプラインには通常、以下が含まれます：

1. ドキュメント
2. チャンキング
3. 埋め込みまたは検索インデックス
4. 取得
5. オプションのリランキング
6. プロンプトの組み立て
7. LLMによる生成

RAGは機械主導です。

その目標は知識の創造ではありません。クエリ時にモデルに関連する文脈を提供することこそが目標です。

RAGが得意なこと

RAGは以下に有効です：

• ドキュメントに基づく質問応答
• 内部検索アシスタント
• サポートボット
• 技術ドキュメントアシスタント
• 準拠の検索
• 大規模なコーパスの研究
• LLMの更新された情報への接続

モデルが情報を記憶できない、または記憶すべきでない場合にRAGは特に有用です。

RAGの失敗モード

RAGは、チームがそれを魔法のような検索として扱うときにしばしば失敗します。

一般的な問題：

• 悪いチャンキング
• 弱い取得
• ノイズの多い文脈
• メタデータの欠如
• 真実の源の不在
• 古いドキュメント
• 弱い評価
• ヒューマンフィードバックループの欠如

RAGは悪い知識管理を修正しません。

基盤となるコンテンツが断片的で、古く、または矛盾している場合、RAGシステムはその混乱を確信を持って引き出します。

意見に基づく見解

RAGは知識戦略ではありません。

RAGはアクセス戦略です。

それは機械が知識にアクセスするのを手伝いますが、どの知識が有効で、保守され、標準的で、有用かを決めるわけではありません。

4. AIメモリシステム

AIメモリシステムは、エージェントに単一のプロンプトや会話を超えた永続的な文脈を与えます。

それらは以下を保存する可能性があります：

• ユーザーの好み
• 過去の決定
• 長期的な事実
• タスク履歴
• 要約
• 省察
• 抽出されたエンティティ
• エピソードメモリ
• 意味メモリ

例や関連アイデアには以下が含まれます：

• MemGPTスタイルのメモリ階層
• 長期的エージェントメモリ
• エピソードメモリ
• 意味メモリ
• ベクトルメモリ
• プロファイルメモリ
• ツール状態メモリ
• 省察エージェント

AIメモリはエージェント主導です。

その目標は連続性です。

AIメモリが得意なこと

AIメモリシステムは以下に有効です：

• 個人アシスタント
• 長期間実行されるコーディングエージェント
• 研究エージェント
• カスタマーサポートエージェント
• 指導システム
• ワークフロー自動化
• 永続的なコンパニオン
• 複数セッションのタスク実行

システムが記憶しているように振る舞う必要がある場合、メモリは重要です。

AIメモリの失敗モード

メモリシステムは管理されていない場合、危険です。

一般的な問題：

• 誤った事実の記憶
• 過剰な保存
• プライバシリスク
• 古い好み
• 悪いメモリランキング
• メモリ汚染
• 忘却メカニズムの欠如
• メモリと真実の混同

メモリシステムにはガバナンスが必要です。

それは以下に答えるべきです：

• 何を記憶すべきか？
• 誰が承認したか？
• どれほど長く生き残るべきか？
• いつ忘れられるべきか？
• どのように修正されるか？

意見に基づく見解

AIメモリは単なる長文脈ではありません。

長文脈はモデルが一度により多くのものを見ることを可能にします。 メモリは時間経過で何が残るかを決定します。

エンジニアリングレイヤーにおいて — OpenClaw、Hermes、およびプロバイダーSDKにおけるワーキングメモリ、構造化された状態、取得メモリ、および統合ポリシー — その分離は「[AIアシスタントにおけるメモリシステム](https://www.glukhov.org/ja/ai-systems/memory/memory-systems-in-ai-assistants/ “AIアシスタントのための短期、長期、および構造化メモリの設計方法：取得メカニクス、トレードオフ、失敗モード、および実際のパターン）」で解説されています。

それらは異なる問題です。

核心的な違いの表

次元	PKM	ウィキ	RAG	AIメモリ
主なユーザー	個人	チームまたは公開グループ	AIシステム	AIエージェント
主な機能	思考	共有参照	クエリ時の取得	永続的文脈
知識状態	進化中	安定化	取得済み	適応的
構造	柔軟	明示的	インデックスベース	学習済みまたは抽出済み
取得スタイル	人間の検索とリンク	ナビゲーションと検索	意味的またはハイブリッド取得	関連性および注目度
所有権	個人	ページまたはチームの所有者	システム管理者	エージェントまたはユーザー制御
時間視野	長期的個人	長期的共有	クエリ時	複数セッション
最適な出力	洞察	信頼できる参照	根拠のある回答	連続性
主なリスク	蓄積	古さ	悪い取得	悪いメモリ
良い指標	思考における再利用	信頼と新鮮さ	回答の質	有用な連続性

構造 vs 取得 vs 進化

これらのシステムを理解する最も簡単な方法は、それらが何を最適化するかを比較することです。その違いのアーキテクチャ的影響は「[知識システムにおける取得 vs 表現](https://www.glukhov.org/ja/knowledge-management/foundations/retrieval-vs-representation/ “取得 vs 表現 — なぜRAGだけでは不十分なのか、そしていつ構造が検索よりも重要になるか）」で深く探求されています。

PKMは個人的な進化を最適化する

PKMは、あなたの理解がどのように変化するかについてです。

あなたは素材を収集し、書き直し、接続し、それを有用なものに変えます。

出力はしばしば以下です：

• より良いメンタルモデル
• 書かれた記事
• 決定
• 研究の方向性
• 再利用可能な洞察

PKMは主に高速な検索についてではありません。それは長期的な意味化についてです。

ウィキは共有構造を最適化する

ウィキは安定した知識についてです。

それは以下を問います：

• 現在の答えは何ですか？
• 誰がそれを所有していますか？
• 人々はどこに行くべきですか？
• 何を更新すべきですか？

ウィキは人々がそれを信頼するときに機能します。

RAGは機械の取得を最適化する

RAGは正しいタイミングで正しい文脈を取得することについてです。

それは以下を問います：

• どのドキュメントが関連していますか？
• どのチャンクを使用すべきですか？
• どのくらいの文脈が収まりますか？
• モデルは何を引用すべきですか？

RAGは取得の質が高く、ソースコーパスが信頼できるときに機能します。

AIメモリは連続性を最適化する

メモリシステムはセッション間の永続性についてです。

それは以下を問います：

• エージェントは何を記憶すべきですか？
• 何を忘れさせるべきですか？
• どのメモリが今重要ですか？
• メモリは振る舞いをどのように変えるべきですか？

メモリは、古いまたは不正確な文脈でエージェントを汚染せずに、将来の振る舞いを改善するときに機能します。

PKMを使用するタイミング

知識が個人的で、未完成、または探索的な場合にPKMを使用します。

良いシナリオ：

• 分散システムの学習
• 記事の計画
• LLMアーキテクチャの研究
• 本のノートを収集
• セカンドブレインの構築
• 個人の実験の追跡

まだ思考しているときにPKMを使用します。

例

あなたはRAG評価について学習しています。

あなたは以下を収集します：

• 記事
• ベンチマークノート
• 図
• 実装アイデア
• 自身の実験からの失敗

これはまずPKMに属します。

後で、知識が安定したら、記事を公開したり、ドキュメントに変えたりするかもしれません。

ウィキを使用するタイミング

知識が共有され、保守される必要がある場合にウィキを使用します。

良いシナリオ：

• チームオンボーディング
• APIドキュメント
• 運用ランブック
• アーキテクチャ決定記録
• 製品知識
• デプロイメント指示
• サポート手順

他者が信頼できる回答を必要とするときにウィキを使用します。

例

あなたのチームには、HugoサイトをS3およびCloudFrontにデプロイするための唯一の正しい方法があります。

それは誰かのプライベートなノートのみに属すべきではありません。

明確な所有権を持つウィキまたはドキュメントシステムに属すべきです。

RAGを使用するタイミング

AIシステムがクエリ時に外部知識にアクセスする必要がある場合にRAGを使用します。

良いシナリオ：

• ドキュメントに基づくチャットボット
• 内部ドキュメントに基づく検索アシスタント
• ヘルプ記事に基づくサポートアシスタント
• 法的または準拠アシスタント
• 大規模なドキュメントセットの研究
• コードドキュメントに基づく開発者アシスタント

問題が以下である場合にRAGを使用します：

モデルは重み外の情報を必要としています。

例

あなたは数百の技術記事を持っており、それらを使用して質問に答えるアシスタントが欲しいとします。

RAGは良い選択肢です。

ただし、ドキュメントが取得に十分なほどクリーンである場合のみです。

AIメモリを使用するタイミング

エージェントに連続性が必要な場合にAIメモリを使用します。

良いシナリオ：

• プロジェクトの慣習を記憶するコーディングエージェント
• 好みを記憶する個人アシスタント
• 長期的な調査を続ける研究エージェント
• 学生の進捗を記憶する指導エージェント
• 過去の相互作用を記憶するサポートエージェント
• 目標を追跡する自律エージェント

システムが時間とともに改善する必要がある場合にメモリを使用します。

例

コーディングエージェントは以下を記憶すべきです：

• プロジェクトはGoを使用している
• テストは特定のコマンドで実行される
• ユーザーは最小限の依存関係を好む
• データベースマイグレーションは規約に従う

それは単なる取得ではありません。それは永続的な運用文脈です — この記事がRAGとエージェントメモリとの間に引く区別であり、実装の詳細は「[AIアシスタントにおけるメモリシステム](https://www.glukhov.org/ja/ai-systems/memory/memory-systems-in-ai-assistants/ “AIアシスタントのための短期、長期、および構造化メモリの設計方法：取得メカニクス、トレードオフ、失敗モード、および実際のパターン）」にあります。

これらのシステムの組み合わせ

最も有用なシステムはハイブリッドです。

成熟した知識アーキテクチャは以下のように見えるかもしれません：

1. 個人的な探索のためのPKM
2. 安定した共有知識のためのウィキ
3. 機械アクセスのためのRAG
4. 長期的エージェント連続性のためのAIメモリ

各レイヤーには役割があります。

パターン1. PKMからウィキへ

これは人間の知識パイプラインです。

フロー：

1. プライベートにノートを捕捉する
2. アイデアを接続する
3. 洞察を抽出する
4. 安定した知識を公開する
5. 共有参照として維持する

これが個人研究が組織知識になる方法です。

例

あなたはObsidianでセルフホスト型知識ツールを研究します。

DokuWiki、Nextcloud、および静的Markdownシステムをテストした後、サイトまたはチームのウィキに安定したガイドを記述します。

PKMが洞察を生み出しました。 ウィキが結果を保存します。

パターン2. ウィキからRAGへ

これは機械アクセスパイプラインです。

フロー：

1. 標準的なウィキページを維持する
2. それらをインデックス化する
3. 関連セクションを取得する
4. 根拠のある回答を生成する
5. ソースにリンクする

これは最もクリーンなRAGパターンの一つです。

ウィキは真実の源のままです。 RAGはアクセスレイヤーになります。

例

サポートボットが製品ウィキを使用して質問に答えます。

ボットはウィキを置き換えるべきではありません。それは標準的なページに戻ってユーザーをルーティングし、引用すべきです。

パターン3. RAGとメモリ

これはエージェント連続性パイプラインです。

フロー：

1. RAGが外部事実を取得する
2. メモリがユーザーまたはタスクの文脈を保存する
3. エージェントは両方を組み合わせる
4. 将来の振る舞いが改善される

RAGは以下に答えます：

知識ベースは何と言っているのか？

メモリは以下に答えます：

このユーザー、プロジェクト、またはタスクについて何が重要なのか？

例

コーディングエージェントはRAGを使用してフレームワークドキュメントを取得します。

それはメモリを使用して、あなたのプロジェクトがORMを避け、sqlcを好み、構造化ロギングを使用することを記憶します。

それらは異なる知識タイプです。

パターン4. PKMとAIアシスタント

これはハイブリッド思考パイプラインです。

フロー：

1. 人間がノートを捕捉する
2. AIが要約し、リンクを提案する
3. 人間が編集し、検証する
4. 知識がより構造化される
5. 一部のページがウィキまたは出版に進む

AIはPKMシステムを増強しますが、真実の所有権を持つべきではありません。

例

AIアシスタントは、RAG、メモリシステム、LLM Wikiに関するノート間の接続を提案できます。

しかし、どの接続が意味があるかは人間が決定します。

一般的なアーキテクチャの間違い

間違い1. RAGをウィキとして扱う

RAGは知識ベースではありません。

それは自動的に標準的な構造を作成しません。存在するものから取得します。

ソースドキュメントが悪い場合、RAGは悪い知識に対する確信のあるインターフェースになります。

間違い2. メモリをデータベースとして扱う

AIメモリは選択的文脈であり、一般的なストレージではありません。

データベースはレコードを保存します。 メモリは振る舞いを変えます。

正確な事実を必要とする場合、データベースまたは知識ベースを使用します。 連続性を必要とする場合、メモリを使用します。

間違い3. PKMをドキュメント作成として扱う

PKMは混沌とすることができます。

ドキュメント作成はそうあるべきではありません。

プライベートなノートは形成途中のアイデアを含むことができます。共有ドキュメントは安定して保守された知識を含むべきです。

間違い4. ウィキを思考ツールとして扱う

ウィキは思考をサポートできますが、初期の探索には適していません。

すべての初期の思考が磨かれたページにならなければならない場合、人は書き上げなくなります。

粗い思考にはPKMを使用し、耐久性のある知識にはウィキを使用します。

間違い5. 長文脈をメモリとして扱う

長文脈はメモリではありません。

それは文脈が存在している間のみ役立ちます。

メモリは永続し、選択し、更新し、時には忘却します。

意思決定ガイド

このシンプルな意思決定モデルを使用します。

知識がプライベートで進化している場合

PKMを使用します。

知識が共有され、安定している場合

ウィキを使用します。

AIが外部ドキュメントから答える必要がある場合

RAGを使用します。

エージェントが時間とともに連続性を必要とする場合

メモリを使用します。

すべてを必要とする場合

層状システムを構築します。

一つのツールにすべての仕事を強制しないでください。

知識システムスペクトル

これらのシステムは、人間の思考からAIの連続性へのスペクトルを形成します。

レイヤー	システム	役割
人間の思考	PKM	探索と統合
共有構造	ウィキ	保存と維持
機械アクセス	RAG	取得と生成
エージェント連続性	メモリ	永続と適応

方向性は重要です。

知識はしばしば個人的な思考として始まり、共有構造になり、機械取得のためにインデックス化され、そして永続的なエージェント振る舞いの一部になります。

それが現代の知識スタックです。

LLM Wikiの位置づけ

LLM Wikiスタイルのシステムは、ウィキとAIアーキテクチャの間に位置します。

それらは従来のRAGではありません。

クエリ時のみチャンクを取得する代わりに、それらは知識をページ、要約、エンティティ、およびリンクに事前構造化しようとする試みです。

これにより、それらはコンパイルされた知識システムに近づきます。

有用な配置：

システム	位置
ウィキ	人間が維持する構造化知識
RAG	クエリ時の機械取得
LLM Wiki	取り込み時の機械構造化知識
メモリ	エージェントの永続的文脈

これがLLM Wikiが通常のRAG内ではなく、知識システムアーキテクチャの近くに属する理由です。

実用的な例

例1. 個人的な技術ブログ

技術ブロガーは以下を使用するかもしれません：

• PKMは研究ノートのために
• 公開された知識としてのHugoサイト
• ウィキのような構造としての内部リンク
• サイト検索のための後からのRAG
• 執筆アシスタントの好みとしてのAIメモリ

これは強力なアーキテクチャです。

AIサポートを可能にしつつ、人間の判断を中心に保ちます。

例2. エンジニアリングチーム

エンジニアリングチームは以下を使用するかもしれません：

• 個人の学習のためのPKM
• 標準とランブックのためのウィキ
• 内部ドキュメントのためのRAGアシスタント
• リポジトリ内で作業するコーディングエージェントのためのメモリ

ウィキは標準的であるべきです。

RAGアシスタントはプロセスを発明すべきではありません。 メモリレイヤーはプロジェクトの好みを記憶すべきですが、アーキテクチャの決定を置き換えるべきではありません。

例3. AI研究ワークフロー

研究者は以下を使用するかもしれません：

• 論文ノートのためのPKM
• 安定した要約のためのウィキ
• 文献検索のためのRAG
• 長期的な研究エージェントのためのメモリ

これは、各レイヤーが異なる時間スケールを処理するため機能します。

セキュリティとガバナンス

知識システムは機密または古い情報を保存する場合、リスクが生じます。

PKMガバナンス

質問：

• 何がプライベートのまま残るべきか？
• 何が公開されるべきか？
• 何が削除されるべきか？

ウィキガバナンス

質問：

• 各ページの所有者は誰か？
• 最後に見直されたのはいつか？
• 何が標準的か？

RAGガバナンス

質問：

• どのソースがインデックス化されているか？
• 回答は引用されているか？
• 取得はどのように評価されるか？
• どのコンテンツが除外されているか？

メモリガバナンス

質問：

• 何が記憶されるか？
• ユーザーはメモリを検査できるか？
• ユーザーはメモリを削除できるか？
• 誤ったメモリはどのように修正されるか？

メモリは静かに将来の振る舞いに影響を与える可能性があるため、最も厳格なガバナンスを必要とします。

SEOとコンテンツ戦略に関する注意

技術サイト運営の場合、この区別はアーキテクチャ的だけでなく、編集的でもあります。

あなたは以下のようにコンテンツをマッピングできます：

• PKMページは人間の知識実践を説明します。
• ウィキページは構造化知識システムを説明します。
• RAGページは取得エンジニアリングを説明します。
• メモリページは永続的なAI振る舞いを説明します。
• アーキテクチャページはパラダイムを比較し、接続します。

これにより、緩く関連したAI記事の山ではなく、クリーンな権威メッシュがサイトにもたらされます。

最終的な結論

PKM、RAG、ウィキ、およびAIメモリシステムは競合者ではありません。

それらは異なる質問に対する異なる答えです。

PKMは以下を問います：

私は時間とともにどのようにより良く考えるべきか？

ウィキは以下を問います：

私たちは何を知らなければならず、信頼できるバージョンはどこにあるのか？

RAGは以下を問います：

モデルは今すぐどの外部文脈を使用すべきか？

AIメモリは以下を問います：

このエージェントは将来のために何を記憶すべきか？

これらの質問を分離すると、アーキテクチャは明らかになります。

思考にはPKMを使用します。 共有された真実にはウィキを使用します。 取得にはRAGを使用します。 連続性にはメモリを使用します。

未来は他のすべてを置き換える一つの知識システムではありません。

未来は層状知識アーキテクチャです。知識管理スペクトル全体にわたるツール、手法、およびセルフホスト型プラットフォームについては、クラスターピラーが領域をマッピングします。

出典および追加読書

• https://cloud.google.com/use-cases/retrieval-augmented-generation
• https://aws.amazon.com/what-is/retrieval-augmented-generation/
• https://www.ibm.com/think/topics/retrieval-augmented-generation
• https://www.ibm.com/think/topics/knowledge-management
• https://arxiv.org/abs/2310.08560
• https://research.memgpt.ai/
• https://zettelkasten.de/posts/building-a-second-brain-and-zettelkasten/