Bộ nhớ và ngữ cảnh: Giúp các agent ghi nhớ

Trong bài học 4, agent nghiên cứu của bạn có thể tìm kiếm trên web, truy vấn Wikipedia và tổng hợp các phát hiện. Nhưng nếu bạn hỏi agent "Tôi vừa hỏi bạn điều gì?", nó sẽ không nhớ gì cả. Mỗi tin nhắn đều bắt đầu từ đầu. Đó là khoảng trống mà bộ nhớ lấp đầy - và đó là sự khác biệt giữa một công cụ chỉ dùng một lần và một trợ lý thực sự.

Tại sao bộ nhớ lại quan trọng?

Nếu không có bộ nhớ, mọi thao tác thực thi quy trình làm việc đều bị cô lập. AI không biết:

• Người dùng đã hỏi gì 30 giây trước
• Nó đã trả lời điều gì
• Ngữ cảnh mà người dùng đã cung cấp trước đó

Đối với các quy trình làm việc đơn nhiệm như phân loại email (bài học 3), điều này không sao. Nhưng đối với bất kỳ thứ gì mang tính hội thoại - chatbot, nhân viên hỗ trợ, trợ lý cá nhân - bộ nhớ là rất cần thiết. Nghiên cứu cho thấy khoảng 70% người dùng xây dựng quy trình làm việc AI n8n gặp khó khăn trong việc ghi nhớ ngữ cảnh. Đây là nguồn gốc gây khó chịu số 1.

Các loại bộ nhớ trong n8n

n8n cung cấp 4 phương pháp bộ nhớ, mỗi phương pháp đều có những ưu và nhược điểm riêng:

Quá trình phát triển: Bắt đầu với Simple Memory để thử nghiệm → chuyển sang PostgreSQL cho môi trường sản xuất → thêm Redis nếu cần tốc độ đọc dưới mili giây.

Hãy cùng xem xét từng loại.

Simple Memory: Chỉ để thử nghiệm

Simple Memory lưu trữ lịch sử hội thoại trong bộ nhớ runtime của quy trình làm việc. Đây là cách thiết lập nhanh nhất - chỉ cần gắn nó vào AI Agent của bạn là nó sẽ hoạt động.

Tại sao bạn không nên sử dụng nó trong môi trường sản xuất?

• Lịch sử hội thoại biến mất ngay khi quá trình thực thi kết thúc
• Nếu n8n khởi động lại, toàn bộ bộ nhớ sẽ bị mất
• Nó không hoạt động ở chế độ hàng đợi - đây là thiết lập được n8n khuyến nghị để xử lý người dùng đồng thời

Hãy coi Simple Memory như một cuốn sổ tay bị xé vụn sau mỗi cuộc hội thoại. Tốt cho việc thử nghiệm các prompt của bạn. Vô dụng đối với người dùng thực.

PostgreSQL Memory: Mặc định cho môi trường sản xuất

PostgreSQL Memory lưu trữ các cuộc hội thoại trong một cơ sở dữ liệu thực. Nó được lưu giữ sau khi khởi động lại, hỗ trợ truy cập đồng thời và có thể truy vấn bằng SQL.

Thiết lập:

1. Bạn cần một cơ sở dữ liệu PostgreSQL (n8n Cloud đã bao gồm một cơ sở dữ liệu, hoặc bạn có thể tự chạy cơ sở dữ liệu của riêng mình)
2. Thêm một node con Postgres Chat Memory vào AI Agent của bạn
3. Cấu hình thông tin kết nối (máy chủ, cơ sở dữ liệu, người dùng, mật khẩu)
4. Đặt Session ID - đây là chìa khóa để nhóm các tin nhắn thành những cuộc hội thoại

ID phiên rất quan trọng. Nó cho n8n biết cần load cuộc hội thoại nào. Một trình kích hoạt trò chuyện thường cung cấp ID này thông qua {{ $json.sessionId }} hoặc bạn có thể lấy nó từ ID người dùng.

✅ Kiểm tra nhanh: Hai người dùng trò chuyện với bot của bạn cùng lúc. Cả hai đều lưu trữ cuộc hội thoại của họ trong PostgreSQL Memory. Làm thế nào để agent giữ cho các cuộc hội thoại của họ được tách biệt?

