Ghi chú kỹ thuật Naly: Soạn thảo bài RAG ưu tiên nguồn cho xuất bản bền vững, có thể kiểm toán

TÓM TẮTTrình tạo tăng cường truy xuất (RAG) biến quy trình pipeline bài viết của Naly thành hệ thống xuất bản dựa trên nguồn thay vì viết từ trí nhớ mô hình. Mỗi yêu cầu bản nháp trước hết thu thập bằng chứng web và arXiv, chuẩn hóa và lưu trữ các sự kiện nguồn, sau đó yêu cầu mô hình tạo bản nháp theo hướng trả lời trước và bài viết HTML cuối cùng. Điều này chuyển trọng tâm rủi ro từ “mô hình có hallucinate không?” sang “lớp truy xuất có đầy đủ và truy xuất được không,” giúp biên tập viên có artefact ổn định, công việc có thể phát lại, và tuyên bố công khai có thể bảo vệ.

Tóm tắt

RAG trong Naly nên được thiết kế xoay quanh độ bền nguồn và các hợp đồng có tính xác định. Vào ngày 27 tháng 6 năm 2026, độ tin cậy thực tế đến ít từ mô hình lớn hơn và nhiều hơn từ việc liệu artefact truy xuất có thể truy vấn được, có phiên bản hóa và được xác minh trước khi xuất bản hay không. Lưu ý này đề xuất thiết kế hai mặt phẳng: một mặt phẳng bằng chứng cho truy xuất/lưu trữ và một mặt phẳng sinh nội dung cho việc soạn thảo, rồi lý giải cách kiến trúc này trực tiếp nâng cao niềm tin biên tập và xử lý sự cố.

Nó nằm ở đâu trong Naly

Naly chạy cơ chế này như một phân hệ nội dung sản xuất trong stack Next.js 16.0.7 App Router (next + react), nơi việc xuất bản bài viết là một phần của các đường dẫn mã chạy chứ không phải một bước viết thủ công offline riêng biệt. Đường dẫn tác vụ bài viết là nơi mọi ràng buộc phải được áp đặt: một tác vụ chỉ được coi là “được viết” khi bản ghi nguồn đã tồn tại, cấu trúc tóm tắt hợp lệ, và HTML đã được vật liệu hóa.

Việc căn chỉnh stack này có chủ đích:

next@16.0.7 + React Server Components chạy phần render kích hoạt bởi tác vụ trong không gian server, phù hợp với hợp đồng đầu ra phía server cho bài viết.
drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 định nghĩa các bảng tác vụ và nguồn có kiểu dữ liệu, có tính bền vững để mọi tuyên bố đều có thể truy vết.
ai@6.0.0-beta.105 cung cấp cho khâu tạo lập kiểm soát đầu ra nhận biết schema.
marked@17.0.1 chuyển đổi các bản tóm tắt Markdown đã tạo thành HTML đã render để xuất bản.
@vercel/blob@2.0.0 lưu trữ các asset đã tạo dưới dạng URL bền vững để tái sử dụng.
Công cụ Anthropic có thể được thêm vào như nhà cung cấp mô hình thay thế trong cùng một vỏ hợp đồng, nhưng không phải là lối thoát khỏi các ràng buộc có cấu trúc.

Điều này thay thế mô hình “generate rồi proofread” bằng một vòng lặp viết có căn cứ: truy xuất, xác thực, tạo nội dung, render và xuất bản đều phải vượt qua trước khi bài viết hiển thị.

Cơ chế kỹ thuật

Một thiết kế Naly vững chắc có năm giai đoạn ràng buộc:

Kế hoạch bằng chứng và điều phối truy vấn

Định nghĩa đặc tả tác vụ với chủ đề, khung thời gian và chính sách bằng chứng.
Chạy cả tìm kiếm web lẫn tìm kiếm arXiv để lấy nguồn gốc chính.
Loại bỏ trùng lặp theo URL chuẩn hóa và chuẩn hóa giao thức, host, chuỗi truy vấn.

Lớp bền vững nguồn

