#vector-search

Weaviate 1.38 Release

Weaviate 1.38 ra mắt với các tính năng mới như HFresh (chỉ số vector dựa trên đĩa, tối ưu bộ nhớ cho streaming) và MCP Server tích hợp cho phép LLMs tương tác trực tiếp. Bản cập nhật cũng bổ sung async replication mặc định, Boost API (tái xếp hạng truy vấn), nested object filtering, cùng nhiều cải tiến khác như quản lý replica, cấu hình chỉ số vector, và module text2vec-digitalocean.

Lập trình viên phát triển ứng dụng AI hoặc hệ thống vector search cần đọc để cập nhật về MCP Server và Boost API, giúp tối ưu hóa giao tiếp trực tiếp giữa LLM với cơ sở dữ liệu vector và cải thiện hiệu suất tìm kiếm bằng cách xếp hạng kết quả một cách linh hoạt mà không mất bất kỳ dữ liệu nào.

Letting an LLM Pick the Right RAG Page: The Arbiter Pattern at the End of Retrieval

Bài viết giới thiệu "Arbiter Pattern" trong RAG, nơi LLM đóng vai trọng tài bằng cách phân loại và đánh giá các nguồn tài liệu ứng viên dựa trên cấu trúc dữ liệu đầu vào, thay thế phương pháp kết hợp điểm số truyền thống. Tác giả nhấn mạnh embeddings nên là phương pháp cuối cùng trong tài liệu doanh nghiệp do hạn chế trong việc xác định sự vắng mặt của thông tin, trong khi keyword retrieval cung cấp khả năng phủ định chắc chắn. Ngoài ra, bài viết đề cập đến bộ chọn phương pháp truy xuất theo loại câu hỏi, lược đồ JSON thống nhất cho kết quả truy xuất nhằm đảm bảo khả năng kiểm tra, và tầm quan trọng của xử lý "không tìm thấy" đáng tin cậy trong ngữ cảnh tuân thủ quy định.

Một lập trình viên cần đọc bài này để tìm hiểu cách tối ưu hóa hệ thống RAG bằng cách áp dụng Arbiter Pattern—một giải pháp linh hoạt hơn fusion score, giúp xử lý các trường hợp phức tạp trong việc lựa chọn kết quả phù hợp từ nhiều nguồn thông tin khác nhau.

Knowledge graph RAG: structured retrieval for AI agents

GraphRAG khắc phục hạn chế của vector search khi không thể truy vết mối quan hệ giữa tài liệu, cho phép các tác nhân AI kết nối bằng chứng đa bước nhờ mô hình hóa dữ liệu dưới dạng thực thể (entities) và liên kết (edges). Redis Iris cung cấp nền tảng tích hợp tìm kiếm vector, cập nhật dữ liệu theo thời gian thực, truy cập công cụ có kiểm soát và bộ nhớ đệm ngữ nghĩa để hỗ trợ kiến trúc truy xuất này.

Lập trình viên cần đọc bài này để hiểu cách xây dựng hệ thống tìm kiếm thông minh cho AI bằng GraphRAG, giúp giải quyết vấn đề truy vấn đa cấp và cập nhật dữ liệu hiệu quả trong ứng dụng agent.

Sub-agents: splitting context across specialized AI agents

Các sub-agent là những thành phần AI chuyên biệt đảm nhiệm nhiệm vụ nhỏ trong hệ thống multi-agent, giúp khắc phục giới hạn cửa sổ ngữ cảnh (context window) của LLM nhờ phân chia khối lượng công việc. Tuy nhiên, việc chia nhỏ này cũng gây ra rủi ro sai lệch trạng thái, trùng lặp công việc hoặc lỗi tích tụ. Giải pháp đề xuất là sử dụng bộ nhớ chia sẻ kết hợp nhiều lớp (bộ nhớ phiên ngắn hạn, dài hạn bằng vector search) cùng cơ chế điều phối như pub/sub hay Streams, với Redis Iris là giải pháp thống nhất hỗ trợ đầy đủ các yêu cầu này.

Lập trình viên cần đọc để hiểu cách tối ưu hóa hệ thống AI đa agent bằng cách giải quyết vấn đề phân tán thông tin và tránh rủi ro mất hiệu suất do quản lý bộ nhớ phân tán không hiệu quả.

The new database world according to Google: Inexact queries and AI in everything

Google giới thiệu tầm nhìn tương lai về cơ sở dữ liệu với sự tích hợp AI agent và truy vấn không chính xác (inexact queries) thông qua ngôn ngữ tự nhiên, thay vì chỉ SQL truyền thống. Họ đang nhúng các chức năng AI (như AI.IF sử dụng Gemini) trực tiếp vào Google SQL trên các nền tảng Spanner, AlloyDB và BigQuery, đồng thời phát triển "proxy models" để giảm chi phí và độ trễ khi gọi LLM. Trong 3-5 năm tới, người dùng có thể chuyển từ tương tác trực tiếp sang điều phối các agent, thay thế dashboard truyền thống bằng phân tích hội thoại.

Những công nghệ mới từ Google như proxy models và AI tích hợp trực tiếp vào cơ sở dữ liệu sẽ giúp tối ưu hóa hiệu suất và chi phí khi xử lý các truy vấn phức tạp, đồng thời mở ra khả năng tương tác tự nhiên thông qua ngôn ngữ, giúp lập trình viên tìm hiểu cách ứng dụng AI vào hệ thống dữ liệu hiện đại.

10 Years of MongoDB Atlas: Built for What’s Next

MongoDB Atlas celebrates its 10th anniversary, tracing its evolution from a managed cloud database launched in 2016 to an AI-ready data platform. Key milestones include multi-cloud cluster support across AWS, Azure, and Google Cloud, ACID transactions, Atlas Search, Vector Search, and the acquisition of Voyage AI for improved embedding and reranking. Today Atlas serves over 250,000 new builders monthly, processes more than three trillion queries per day, and hosts over 726,000 vector indexes across nearly 70,000 customers. The post highlights how Atlas is now positioned as the data layer for agentic AI applications, enabling semantic search, RAG, and real-time context retrieval without requiring separate infrastructure.

NVIDIA and AWS Collaborate to Bring AI to Production at Scale

NVIDIA and AWS have announced several joint infrastructure advancements for enterprise AI at scale. New Amazon EC2 G7 instances powered by NVIDIA RTX PRO 4500 Blackwell Server Edition GPUs deliver up to 4.6x AI inference performance and 2.1x graphics performance over G6 instances, with support for up to 8 GPUs and 700 Gbps networking. Amazon OpenSearch Serverless now uses NVIDIA cuVS for GPU-accelerated vector indexing by default, enabling up to 10x faster vector indexing at a quarter of the CPU-only cost, making billion-scale vector databases buildable in under an hour. Additionally, AWS has achieved NVIDIA Exemplar Cloud status for GB300 training workloads, certifying that AWS meets NVIDIA's rigorous performance benchmarks for large-scale AI training.

Why Agent Memory Should Store Facts, Not Conversations

AtomMem, a paper from USTC, argues that LLM agent memory systems fail because they store at the wrong granularity — conversation turns instead of atomic facts. By decomposing turns into the smallest self-contained statements, organizing them in a hierarchy, and connecting them via an associative graph, the system achieves state-of-the-art on the LoCoMo benchmark with a 61.4% reduction in API token consumption. The core design principle: memory granularity should match query granularity, not input granularity. The post also honestly addresses open questions around extraction reliability (LLMs in the write path can hallucinate durable falsehoods) and graph coherence at very long horizons, and offers practical guidance on when the approach is and isn't a net win.