Đáp án: ID phiên. Mỗi người dùng nhận được một ID phiên duy nhất. Khi Người dùng A gửi tin nhắn, hệ thống chỉ load lịch sử hội thoại của Người dùng A từ PostgreSQL. Lịch sử của Người dùng B được lưu trữ riêng biệt. Nếu không có ID phiên riêng biệt, cả hai người dùng sẽ chia sẻ cùng một cuộc hội thoại - điều này sẽ gây nhầm lẫn và vi phạm quyền riêng tư.

Redis Memory: Cho tốc độ

Redis Memory lưu trữ các cuộc hội thoại trong Redis - một kho dữ liệu trong bộ nhớ cực kỳ nhanh (đọc dưới mili giây).

Nó lý tưởng cho:

• Bot có thông lượng cao xử lý hàng trăm cuộc hội thoại đồng thời
• Các ứng dụng thời gian thực nơi độ trễ là yếu tố quan trọng
• Các cuộc hội thoại cần tự động hết hạn (Redis hỗ trợ TTL - thời gian tồn tại)

Thiết lập:

Tương tự như PostgreSQL - thêm một node con Redis Chat Memory, cung cấp kết nối Redis của bạn, đặt ID phiên. Điểm khác biệt chính: Bạn có thể đặt TTL để các cuộc hội thoại tự động hết hạn sau một khoảng thời gian nhất định (hữu ích cho các cuộc trò chuyện hỗ trợ không cần lịch sử vĩnh viễn).

Đối với hầu hết các quy trình làm việc, PostgreSQL là lựa chọn phù hợp. Redis được sử dụng khi bạn tối ưu hóa hiệu suất ở quy mô lớn.

Window Buffer: Giới hạn ngữ cảnh

Window Buffer không phải là một loại lưu trữ - mà là một chiến lược. Nó chỉ giữ lại N tin nhắn gần nhất trong cửa sổ ngữ cảnh thay vì toàn bộ lịch sử hội thoại.

Tại sao lại giới hạn tin nhắn? Các mô hình LLM có giới hạn token. Một cuộc hội thoại với 200 tin nhắn có thể vượt quá cửa sổ ngữ cảnh của mô hình, gây ra lỗi hoặc cắt bớt âm thầm. Window Buffer giữ lại các tin nhắn gần đây nhất (ví dụ: 20 tin nhắn gần nhất) để agent luôn có ngữ cảnh gần đây mà không vượt quá giới hạn token.

Bạn kết hợp Window Buffer với một hệ thống lưu trữ:

• Window Buffer + PostgreSQL = lưu trữ mọi thứ, load N tin nhắn gần nhất
• Window Buffer + Redis = cùng ý tưởng, đọc nhanh hơn

Xây dựng: Chatbot với bộ nhớ bền vững

Hãy nâng cấp agent nghiên cứu của bạn từ bài học 4 với PostgreSQL Memory.

Bước 1: Bắt đầu từ agent của bài học 4

Mở Multi-Tool Research Agent mà bạn đã xây dựng trong bài học 4 (Kích hoạt trò chuyện → AI Agent với các công cụ).

Bước 2: Thêm PostgreSQL Memory

1. Nhấp vào node AI Agent
2. Trong mục Memory, thêm node con Postgres Chat Memory
3. Cấu hình kết nối đến phiên bản PostgreSQL của bạn
4. Đặt Session ID Key: {{ $json.sessionId }}

Nếu đang sử dụng n8n Cloud, bạn có thể sử dụng PostgreSQL tích hợp sẵn của n8n. Nếu tự host, hãy kết nối với bất kỳ cơ sở dữ liệu PostgreSQL nào.

Bước 3: Cập nhật prompt hệ thống

Thêm hướng dẫn quản lý bộ nhớ vào prompt hệ thống của bạn:

Bạn là trợ lý nghiên cứu với khả năng ghi nhớ hội thoại.

