Bỏ qua đến nội dung chính
Về trang chủ
AI tools-ai 7 phút đọc

Elasticsearch: Xây Dựng Bộ Nhớ Dai Dẳng Cho AI Agent Đạt Độ Thu Hồi 0.89 Và Bảo Mật Tuyệt Đối! 🧠🔍

Elasticsearch Labs đã phát triển một lớp bộ nhớ dai dẳng, đa người thuê cho các tác nhân AI dựa trên Elasticsearch, đạt tỷ lệ thu hồi 0.89 ấn tượng và đảm bảo không có rò rỉ dữ liệu giữa các người dùng.

Tier 2 · nguồn 99% độ tin cậy Auto-priority
Nguồn gốc elastic.co

Kalera News xin giới thiệu một nghiên cứu đột phá từ Elasticsearch Labs về cách xây dựng một hệ thống bộ nhớ bền vững và hiệu quả cho các tác nhân AI. Công trình này không chỉ giải quyết các hạn chế cố hữu của cửa sổ ngữ cảnh mà còn đạt được độ chính xác cao và bảo mật tuyệt đối.

Nguồn gốc: Elasticsearch Labs Blog Tác giả: Noam Schwartz (Elasticsearch Labs) Ngày công bố: 16 tháng 6 năm 2026

🚀 Thành Tựu Nổi Bật:

* Xây dựng thành công lớp bộ nhớ tác nhân (agent memory) bền vững, đa người thuê trên Elasticsearch. * Đạt tỷ lệ Recall@10 trung bình là 0.89 trên 168 câu hỏi. * Đảm bảo không có rò rỉ dữ liệu giữa các người thuê (zero cross-tenant leaks). * Mã nguồn mở có sẵn trên GitHub (atlas-memory-demo).

---

💡 Vấn Đề Cốt Lõi: Cửa Sổ Ngữ Cảnh và Bộ Nhớ Dài Hạn

Việc phụ thuộc hoàn toàn vào cửa sổ ngữ cảnh (context window) lớn cho bộ nhớ của tác nhân AI là không hiệu quả, tốn kém và gặp phải độ trễ cùng hiệu ứng "lạc giữa" (lost in the middle effect) – thông tin quan trọng bị bỏ qua khi nằm ở giữa một ngữ cảnh dài.

> "Một cửa sổ ngữ cảnh 1 triệu token chỉ là một cuốn sổ nháp, không phải hệ thống bộ nhớ. Cửa sổ ngữ cảnh là bộ nhớ ngắn hạn: không gian suy luận chủ động cho một lần suy luận duy nhất. Cái thiếu sót ở đây là bộ nhớ dài hạn: một kho lưu trữ bền vững tồn tại sau khi phiên làm việc kết thúc, có thể mở rộng tới hàng năm tương tác, và cho phép bạn truy xuất thông tin theo nội dung, thời gian và người dùng."

---

1. Kiến Trúc Ba Chỉ Mục (Phân Tách Nhận Thức)

Để ngăn bộ nhớ trở thành một "đống rơm" khó quản lý, kiến trúc này ánh xạ bộ nhớ tới ba chỉ mục Elasticsearch riêng biệt, dựa trên tâm lý học nhận thức:

* Bộ nhớ theo sự kiện (Episodic Memory): Lưu trữ các lượt tương tác thô của người dùng theo thời gian. Hầu hết là ngắn hạn, nhưng một số đóng vai trò bằng chứng cho các sự kiện bền vững. * Bộ nhớ ngữ nghĩa (Semantic Memory): Lưu trữ các sự kiện/thông tin ổn định, chắt lọc về người dùng (ví dụ: "Sarah sở hữu một Lumio Hub v2"). Những thông tin này tồn tại qua nhiều phiên và là cơ sở để tác nhân hiểu người dùng. * Bộ nhớ quy trình (Procedural Memory): Lưu trữ các quy trình và bước khắc phục sự cố (ví dụ: "Cách khắc phục sự cố mất kết nối Zigbee"). Mỗi quy trình có số lần thành công (success_count) và thất bại (failure_count) được cập nhật trong quá trình củng cố.

---

2. Quy Trình Thu Hồi: Truy Xuất Kết Hợp & Xếp Hạng Lại

Truy xuất bộ nhớ sử dụng một quy trình tìm kiếm kết hợp hai giai đoạn:

* Giai đoạn 1: Hợp nhất xếp hạng nghịch đảo (Reciprocal Rank Fusion - RRF) * Nhánh BM25: Thu thập các kết quả khớp từ khóa chính xác (số phiên bản, mã lỗi, tên riêng). * Nhánh vector dày đặc (Dense Vector): Thu thập ý nghĩa ngữ nghĩa bằng cách sử dụng nhúng Jina v5 (tự động tạo thông qua ánh xạ trường semantic_text của Elasticsearch). * Cấu hình: Tìm nạp quá mức 80 ứng viên mỗi nhánh và hợp nhất chúng bằng RRF với rank_constant=30 (chặt chẽ hơn mức mặc định 60 của ES để các mục được xếp hạng cao nhất chiếm ưu thế). * Giai đoạn 2: Xếp hạng lại bằng bộ mã hóa chéo (Cross-Encoder Reranking) * Một bộ mã hóa chéo Jina v2 cùng chấm điểm các ứng viên đã hợp nhất với truy vấn của người dùng để đạt độ liên quan chính xác cao.

#### Tối ưu hóa trước thu hồi

Các tác nhân thường diễn giải lại truy vấn, bỏ đi số seri hoặc mã lỗi chính xác. Để ngăn chặn điều này, hệ thống chạy một quá trình tiền thu hồi tự động trên thông điệp nguyên văn của người dùng vào đầu mỗi lượt, đưa trực tiếp kết quả vào ngữ cảnh hội thoại.

---

3. Ghi, Củng Cố và Khả Năng Hiển Thị Ngay Trong Lượt Tương Tác

#### Ghi dữ liệu trực tiếp (Hot-Path Writing)

Mỗi lượt tương tác của người dùng ngay lập tức ghi một sự kiện theo sự kiện. Các phản hồi của tác nhân bị bỏ qua để tránh văn xuôi dài làm lu mờ các thông tin thực tế của người dùng.

#### Khả năng hiển thị ngay trong lượt tương tác (refresh=True)

* Vấn đề: Khoảng thời gian làm mới không đồng bộ mặc định của Elasticsearch tạo ra một khoảng trống truyền bá. Nếu người dùng cung cấp một thông tin và hỏi về nó trong cùng một lượt, tài liệu mới ghi có thể không hiển thị cho lệnh gọi công cụ thu hồi ngay lập tức. * Giải pháp: Mỗi lệnh gọi write_memory truyền refresh=True, buộc phân mảnh phải làm mới và nhúng Jina v5 phải "cập bến" trước khi lệnh gọi ghi trả về.

#### Củng cố (Consolidation)

Một quy trình nền (được mô phỏng mỗi lượt trong bản demo) sử dụng LLM để củng cố các nhật ký theo sự kiện thành các sự kiện ngữ nghĩa và các quy trình. LLM được cung cấp các sự kiện gần đây, các sự kiện và quy trình hiện có. Nó xuất ra các sự kiện ngữ nghĩa mới (yêu cầu supporting_episode_ids để chứng minh nguồn gốc), các quy trình mới và cập nhật success_count/failure_count.

* Loại bỏ trùng lặp: Các sự kiện ứng cử viên được so sánh với chỉ mục ngữ nghĩa của người dùng bằng tìm kiếm kết hợp. Nếu điểm tương đồng của một ứng cử viên ≥ 0.90, nó được coi là trùng lặp và bị loại bỏ.

---

4. Xử Lý Mâu Thuẫn và Thay Thế

Thay vì xóa các sự kiện cũ, mâu thuẫn (làm mất dấu vết kiểm toán), hệ thống sử dụng thay thế (supersession):

1. Phát hiện & Phân loại: Khi người dùng cung cấp thông tin cập nhật (ví dụ: "Chúng tôi đã rời Bristol, hiện đang ở Edinburgh"), tác nhân phát hiện xung đột với thông tin đã thu hồi ("Sarah sống ở Bristol"). Nó phân loại mâu thuẫn là natural (cập nhật) hoặc harsh (sửa lỗi). 2. Ghi & Liên kết: Tác nhân gọi write_memory(text="Sarah sống ở Edinburgh", supersedes_id="abc", contradiction="natural"). * Một tài liệu mới được ghi. * Tài liệu cũ được cập nhật với superseded_by="xyz"superseded_at=<thời điểm hiện tại>.

---

5. Bảo Mật & Đa Người Thuê (DLS Isolation)

Trong các thiết lập doanh nghiệp, việc rò rỉ giữa bộ nhớ người dùng là tối quan trọng. Thiết kế này đạt được không rò rỉ giữa các người thuê (zero cross-tenant leaks) bằng cách sử dụng Bảo mật cấp tài liệu (Document-Level Security - DLS) gốc của Elasticsearch:

* Mỗi tài liệu có một trường tenant_id. * Token truy vấn của người dùng bị giới hạn theo vai trò của họ sẽ tự động thêm truy vấn DLS: "term": { "tenant_id": "sarah_tenant" }. * Ngay cả khi chỉ mục vector khớp với các khái niệm của người dùng khác, chúng vẫn được lọc vật lý ở cấp độ chỉ mục trước khi hợp nhất RRF hoặc xếp hạng lại xảy ra. Điều này đảm bảo tính riêng tư và bảo mật dữ liệu tuyệt đối cho từng người dùng. 🔒