Lưu trữ siêu dữ liệu theo từng URL (url, URL đã chuẩn hóa, trạng thái fetch, thời điểm fetch, tiêu đề, trích đoạn, loại nguồn).
Lưu các đoạn trích dành cho mô hình riêng biệt với payload thô để các lần chạy lại có tính xác định ngay cả khi trang nguồn bên ngoài dịch chuyển.
Thêm checksum cho từng nguồn để phát hiện độ trôi dữ liệu.

Hình thành ngữ cảnh và ràng buộc

Xây dựng ngữ cảnh truy xuất theo mức độ liên quan và tính mới.
Yêu cầu ID nguồn rõ ràng trong hợp đồng prompt.
Buộc cấu trúc đầu ra kiểu answer-first (intro claim, evidence bullets, risk caveats, uncertainty), cùng với tham chiếu nguồn có thứ tự.

Sinh có cấu trúc với schema chặt chẽ

Sử dụng output có cấu trúc để phản hồi sai định dạng hoặc vi phạm schema bị lỗi nhanh và được thử lại với ngữ cảnh chặt hơn.
Giữ khâu sinh ở ngữ cảnh server và từ chối bản nháp khi đưa ra thông tin không có bằng chứng nguồn ánh xạ.

Render, xuất bản và xác minh

Chuyển đổi Markdown đã xác thực sang HTML và lưu trữ cả markdown + HTML.
Chỉ lưu cache đầu ra cuối cùng sau khi xác thực thành công.
Phát sinh các trường phân tích và kiểm toán: số lượng nguồn, số tuyên bố bị từ chối, số lần retry, và độ trễ sinh.

Di chuyển thiết kế quan trọng nhất là phân tách nhiệm vụ: chất lượng truy xuất và chất lượng sinh là hai miền lỗi khác nhau với các chỉ số khác nhau. Next.js Server Components phù hợp với sự tách này vì rendering có thể giữ tính xác định trong khi truy xuất và sinh diễn ra trong các tác vụ bất đồng bộ có kiểm soát.

Những gì tài liệu học thuật chỉ ra

Nghiên cứu RAG gần đây ủng hộ mẫu kiến trúc này. Một tổng quan năm 2024 về kiến trúc RAG mô tả cách các hệ thống tăng cường truy xuất giảm trôi sự thật bằng cách điều kiện hóa quá trình sinh trên bằng chứng bên ngoài, nhưng cũng nêu các đánh đổi về độ phức tạp pipeline và phối hợp mô-đun [Gupta et al., 2024]. Một khảo sát tiếp theo năm 2025 bổ sung rằng độ bền hiện nay phụ thuộc vào truy xuất thích ứng, kiểm soát giải mã và đánh giá đầu-cuối, thay vì chỉ dựa vào chất lượng sinh [Sharma, 2025].

Đối với kiểm soát chất lượng sản xuất, khảo sát tập trung vào đánh giá năm 2025 tách rõ đánh giá nội bộ của retriever/generator và chỉ số hệ thống bên ngoài; sự phân rã này đặc biệt hữu ích cho pipeline bài viết vì “bài xấu” có thể là chọn sai nguồn ngay cả khi chất lượng ngôn ngữ tốt [Gan et al., 2025]. Các công trình tập trung vào groundedness cũng chuyển sang lớp phát hiện phân loại độ hỗ trợ của tuyên bố bằng ngữ cảnh truy xuất và kiểm tra theo kiểu NLI, củng cố giá trị thực tiễn của xác thực sau khi sinh [Gerner et al., 2025].

Tóm lại, các bài báo hội tụ ở một luận điểm: RAG không chỉ là cách bơm ngữ cảnh, mà là một hợp đồng kỹ thuật giữa truy xuất và sinh. Vì vậy Naly nên tối ưu hóa hợp đồng này, không chỉ tối ưu prompt.

Đánh đổi thiết kế