Khi người dùng đặt câu hỏi tiếp theo:
- Tham khảo thông tin từ phần trước của cuộc hội thoại
- Không lặp lại thông tin bạn đã cung cấp
- Nếu người dùng nói "như tôi đã đề cập" hoặc "như chúng ta đã thảo luận", hãy kiểm tra lại trí nhớ của bạn

Khi chào đón người dùng quay lại:
- Xác nhận cuộc hội thoại trước đó nếu có liên quan
- Đừng bắt đầu lại từ đầu mỗi lần

Bước 4: Kiểm tra tính liên tục

Nhấp vào "Test workflow" và thực hiện một cuộc hội thoại nhiều lượt:

1. "Dân số Nhật Bản là bao nhiêu?"
2. "So với Hàn Quốc thì sao?"
3. "Nước nào có GDP bình quân đầu người cao hơn?"

Nếu không có bộ nhớ, câu hỏi thứ 2 sẽ thất bại - chatbot sẽ không biết "đó" là gì. Với PostgreSQL Memory, chatbot sẽ load các cuộc hội thoại trước đó và hiểu ngữ cảnh.

Bây giờ, hãy đóng cuộc trò chuyện và mở lại (sử dụng cùng ID phiên). Hỏi: "Chúng ta đang nói về điều gì?". Chatbot sẽ nhớ lại cuộc thảo luận về Nhật Bản/Hàn Quốc của bạn - vì bộ nhớ được lưu trữ trong cơ sở dữ liệu.

✅ Kiểm tra nhanh: Chatbot của bạn hoạt động trong môi trường thử nghiệm nhưng lại quên các cuộc hội thoại trong môi trường sản xuất. Điều đầu tiên cần kiểm tra là gì?

Câu trả lời: ID phiên. Trong quá trình thử nghiệm, Chat Trigger có thể tạo ra một ID phiên tĩnh. Trong môi trường sản xuất, mỗi người dùng cần một ID phiên nhất quán, duy nhất - thường được tạo ra từ ID người dùng hoặc token xác thực của họ. Nếu ID phiên thay đổi giữa các tin nhắn hoặc mặc định thành một giá trị ngẫu nhiên, bộ nhớ sẽ load một cuộc hội thoại mới mỗi lần.

Chi phí bộ nhớ và token

Bộ nhớ càng nhiều thì càng cần nhiều token cho mỗi yêu cầu. Mỗi tin nhắn trong lịch sử hội thoại đều được gửi đến LLM dưới dạng ngữ cảnh. Một cuộc hội thoại 50 tin nhắn có thể thêm hơn 5.000 token vào mỗi yêu cầu tiếp theo.

Các chiến lược quản lý chi phí:

• Window Buffer: Chỉ load 10 - 20 tin nhắn gần nhất thay vì toàn bộ lịch sử
• Summary Memory: Định kỳ tóm tắt các tin nhắn cũ thành một bản tóm tắt ngắn gọn (yêu cầu một lệnh gọi LLM riêng biệt)
• Selective Memory: Chỉ lưu trữ các tin nhắn chứa ngữ cảnh quan trọng (sở thích người dùng, quyết định) - bỏ qua những tin nhắn xã giao

Đối với hầu hết các trường hợp sử dụng, Window Buffer gồm 15 - 20 tin nhắn là điểm tối ưu giữa nhận biết ngữ cảnh và chi phí.

Những điểm chính cần ghi nhớ

• Bộ nhớ đơn giản chỉ dành cho mục đích thử nghiệm - dữ liệu sẽ biến mất sau khi thực thi và bị lỗi ở chế độ hàng đợi
• PostgreSQL Memory là mặc định cho môi trường sản xuất - bền vững, đồng thời, có thể truy vấn
• Redis Memory dành cho các kịch bản thông lượng cao, nơi việc đọc dữ liệu dưới mili giây là rất quan trọng
• Window Buffer giới hạn số lượng tin nhắn mà agent load - rất cần thiết để quản lý chi phí token
• ID phiên xác định cuộc hội thoại nào mà agent load - nếu thiết lập sai, mọi tin nhắn sẽ bắt đầu lại từ đầu
• Luôn cập nhật prompt hệ thống của bạn để nhận biết bộ nhớ - hãy cho agent biết cách sử dụng lịch sử hội thoại