# Các loại memory cho AI agent và khi nào nên nâng cấp

[Duke Pan](https://homus.dev/speakers/duke-pan) · [Duke Pan](https://homus.dev/orgs/duke-pan)

> Bốn loại memory cho AI agent: AGENTS.md, vector search, knowledge graph, bảng dữ liệu; khi nào bỏ grep, và thử câu hỏi thật trước khi nâng cấp.

Topics: Context Engineering, Agents, Retrieval, Skills

Canonical: https://homus.dev/talks/every-type-of-ai-agent-memory-explained-in-15-minutes

## 1. Khi nào nên nâng cấp memory cho AI?

Duke Pan mở video (đăng ngày 14/10/2026) bằng một câu hỏi: tới lúc nào thì việc nâng cấp hệ thống memory cho AI agent của bạn mới có ý nghĩa? Nói gọn lại, đó là chuyện AI của bạn nhớ về bạn theo cách nào, so với việc chỉ để mọi thứ nằm sẵn trên máy, trong các file và folder của workspace.

![Duke Pan nói trước camera, bên trái là slide 'When do you upgrade your AI's memory?'](https://homus.dev/photos/o2jphteA_GY-0003.jpg)

Slide mở đầu đặt câu hỏi "When do you upgrade your AI's memory?" (khi nào bạn nâng cấp memory cho AI), cạnh khung hình Duke nói trước camera.

Có lẽ bạn đã nghe tới khái niệm "second brain" (bộ não thứ hai) mà ai cũng nhắc. Nhưng theo Duke (video đăng ngày 14/10/2026), phần lớn mọi người chỉ có một phiên bản rất đơn giản của nó: về cơ bản chỉ là các file markdown. Và theo anh, cách đó sẽ không scale được cho doanh nghiệp lớn, cho cả doanh nghiệp cỡ vừa, thậm chí cho cả workflow chạy trên máy của riêng bạn nếu workflow đó có nhiều dữ liệu.

![Slide 'Most people have the simple version': cây thư mục workspace gồm AGENTS.md, notes, clients.md, projects.md](https://homus.dev/photos/o2jphteA_GY-0023.jpg)

Slide "The second brain: most people have the simple version": một workspace chỉ gồm các file markdown (AGENTS.md, folder notes/ với ideas.md và meetings.md, clients.md, projects.md). Bên phải, slide ghi rằng nếu làm theo cách ngây thơ (naively), nó sẽ không scale cho doanh nghiệp lớn và doanh nghiệp cỡ vừa; đây là nhận định của Duke trong video đăng ngày 14/10/2026.

## 2. Ba câu hỏi cần trả lời

Video xuất phát từ một câu hỏi anh nhận được. Theo Duke, trong đó thật ra có ba câu hỏi:

- Tới lúc nào thì nên tạo ra những cách khác nhau để truy vấn (query) memory?

- Đâu là những phương pháp truy vấn hay được dùng nhất?

- Các cấu trúc memory đó là gì, và xây chúng thế nào với những công nghệ đang có? Duke (video đăng ngày 14/10/2026) kể ra vài cái phổ biến như Convex, Postgres, cùng vài cái khác sẽ nói trong video.

Mục tiêu anh đặt ra cho video (đăng ngày 14/10/2026): xem hết video, bạn sẽ hiểu khá rõ các cấu trúc memory cho AI agent và khi nào nên dùng từng cái.

Ba câu hỏi mà Duke tách ra từ câu hỏi anh nhận được, và cũng là ba phần video (đăng ngày 14/10/2026) trả lời.

## 3. Cách tra cứu mặc định: keyword search với grep và ripgrep

Trước khi nói tới các phương pháp memory nâng cao, Duke muốn bạn hiểu rằng đã có sẵn một cơ chế truy xuất (retrieval) mặc định mà AI hay dùng: **keyword search**, tìm theo từ khoá. Nó còn được biết tới qua tên công cụ: `grep` hoặc `ripgrep`. Theo Duke (video đăng ngày 14/10/2026), cách này thật ra chạy rất tốt, nhất là khi bạn đang tìm những chỗ khớp chính xác (exact match).

![Slide 'The default: keyword search' với lệnh rg invoice và ba dòng kết quả](https://homus.dev/photos/o2jphteA_GY-0123.jpg)

Slide "Before the advanced methods: the default, keyword search" với hai nhãn GREP và RIPGREP (RG). Ví dụ trên slide là lệnh `rg "invoice"` trả về ba dòng, mỗi dòng có tên file, số dòng và đoạn chữ chứa từ "invoice", như `notes/clients.md:12` "sent the invoice on Friday" (slide trong video đăng ngày 14/10/2026).

## 4. Demo ripgrep trong workspace DukeBot

Duke chuyển sang một ví dụ thật. Folder của anh tên là DukeBot: đó là AI workspace của anh, "AI của tôi, gọi sao cũng được". Anh mở terminal, tức command line, nơi anh có thể nói chuyện trực tiếp với máy tính, gõ lệnh để điều khiển máy. Theo Duke (video đăng ngày 14/10/2026), nếu bạn dùng Mac thì nó tên là Terminal, cứ mở lên là dùng; nếu dùng Windows thì đó là Command Prompt.

Trong đó anh dùng `rg`, tức ripgrep. Anh nói nếu muốn tự thử, bạn chỉ cần chạy lệnh dưới đây là có công cụ này (README của ripgrep cũng ghi lệnh này, đọc ngày 28/10/2026):

```
brew install ripgrep
```

Theo Duke (video đăng ngày 14/10/2026), phần lớn thời gian chính AI đang dùng công cụ này. Anh gõ thử lệnh tìm chữ "dukebot", đúng như trên màn hình demo:

```
rg dukebot
```

Theo Duke (video đăng ngày 14/10/2026), lệnh này tìm mọi chỗ xuất hiện của mẫu (pattern) đó, tức từ "dukebot", bên trong folder DukeBot và mọi folder bên dưới. Nó chạy đệ quy (recursively): xem cả các subfolder và file, rồi cho biết từ đó nằm ở đâu.

Trong kết quả (demo trong video đăng ngày 14/10/2026), Duke chỉ vào một file có tên kết thúc bằng `youtube_set_thumbnail.py`. Những dòng màu hồng là tên file; ngay dưới là số dòng. Ví dụ, ở dòng 30 trong file đó có một đoạn chữ chứa từ "dukebot". Trên màn hình demo có chú thích "Pink = file name · number = line". Anh nhấn mạnh nó tìm ra tất cả những chỗ xuất hiện này nhanh thế nào, và theo anh, đó là cách AI của bạn truy xuất dữ liệu trong phần lớn trường hợp.

Cách đọc kết quả `rg` theo chú thích trên màn hình demo của Duke (video đăng ngày 14/10/2026): tên file in màu hồng, mỗi dòng bên dưới bắt đầu bằng số dòng rồi tới đoạn chữ khớp.

Đó chính là keyword search. Theo Duke (video đăng ngày 14/10/2026), nó rất giỏi tìm chỗ khớp chính xác, và cũng rất nhanh. Nhưng bạn sẽ thấy nó không phải lựa chọn tốt nhất cho mọi tình huống.

## 5. Bốn loại memory, và loại đơn giản nhất: AGENTS.md / CLAUDE.md

Vậy memory cho AI agent có những loại nào, những cấu trúc nào? Theo Duke (video đăng ngày 14/10/2026), thường có bốn loại.

![Slide '4 types of memory': AGENTS.md / CLAUDE.md, vector search, knowledge graph, tabular](https://homus.dev/photos/o2jphteA_GY-0303.jpg)

Slide "Long-term memory for AI agents: 4 types of memory". Ô đầu tiên được tô đậm, nhãn "The simple one": AGENTS.md / CLAUDE.md, một file markdown. Ba ô còn lại đánh số 1 tới 3: vector search (câu hỏi ra câu trả lời), knowledge graph (relationship) và tabular (dữ liệu cùng một dạng). Đây là cách Duke chia trong video đăng ngày 14/10/2026.

Loại thứ nhất là loại đơn giản nhất: về cơ bản chỉ là một file markdown tên `AGENTS.md` hoặc `CLAUDE.md` mà hầu hết chúng ta đều biết. Theo Duke (video đăng ngày 14/10/2026), lý do nó được xem là long-term memory là vì nó được đưa (inject) vào mọi chat session, bên trong mỗi chat session bạn dùng. Thông tin gì bạn đặt vào đó thì mọi chat session mở ra sau này cũng sẽ có thông tin đó. Vì vậy nó nhớ những điều đó lâu dài. Trên slide tiếp theo, một file AGENTS.md nối tới ba ô "Chat session 1", "Chat session 2", "Chat session 3", ô nào cũng có dấu tích.

Nhưng theo Duke (video đăng ngày 14/10/2026), cách này rất đơn giản vì nó thật sự chỉ là một file. Bạn không nên nhồi quá nhiều thông tin vào đó. Nó chủ yếu chỉ chứa vài hướng dẫn ở mức bề mặt, hoặc phần chỉ đường (routing) cho biết những thứ khác nằm ở đâu.

## 6. Cấu trúc 1: vector search cho hỏi đáp

Các loại thú vị hơn bắt đầu với loại số một: **vector search**. Duke đoán đây là thứ bạn đã từng nghe. Theo anh (video đăng ngày 14/10/2026), nó thật sự tốt cho mọi kiểu hỏi đáp (Q&A). Use case của bạn là muốn đặt một câu hỏi và nhận về câu trả lời, những câu hỏi lặp đi lặp lại, kiểu:

- "Doanh thu quý trước là bao nhiêu?" ("What was the revenue last quarter?")

- "Mình đã nói về X, Y, Z trong video nào?" ("In which video did I talk about X, Y, Z?")

Với những câu hỏi như vậy, khi bạn chỉ muốn một câu trả lời cho một câu hỏi, theo Duke (video đăng ngày 14/10/2026) vector search thường khá tốt. Trên slide, hai câu hỏi đó trỏ vào một ô ghi "One question → one answer", kèm nhãn "Best for Q&A".

Ngược lại, theo Duke (video đăng ngày 14/10/2026), vector search không tốt bằng cho những câu hỏi mang tính quan hệ (relational): "A liên quan tới B thế nào?". Đó không còn là hỏi đáp nữa, mà là chuyện một entity liên quan tới entity khác ra sao. Đó là một kiểu use case khác.

Hai kiểu câu hỏi Duke phân biệt khi nói về vector search (video đăng ngày 14/10/2026): hỏi đáp một câu ra một câu trả lời, và câu hỏi về quan hệ giữa các entity.

## 7. Vector search chạy thế nào: chữ thành số

Duke giải thích cách vector search hoạt động bằng lời đơn giản (video đăng ngày 14/10/2026). Về cơ bản, bạn có một đống dữ liệu, và nó được embed thành các con số. Việc đó dùng một hàm (function). Giả sử trong một video của anh có câu "where is my girlfriend?" (bạn gái tôi đâu rồi?). Câu đó trở thành một dãy số: một hàm biến câu đó thành một dãy số.

![Slide 'Text becomes numbers': dữ liệu 'where is my girlfriend' qua embed() thành dãy số; câu hỏi 'In which video did I talk about my girlfriend?'](https://homus.dev/photos/o2jphteA_GY-0443.jpg)

Slide "How it works: text becomes numbers". Dữ liệu ("Your data": "where is my girlfriend") đi qua hàm `embed( )` để thành một dãy số như `[0.12, -0.48, …]`. Bên dưới là câu hỏi ("Your question": "In which video did I talk about my girlfriend?") sẽ đi qua cùng hàm đó (slide trong video đăng ngày 14/10/2026).

Phần quan trọng cần hiểu, theo Duke (video đăng ngày 14/10/2026), là chính hàm đó cũng được dùng khi bạn đặt câu hỏi "tôi đã nói về bạn gái trong video nào?". Cùng một hàm biến câu hỏi đầu vào thành các con số. Và hai dãy số đó nhiều khả năng sẽ giống nhau. Đó là cách AI của bạn tìm ra video đó nằm ở đâu, hay đó là video nào.

Theo Duke (video đăng ngày 14/10/2026), vì hàm này dùng toán học nên nó rất nhanh, khác với graph chẳng hạn.

## 8. Cấu trúc 2: knowledge graph và bài toán scale

Graph, theo Duke (video đăng ngày 14/10/2026), là thứ hay được dùng cho các second brain. Anh nói Karpathy cũng đã làm cách này phổ biến, với kiểu dựng toàn bộ hệ thống trên máy chỉ bằng một prompt duy nhất.

![Slide 'Knowledge graph': các node note, idea, person, topic, project nối với nhau; hai ô 'Small, local data: works well' và 'Medium scale: I don't recommend it'](https://homus.dev/photos/o2jphteA_GY-0523.jpg)

Slide "Structure 2: knowledge graph". Bên trái là một graph nhỏ với các node note, idea, person, topic, project, có nhãn "Popular local 'second brain' setup". Bên phải, dưới tiêu đề "The problem: scale", là hai ô: dữ liệu nhỏ, trên máy thì "works well"; quy mô vừa thì "I don't recommend it". Đây là đánh giá của Duke trong video đăng ngày 14/10/2026.

Nhưng theo Duke (video đăng ngày 14/10/2026), vấn đề là cách này thường không scale tốt lắm. Nó có thể tốt cho dữ liệu nhỏ, nằm hẳn trên máy, nhưng với quy mô vừa và lớn, anh nói thật là anh không khuyên dùng. Ngay sau đó anh nói thêm: với quy mô lớn thì nó có thể rất tốt, nhưng cực kỳ khó dựng, vì bạn phải định nghĩa các node entity và các relationship giữa chúng.

## 9. Định nghĩa entity và relationship: vì sao khó

Duke đưa một ví dụ (video đăng ngày 14/10/2026). Bạn có một node chứa toàn bộ dữ liệu doanh thu của công ty. Sau đó bạn cần định nghĩa, chẳng hạn, vài metric: cột A cộng với cột B là doanh thu, tức là cách tính doanh thu cho công ty này.

Rồi bạn còn phải định nghĩa relationship: metric này được tính trên table entity kia. Như vậy bạn phải định nghĩa table entity, metric entity, có thể thêm cả definition hay ontology entity. Theo Duke (video đăng ngày 14/10/2026), nếu muốn làm cho tốt thì việc này khá phức tạp.

Ví dụ entity và relationship theo slide "Why it's hard: you define every entity and relationship" trong video của Duke (đăng ngày 14/10/2026): một metric entity tính doanh thu từ cột A và cột B, "calculates over" một table entity chứa toàn bộ dữ liệu doanh thu, và bạn phải tự định nghĩa cả ba loại entity.

Theo Duke (video đăng ngày 14/10/2026), nếu bạn chỉ có phiên bản markdown nằm trên máy của mình thì nó sẽ chạy tốt cho bạn. Nhưng phần lớn trường hợp, nếu bạn đang cố xây nó cho một công ty, anh không khuyên dùng.

## 10. Cấu trúc 3: tabular, nhiều dữ liệu cùng một dạng

Loại thứ ba là **tabular**, dữ liệu dạng bảng. Theo Duke (video đăng ngày 14/10/2026), đây là loại phổ biến nhất. Về cơ bản nó chỉ là một cách lưu dữ liệu có schema: dùng khi bạn có một khối lượng lớn dữ liệu cùng một loại, cùng một schema.

Anh lấy chính mình làm ví dụ (video đăng ngày 14/10/2026). Giả sử anh phải lưu tất cả video của anh: nội dung của anh có tới hàng trăm video, và mỗi video khá đồng nhất. Video nào cũng có tiêu đề, thumbnail, mô tả, chủ đề, một bản tóm tắt, và có thể thêm các phần (section): phần một nói gì, phần hai nói gì, phần ba nói gì, cùng một ít metadata khác. Định dạng schema đó, tính theo từng video, là giống nhau.

Nếu bạn có hàng trăm hay hàng nghìn video, mỗi video về cơ bản chỉ là một hàng (row) trong bảng này, và bảng này tên là `video`. Vậy nên khi bắt đầu có nhiều dữ liệu, theo Duke (video đăng ngày 14/10/2026), bạn sẽ muốn lưu dữ liệu vào một bảng, và bạn phải định nghĩa schema của bảng đó: những cột nào, những cột hay dùng nào mà bạn muốn query được.

![Slide 'Define the schema': bảng video với các cột title, thumbnail, description, topic, summary, sections](https://homus.dev/photos/o2jphteA_GY-0723.jpg)

Slide "Structure 3, tabular: define the schema". Bảng `video` có sáu cột: title, thumbnail, description, topic, summary, sections. Bên dưới ghi "Schema = the columns you'll query most" và một ô có dấu tích "Ask your AI to define it", theo cách Duke trình bày trong video đăng ngày 14/10/2026.

Theo Duke (video đăng ngày 14/10/2026), bạn có thể nhờ AI định nghĩa schema này cho bạn, nhưng sẽ tốt cho bạn nếu bạn hỏi AI một cách rõ ràng, để nó định nghĩa, và đồng thời chính bạn cũng nắm được schema đó thật ra trông thế nào.

## 11. Cách Duke dùng: bảng footage_segments có vector embedding

Rồi Duke ghép các loại lại với nhau. Ví dụ anh dùng cho chính mình (theo video đăng ngày 14/10/2026): anh có một bảng tên `footage_segments`. Trong bảng này có đúng những thứ anh vừa kể: các section của video, tóm tắt, timestamp, đủ loại metadata cho một video. Mỗi hàng còn có thêm một embedding, tức vector embedding của các section trong video: section này anh nói gì, section kia anh nói gì, tất cả được đổi thành một dãy số để dùng cho vector search.

![Slide 'Video sections, searchable by meaning': bảng content_research.footage_segments, 213 rows with vectors, các cột video, section summary, timestamps, embedding](https://homus.dev/photos/o2jphteA_GY-0743.jpg)

Slide "How I use it: video sections, searchable by meaning". Tên bảng trên slide là `content_research.footage_segments`, kèm nhãn "213 rows with vectors" (theo slide trong video đăng ngày 14/10/2026). Các cột: video, section summary, timestamps, embedding; ba hàng ví dụ được ghi rõ là "Illustrative rows" (hàng minh hoạ).

Nhờ vậy anh có thể hỏi kiểu: "mình đã nói về memory trong video nào trước đây?". Anh có nhiều video nói về cách memory hoạt động và cách dựng nó cho AI agent. Theo Duke (video đăng ngày 14/10/2026), anh trả lời được câu hỏi Q&A đó qua AI agent của mình vì agent có quyền dùng tool để truy cập dữ liệu dạng bảng của anh. Dữ liệu được lưu trong bảng, trong bảng video này.

Anh còn có một skill dựng cho AI của mình (theo video đăng ngày 14/10/2026). Về cơ bản skill đó cho AI biết rằng có tồn tại một database, một SQL database; với anh, đó là Neon.

## 12. Xây ở đâu: Postgres, Neon và Convex

Duke kể vài công nghệ phổ biến. Theo anh (video đăng ngày 14/10/2026), vector search có ở cả Postgres, Neon và Convex; bạn chỉ cần bảo AI implement nó trên bất kỳ cái nào trong số đó là sẽ chạy.

![Slide 'Where to build it': ba ô Postgres (SQL, pgvector for vectors), Neon (Hosted Postgres (SQL), Scales very well), Convex](https://homus.dev/photos/o2jphteA_GY-0903.jpg)

Slide "Common tech: where to build it" lúc Duke đang nói về Neon: ô Postgres ghi "SQL" và "pgvector for vectors", ô Neon ghi "Hosted Postgres (SQL)" và "Scales very well", ô Convex mới chỉ có tên. Thanh dưới cùng ghi rằng cả ba đều hỗ trợ vector search và bạn có thể nhờ AI implement; đây là thông tin trên slide trong video đăng ngày 14/10/2026.

Theo Duke (video đăng ngày 14/10/2026), Neon thật ra chính là Postgres: nó là một bản implement của Postgres và cho phép bạn host database trên nền tảng của họ. Anh nói nó scale rất tốt, và nó được làm bởi Databricks. Vì vậy anh khuyên dùng Neon cho SQL; nó là một SQL database.

Còn Convex, theo Duke (video đăng ngày 14/10/2026), là một NoSQL database, cũng scale rất tốt, và rất hợp cho các ứng dụng full-stack. Anh khuyên dùng cái nào trong hai cũng được, và cái nào cũng có khả năng vector search.

Trong file skill cho agent của mình (theo video đăng ngày 14/10/2026), anh ghi khái niệm về quyền truy cập database, và về việc trong đó có sẵn vector embedding.

## 13. Từ câu hỏi tới skill tới vector search, so với keyword search

Duke kể agent của anh xử lý câu hỏi thế nào (theo video đăng ngày 14/10/2026). Khi anh hỏi AI "mình đã nói về X, Y, Z trong video nào?", nó thấy: được rồi, mình có một skill chỉ ra rằng có một database chứa video, nên câu trả lời có lẽ nằm ở đây. Rồi nó cũng thấy bảng này đã có sẵn vector embedding. Thế là nó dùng vector search thẳng trên bảng này để tìm câu trả lời. Theo anh, việc này rất nhanh. Slide lúc đó có tiêu đề "What my agent does: question → skill → vector search", với hai bước: câu hỏi "In which video did I talk about X, Y, Z?" và "Skill: video data lives in a database".

Theo Duke (video đăng ngày 14/10/2026), giờ hãy tưởng tượng nếu nó phải dùng grep, tức keyword search mặc định. Nó chỉ đơn giản tìm, chẳng hạn, từ "memory". Và giả sử anh có hàng trăm hay hàng nghìn video: nó phải đi qua lời nói của từng video một để tìm từ "memory".

![Slide 'Keywords vs meaning': bên trái keyword search grep memory qua từng video, một kết quả không liên quan; bên phải vector search với AI agent memory, memory architecture](https://homus.dev/photos/o2jphteA_GY-1043.jpg)

Slide "Same question, two ways: keywords vs meaning". Bên trái, keyword search chạy `grep "memory"` qua lời nói của từng video một, bắt được câu "…I forgot, my memory of two days ago…" bị gắn nhãn "Irrelevant hit", và "No semantic search". Bên phải, vector search với các cụm như "AI agent memory" và "memory architecture". Đây là so sánh của Duke trong video đăng ngày 14/10/2026.

Có khi anh còn chẳng thật sự nói về memory theo nghĩa quan trọng. Có thể anh chỉ nhắc tới chữ memory kiểu "ôi, tôi quên mất kỷ niệm (memory) của hai ngày trước" hay gì đó, một thứ không liên quan gì tới AI agent. Theo Duke (video đăng ngày 14/10/2026), khi đó keyword search cũng không tìm được đúng chỗ vì nó không có semantic search, nhất là khi câu hỏi của anh là về AI agent memory, hay memory architecture, hay bất kỳ tổ hợp từ nào như vậy.

Với vector search, độ giống nhau thể hiện qua các con số toán học. Theo Duke (video đăng ngày 14/10/2026), nó tìm được đúng thông tin dựa trên ngữ nghĩa (semantics) chứ không chỉ dựa trên keyword khớp chính xác, và nó rất nhanh. Keyword search khớp chính xác có thể cũng tìm ra câu trả lời đúng, nhưng sẽ chậm hơn nhiều vì nó phải tìm keyword chính xác trong toàn bộ chỗ dữ liệu đó.

## 14. Khi nào nâng cấp: thử câu hỏi thật trước

Vậy khi nào dùng loại cấu trúc memory nào? Lời khuyên của Duke (video đăng ngày 14/10/2026): lúc đầu bạn không cần tối ưu quá mức, và chỉ thật sự nâng cấp khi use case xuất hiện.

Anh đưa ví dụ: một doanh nghiệp cần query một câu như "nhân viên sales nào chốt được khách trên 60% số lần?", và họ có hơn 50 nhân viên sales, tức là có rất nhiều dữ liệu. Khi đó, theo Duke, đúng là nhiều khả năng grep không đủ tốt nữa, tuỳ vào việc model hiện giỏi tới đâu tính tới thời điểm làm video (đăng ngày 14/10/2026).

Anh nhấn mạnh: như bạn thấy, việc thử câu hỏi trước là rất quan trọng. Slide lúc đó có tiêu đề "The rule: test the question first", bước một là "Ask Codex / Claude the real question". Nếu Codex hay Claude không trả lời được, ngay cả khi nó có quyền truy cập dữ liệu đó, tức dữ liệu để trả lời câu hỏi nằm đâu đó trên máy của bạn, hay trên máy của khách hàng của bạn, mà agent vẫn không trả lời được, thì theo Duke (video đăng ngày 14/10/2026) điều đó có nghĩa là bạn cần cải thiện phương pháp truy xuất của nó. Cách nó truy xuất dữ liệu chưa được tối ưu, hoặc chưa đủ tốt.

Quy tắc "test the question first" theo Duke (video đăng ngày 14/10/2026): chỉ khi agent không trả lời được dù dữ liệu nằm sẵn trên máy, bạn mới cần cải thiện cách nó truy xuất.

## 15. Từ file lên một hệ thống memory thật

Trong trường hợp đó, theo Duke (video đăng ngày 14/10/2026), có lẽ bạn sẽ phải nghĩ: được rồi, hãy lưu dữ liệu này tốt hơn là chỉ để trong markdown hay file. Anh đi qua từng bước với ví dụ dữ liệu sales:

- **Lưu dữ liệu vào database.** Đưa toàn bộ thông tin sales vào một database, chẳng hạn Neon hay Convex (theo Duke, video đăng ngày 14/10/2026).

- **Định nghĩa schema.** Những cột nào, hay những field nào trong JSON nếu bạn dùng NoSQL với Convex: tên, tỷ lệ chốt (close rate), bất cứ thứ gì bạn cần để trả lời đúng câu hỏi này. Bạn đưa hết thông tin đó vào (theo Duke, video đăng ngày 14/10/2026).

- **Thêm vector search lên trên.** Nhờ AI tạo một vector search database trên chính database Convex hay Neon đang có, nơi chứa toàn bộ thông tin về nhân viên sales (theo Duke, video đăng ngày 14/10/2026).

- **Để AI chọn thứ cần embed.** Theo Duke (video đăng ngày 14/10/2026), AI của bạn sẽ hiểu được cột nào, thông tin nào trong bảng này cần embed, để sau này bạn có thể truy xuất lại.

![Slide 'From files to a real memory system' với bốn bước: store the data in a database, define the schema, add vector search on top, let your AI choose what to embed](https://homus.dev/photos/o2jphteA_GY-1243.jpg)

Slide "The upgrade: from files to a real memory system" với bốn bước Duke đưa ra trong video đăng ngày 14/10/2026: lưu dữ liệu vào database (Neon hoặc Convex); định nghĩa schema (name, close rate, bất cứ gì trả lời được câu hỏi); thêm vector search lên trên cùng database Neon / Convex đó; để AI chọn những cột cần embed để truy xuất sau này.

Cuối cùng, theo Duke (video đăng ngày 14/10/2026), bạn tạo một skill cho agent. Bạn đưa cho nó một skill để nó biết khi nào cần query, query thế nào, và query cái gì bên trong database của bạn.

Theo Duke (video đăng ngày 14/10/2026), nhiều nền tảng trong số này có sẵn CLI riêng. Lời khuyên của anh: giả sử bạn dùng Neon hay Convex, hãy vào website của họ, ở đó sẽ có tên CLI, và bạn có thể nói thẳng với AI "cài CLI cho Neon" hay "cài CLI cho Convex". Thế là bạn có nó ngay. Rồi bạn nhờ AI tạo một skill để nó biết cách dùng CLI đó cho đúng. Tài liệu của Neon và Convex đều có trang riêng cho CLI (xem phần nguồn, đọc ngày 28/10/2026).

## 16. Tóm tắt ba cấu trúc và bộ câu hỏi test

Để kết luận, Duke tóm lại ba cấu trúc memory video vừa giải thích (theo video đăng ngày 14/10/2026):

- **Vector search**: rất tốt cho hỏi đáp (Q&A), thứ rất phổ biến ở mọi công ty có những câu hỏi kinh doanh kiểu này (theo Duke, video đăng ngày 14/10/2026).

- **Knowledge graph**: cho quan hệ giữa các entity khác nhau. Nhưng theo Duke (video đăng ngày 14/10/2026), nó thường khó scale, nhất là ở công ty lớn, nơi việc implement trở nên rất khó, nên anh không khuyên dùng nó ngay từ đầu.

- **Tabular**: rất phổ biến, gần như công ty nào cũng có dữ liệu dạng bảng, tức là các bảng SQL hay cả bảng NoSQL. Theo Duke (video đăng ngày 14/10/2026), nó rất hợp cho các truy vấn kiểu phân tích: doanh thu là bao nhiêu, xu hướng doanh thu thế nào; nhất là với dữ liệu có schema lặp lại, schema ít thay đổi và có cấu trúc rõ.

Ba cấu trúc memory trong phần tóm tắt của Duke (video đăng ngày 14/10/2026), theo các nhãn trên slide "Recap: 3 memory structures": Q&A, relationships, analytics.

Và điều quan trọng nhất, theo Duke (video đăng ngày 14/10/2026), là có một bộ câu hỏi test. Chỉ khi AI trả lời sai những câu đó thì bạn mới nên implement các phương pháp truy xuất tốt hơn. Tuỳ theo câu hỏi được đặt ra, bạn chọn một phương pháp hoặc kết hợp vài phương pháp, rồi nhờ AI implement chúng cùng nhau.

![Slide 'Keep a test set of questions': Question 1 và 2 answered, Question 3 failed dẫn tới 'Upgrade retrieval for this one'](https://homus.dev/photos/o2jphteA_GY-1423.jpg)

Slide "Most important: keep a test set of questions". Question 1 và Question 2 được đánh dấu "answered", Question 3 "failed" và trỏ tới "Upgrade retrieval for this one". Dải chữ bên dưới ghi "Only when your AI fails: add a better method", quy tắc Duke chốt lại trong video đăng ngày 14/10/2026.

Duke khép video bằng một câu: anh hy vọng video giúp ích cho bạn.

## Nguồn và liên kết

- Tên gốc: Every Type of AI Agent Memory, Explained in 15 Minutes
- Sự kiện: [YouTube](https://homus.dev/events/youtube)
- Video gốc: [https://www.youtube.com/watch?v=o2jphteA_GY](https://www.youtube.com/watch?v=o2jphteA_GY)

- Kênh YouTube Duke Pan (Duke Pan): [youtube.com/channel/UCxE6qpCeMGgyrae2fV-Lhhg](https://www.youtube.com/channel/UCxE6qpCeMGgyrae2fV-Lhhg)

- ripgrep (`rg`), công cụ tìm kiếm đệ quy theo regex; README có lệnh `brew install ripgrep` (đọc ngày 28/10/2026): [github.com/BurntSushi/ripgrep](https://github.com/BurntSushi/ripgrep)

- PostgreSQL: [postgresql.org](https://www.postgresql.org)

- pgvector, extension vector similarity search cho Postgres mà slide nhắc tới (đọc ngày 28/10/2026): [github.com/pgvector/pgvector](https://github.com/pgvector/pgvector)

- Neon: [neon.com](https://neon.com) · tài liệu extension pgvector trên Neon (đọc ngày 28/10/2026): [neon.com/docs/extensions/pgvector](https://neon.com/docs/extensions/pgvector) · Neon CLI (đọc ngày 28/10/2026): [neon.com/docs/reference/neon-cli](https://neon.com/docs/reference/neon-cli)

- Convex: [convex.dev](https://www.convex.dev) · tài liệu Vector Search của Convex (đọc ngày 28/10/2026): [docs.convex.dev/search/vector-search](https://docs.convex.dev/search/vector-search) · Convex CLI (đọc ngày 28/10/2026): [docs.convex.dev/cli](https://docs.convex.dev/cli)

Nguồn: https://homus.dev/talks/every-type-of-ai-agent-memory-explained-in-15-minutes · cập nhật 2026-10-28