LLM chỉ có thể “đọc” một lượng văn bản giới hạn trong mỗi lần xử lý (cửa sổ ngữ cảnh). Cách này phù hợp với các tác vụ nhỏ, nhưng không còn hiệu quả khi cơ sở tri thức trải dài hàng nghìn trang. Ngay cả khi cửa sổ ngữ cảnh đủ lớn, hiệu suất vẫn có thể suy giảm do bài toán “mò kim đáy bể”.
RAG (“sinh tăng cường bằng truy xuất”) đã trở thành một mô hình triển khai rất phổ biến: bạn duy trì một cơ sở tri thức (tài liệu, wiki, chính sách, bản chép lời, v.v.), dùng embedding để tìm kiếm ngữ nghĩa theo truy vấn của người dùng nhằm truy xuất những đoạn liên quan nhất, rồi đưa các đoạn đó cùng câu hỏi vào LLM. Cách này giới hạn ngữ cảnh của mô hình và nếu được thực hiện đúng, có thể nâng cao chất lượng câu trả lời cũng như giảm hiện tượng ảo giác.
pgai là một tiện ích mở rộng Postgres mã nguồn mở (cùng bộ công cụ đi kèm), giúp bạn xây dựng quy trình “truy xuất bằng AI” trên PostgreSQL, cơ sở dữ liệu mã nguồn mở đáng tin cậy.
Ý tưởng chính là đưa nhiều công đoạn hơn của quy trình RAG tiêu chuẩn xuống lớp cơ sở dữ liệu (nạp → chia đoạn → tạo embedding → duy trì đồng bộ embedding), thay vì coi cơ sở dữ liệu là “nơi chỉ để lưu” embedding.
Đánh giá ban đầu cho thấy dự án này đầy hứa hẹn, nhưng sẽ không phù hợp khi quy trình RAG của bạn bắt đầu phức tạp, dù chỉ ở mức vừa phải (đặc biệt là về phương pháp chia đoạn). Dù vậy, chúng tôi sẽ tiếp tục theo dõi sát dự án này.
Có rất nhiều cách xây dựng RAG. Để tìm hiểu sâu hơn về từng phương pháp, hãy đọc Các ví dụ thực tế về giải pháp RAG tùy chỉnh. Khi chú trọng đến chất lượng, không gian thiết kế trở nên sâu rộng đáng ngạc nhiên; phương pháp “mặc định” phổ biến thường như sau:
Tập hợp một loạt tài liệu.
Chia chúng thành các đoạn. Có nhiều phương pháp để thực hiện việc này (ví dụ: chia theo đoạn văn hoặc nhóm ngữ nghĩa).
Chuyển từng đoạn thành một embedding.
Lưu embedding trong cơ sở dữ liệu vectơ (Pinecone, Milvus, v.v.) hoặc trong Postgres bằng pgvector.
Khi nhận truy vấn, hãy tìm các đoạn gần nhất `và đưa chúng vào LLM (xin nhắc lại... cũng có nhiều cách thực hiện bước này).
Trong nhiều ngăn xếp công nghệ, các bước (1)–(3) diễn ra bên ngoài cơ sở dữ liệu, trong mã ứng dụng hoặc quy trình dữ liệu; cơ sở dữ liệu chủ yếu được dùng để:
lưu trữ embedding
tìm kiếm embedding
pgai là một tiện ích mở rộng Postgres mã nguồn mở do Timescale phát triển, nhằm xóa nhòa ranh giới đó.
Thay vì coi embedding là thứ ứng dụng phải quản lý thủ công, pgai biến embedding thành một tính năng của cơ sở dữ liệu:
Bạn xác định bảng/tài liệu cần tạo embedding.
Bạn chỉ định mô hình embedding và chiến lược chia đoạn.
pgai quản lý phần còn lại, bao gồm việc cập nhật embedding khi dữ liệu nguồn thay đổi.
Lợi ích hứa hẹn rất hấp dẫn:
Ít mã kết nối chuyên biệt cần bảo trì hơn.
Dễ giữ cho embedding luôn “mới” khi tài liệu nguồn bên dưới thay đổi.
Postgres/pgai quản lý việc thử lại, giới hạn tốc độ, tác vụ thất bại, v.v.
Lưu ý cho độc giả: pgai tích hợp sẵn pgvector (một tiện ích mở rộng Postgres rất phổ biến khác dành cho RAG). pgvector bổ sung khả năng lưu trữ vectơ và tìm kiếm tương đồng cho Postgres, còn pgai dựa trên nền tảng đó để tự động hóa các bước trong quy trình RAG như chia đoạn, tạo embedding và duy trì cập nhật các embedding này.
1) Dễ dàng thiết lập và vận hành.
Quy trình thuận lợi khá đơn giản:
Tải các Docker image của Timescale (cơ sở dữ liệu + worker).
Cung cấp khóa API của nhà cung cấp embedding.
Chạy một ít mã SQL để khai báo vectoriser (về cơ bản là: nội dung cần tạo embedding, cách chia đoạn và mô hình cần dùng).
Sau đó, pgai sắp xếp để một worker vectoriser chạy dưới dạng tiến trình riêng và tạo embedding bất đồng bộ (ví dụ: 5 phút một lần hoặc theo bất kỳ tần suất nào bạn muốn).
2) Thật tiện khi toàn bộ quy trình được thực hiện “gần” cơ sở dữ liệu.
pgai có thể nạp nội dung từ các bảng hoặc tải tài liệu từ những nơi như S3, sau đó phân tích cú pháp, chia đoạn và tạo embedding. Công cụ này cũng có thể xử lý nhiều định dạng tài liệu văn bản như PDF, Markdown, v.v.
1) Bạn mất nhiều quyền kiểm soát (trong khi RAG đôi lúc cần điều đó).
Các hệ thống RAG hiệu suất cao (xét theo chất lượng câu trả lời) thường cần quy trình chuyên biệt, chẳng hạn như:
quy tắc chia đoạn tùy chỉnh (theo tiêu đề, trang, lượt phát biểu, v.v.)
chia đoạn có xét siêu dữ liệu (giữ lại tiêu đề phần, dấu thời gian, tác giả, loại tài liệu)
chiến lược embedding khác nhau cho từng loại tài liệu
pgai kém linh hoạt hơn đối với các yêu cầu trên.
Hiện có hai chiến lược chia đoạn chính: bộ chia văn bản theo ký tự và bộ chia văn bản đệ quy theo ký tự, cùng một tùy chọn không chia đoạn. Như vậy có thể đủ cho một số trường hợp sử dụng, nhưng nhiều hệ thống RAG trong môi trường production cần khả năng tùy chỉnh cao hơn.
Sẽ rất tuyệt nếu Timescale có thể tích hợp một số chiến lược chia đoạn tinh vi hơn như trong các thư viện chẳng hạn Chonkie, đồng thời hỗ trợ những thiết kế nâng cao như truy xuất theo ngữ cảnh của Anthropic.
2) Ưu tiên văn bản, chưa phải đa phương thức.
Nhiều bài toán RAG thú vị không còn thuần túy xoay quanh văn bản:
Tệp PDF có sơ đồ
ảnh chụp màn hình/hình ảnh
bản ghi âm
đoạn video
Ngay cả khi có thể “trích xuất văn bản” từ những nguồn này, đó vẫn không phải là một quy trình embedding đa phương thức thực thụ.
Nếu sau này pgai hỗ trợ trọn quy trình cho các mô hình đa phương thức (nạp → chia đoạn → tạo embedding cho hình ảnh lớn, âm thanh và video lưu trên S3, với khả năng đồng bộ đáng tin cậy), điều đó sẽ rất hấp dẫn; nhưng hiện tại, đây vẫn là quy trình embedding văn bản.
3) Nếu chỉ cần embedding, có thể bạn không cần pgai.
Nếu quy trình nạp dữ liệu của bạn đã được tùy chỉnh (hoặc cần phải như vậy), thì “tạo embedding cho các đoạn văn bản” không phải phần khó nhất của RAG. Trong trường hợp đó, pgai chỉ đang giải quyết phần dễ nhất của bài toán.
Ngoài ra, nếu cơ sở tri thức hiếm khi được cập nhật, tính năng tự động đồng bộ embedding sẽ không mang lại nhiều giá trị.
Một cách đặc biệt hiệu quả để dùng pgai là triển khai giao diện text-to-SQL trên các cơ sở dữ liệu của bạn. Bạn có thể thực hiện việc này khá dễ dàng bằng mô-đun semantic_catalog do pgai cung cấp. Chỉ cần thiết lập như sau:
Bash
rồi dùng semantic catalog thu thập từ điển dữ liệu bằng lệnh pgai semantic-catalog create. Thao tác này tạo ngữ cảnh từ kho dữ liệu của bạn, trông gần giống như sau:
Plain Text
Giờ đây, pgai có thể sử dụng ngữ cảnh này theo nhiều cách:
Thông qua tìm kiếm ngữ nghĩa:
Truy vấn này sẽ trả về các bảng, hàm và đối tượng khác có thể liên quan đến truy vấn bằng ngôn ngữ tự nhiên của bạn:
Bash
Lấy ngữ cảnh thô:
Thao tác này sẽ kết xuất ngữ cảnh YAML thô liên quan đến truy vấn bằng ngôn ngữ tự nhiên của bạn:
Bash
Tạo SQL:
Hoặc bạn có thể trực tiếp tạo mã SQL thô cần thiết để trả lời truy vấn. Ngữ cảnh từ bước trước được gửi đến một LLM để tạo câu trả lời:
Bash
Nếu đang xây dựng một hệ thống RAG tương đối đơn giản, pgai đáng để thử nếu bạn muốn:
dùng Postgres làm hệ thống dữ liệu chuẩn,
tối thiểu hóa mã kết nối,
embedding tự động duy trì đồng bộ,
một cách nhanh chóng để áp dụng text-to-SQL cho cơ sở dữ liệu,
thử nghiệm các công cụ RAG và tiện ích mở rộng Postgres mới.
Có lẽ bạn nên chờ thêm trước khi dùng pgai nếu quy trình RAG cần bất kỳ yếu tố nào sau đây:
logic nạp dữ liệu hoặc chia đoạn được tùy chỉnh sâu
nhiều loại tài liệu với yêu cầu phân tích cú pháp khác nhau
embedding đa phương thức
Cuối cùng, dù rõ ràng pgvector đã được ứng dụng rộng rãi, vẫn chưa biết pgai có thu hút được mức độ quan tâm tương tự và nhờ đó nhận được sự hỗ trợ tương xứng hay không (dù công cụ này mới chỉ xuất hiện khoảng 18 tháng).
pgai là một cách tiếp cận RAG thú vị, cho phép cơ sở dữ liệu đảm nhận nhiều công việc vận hành thường nhật hơn để mã ứng dụng trở nên đơn giản hơn.
Hiện tại, công cụ này:
dùng được và thực sự thuận tiện cho các hệ thống RAG đơn giản
chưa đủ linh hoạt cho các quy trình chuyên biệt hơn (đặc biệt là đa phương thức)
Công cụ này rất hứa hẹn và chắc chắn đáng để theo dõi trong quá trình phát triển.