Độ mới so với tính xác định: TTL chặt chẽ hơn làm giảm độ lỗi thời nhưng tăng chi phí fetch lại. Việc lưu trữ snapshot giúp bạn giữ rendering xác định trong khi vẫn có thể revalidate các cửa sổ mới.
Recall so với precision trong truy xuất: truy xuất rộng có thể tăng độ bao phủ nhưng gây nhiễu; bộ lọc relevance hai giai đoạn bảo vệ chất lượng tuyên bố.
Độ chặt của schema so với độ trôi chảy văn phong: schema đầu ra chặt chẽ nâng độ tin cậy máy, nhưng có thể giảm tính tự do phong cách. Mô hình answer-first vẫn giữ được tính dễ đọc trong khi giữ guardrails.
Tốc độ render tĩnh so với khả năng kiểm toán: HTML được pre-render giúp cải thiện hiệu năng delivery và giảm tính toán lặp lại, nhưng chỉ khi artefact nguồn dùng là tham chiếu bất biến.
Độ phức tạp so với chi phí vận hành: mỗi bước xác thực bổ sung (kiểm tra nguồn, kiểm tra schema, lưu trữ artefact) đều làm tăng độ trễ. Hướng dẫn production mới nhất về caching, ranh giới route, và verification tại thời điểm build rất quan trọng để duy trì khả năng vận hành.

Các chế độ lỗi

Trôi nguồn: URL trả về 404/thay đổi mềm sau khi tạo tác vụ. Giảm thiểu: khóa chuẩn hóa + hash snapshot + chuỗi nguồn dự phòng.
Truy xuất quá rộng: recall cao nhưng precision thấp gây ra tổng hợp có vẻ hợp lý nhưng không được hỗ trợ. Giảm thiểu: yêu cầu ràng buộc evidence-first và chặn tuyên bố không khớp nguồn.
Lỗi định dạng mô hình: sai schema hoặc JSON bị cắt ngắn khi sinh. Giảm thiểu: xác thực schema nghiêm ngặt và thử lại với ngữ cảnh giảm.
Đua xuất bản kép: các worker song song có thể xuất bản artefact chưa hoàn chỉnh. Giảm thiểu: khóa idempotency của tác vụ, chuyển trạng thái ở mức hàng (pending -> drafting -> validated -> published).
Suy giảm rendering: markdown sai định dạng hoặc biến đổi HTML không an toàn. Giảm thiểu: đường dẫn chuyển đổi marked định trước và các test đầu ra HTML gắn với manifest mẫu.
Ảo tưởng cachedữ liệu động lỗi thời trong server output có thể làm lệch văn bản đã xuất bản với chỉ mục nguồn. Giảm thiểu: căn chỉnh chiến lược render route với chính sách freshness runtime rõ ràng và tránh cache ngầm khi cần freshness của bằng chứng.

Ghi chú triển khai

Trong triển khai thực tế, hãy coi đây là một hợp đồng xuất bản:

Định nghĩa các bảng nguồn trong Drizzle với các ràng buộc rõ ràng: tính duy nhất của URL theo host/path đã chuẩn hóa, enum trạng thái fetch, và các cột checksum.
Sử dụng đường dẫn driver tương thích Neon một cách nhất quán với hành vi thực thi serverless; tài liệu Drizzle mô tả cả runtime-specific và neon-* các tùy chọn driver.
Trong giai đoạn sinh, áp đặt các hợp đồng đầu ra có cấu trúc và thất bại ngay khi đối tượng không hợp lệ trước khi render.
Áp dụng hướng dẫn production của Next.js cho server boundaries, trang lỗi, caching và metadata SEO cho các route bài viết để việc xuất bản luôn có thể quan sát và nhanh.
Lưu trữ các blob đã sinh (ví dụ: ảnh bìa, tệp đính kèm, export) qua Vercel Blob với chính sách truy cập rõ ràng và đặt tên có tính xác định để tránh xung đột.
Phát sinh kiểm tra vận hành trước khi xuất bản: tối thiểu số nguồn, tối thiểu tính đa dạng nguồn, độ mới của bằng chứng, và tỷ lệ hoàn thành tối thiểu cho các tuyên bố đã ánh xạ.

Đây là sự chuyển đổi cốt lõi: bài viết không còn được chấm điểm bởi sự lanh lợi của mô hình; nó được chấm bởi việc liệu bằng chứng và sinh có đồng bộ với nhau khi retry và redeploy hay không.