Blog

Retrieval-augmented generation for source-backed article writing

Ghi chú kỹ thuật Naly: Viết bài tăng cường truy xuất với nguồn được lưu bền vững

Sinh tăng cường truy xuất biến việc viết bài của Naly thành một quy trình nghiên cứu có thể kiểm toán thay vì chỉ tạo văn xuôi dựa trên bộ nhớ. Lựa chọn thiết kế quan trọng không chỉ là truy xuất, mà còn là lưu giữ nguồn, kỷ luật trong tuyên bố, và kết xuất an toàn.

May 14, 20269 sources

Tóm tắt

Sinh tăng cường truy xuất mang lại cho pipeline bài viết của Naly một bộ nhớ nghiên cứu mới hơn và dễ kiểm toán hơn so với chỉ dựa vào trọng số mô hình. Với mỗi tác vụ ghi chú kỹ thuật hoặc bài tình báo thị trường, hệ thống có thể tìm kiếm web và arXiv, giữ URL nguồn cùng với hiện vật được tạo ra, yêu cầu mô hình trả lời trước, rồi kết xuất kết quả thành HTML. Mục tiêu không phải là tự động hóa vì chính nó; mục tiêu là công bố các tuyên bố mà độc giả có thể truy vết.

Luận điểm rất đơn giản: RAG cho viết bài nên được xem là một hệ thống bằng chứng sản xuất, không phải một mẫu chatbot. Một chatbot có thể được bỏ qua khi trả lời yếu; một bài đã xuất bản trở thành một bề mặt niềm tin lâu dài. Vì vậy, triển khai của Naly cần ba bất biến: truy xuất trước khi soạn thảo, bản ghi nguồn tồn tại sau khi xuất bản, và trình kết xuất giữ được Markdown dễ đọc trong khi tránh HTML không an toàn.

Nó nằm ở đâu trong Naly

Các tác vụ bài viết của Naly nằm giữa thu thập nghiên cứu và xuất bản công khai. Tác vụ bắt đầu bằng một chủ đề được chọn, tạo ý định tìm kiếm, lấy tài liệu web và arXiv, chuẩn hóa kết quả thành bản ghi nguồn, rồi yêu cầu mô hình viết một bài bắt đầu bằng câu trả lời từ tập bằng chứng có giới hạn đó. Đầu ra không chỉ là văn xuôi. Nó là một gói: nội dung Markdown, HTML đã kết xuất, URL nguồn, tiêu đề nguồn, loại nguồn, và đủ metadata để giải thích vì sao từng nguồn được dùng.

Điều này quan trọng với vòng lặp niềm tin của Naly. Lập trường biên tập rộng hơn của Naly là công bố những gì người khác che giấu: memo quyết định, giới hạn hiệu chuẩn, thất bại, và bằng chứng phía sau các tuyên bố. Sinh có nguồn hậu thuẫn biến lập trường đó thành vận hành. Độc giả không nên phải đoán liệu một câu phát biểu đến từ dữ liệu huấn luyện của mô hình, tài liệu chính thức, một bài báo khoa học, hay khẳng định của operator.

Lớp RAG thuộc về giai đoạn trước soạn thảo, không phải sau đó. Gắn trích dẫn hậu kiểm yếu hơn vì mô hình đã hình thành các tuyên bố. Trong một thiết kế mạnh hơn, truy xuất ràng buộc ngữ cảnh sinh, và quá trình sinh tạo ra các tuyên bố có thể được kiểm tra với tập đã truy xuất. Bài viết hiển thị có thể vẫn súc tích, nhưng hiện vật được lưu nên giữ lại dấu vết nghiên cứu.

Cơ chế kỹ thuật

Đối với viết bài, luồng RAG của Naly là một pipeline batch:

  1. Chọn chủ đề tạo ra một câu hỏi nghiên cứu có giới hạn, chẳng hạn như cách sinh tăng cường truy xuất đặt nền bằng chứng cho việc viết bài có nguồn hậu thuẫn.
  2. Lập kế hoạch truy vấn mở rộng câu hỏi đó thành các truy vấn web, truy vấn tài liệu chính thức, và truy vấn arXiv.
  3. Truy xuất thu thập tài liệu chính thức, các bài báo chính yếu, và những nguồn giải thích có tín hiệu cao.
  4. Chuẩn hóa trích xuất tiêu đề, URL chính tắc, loại nguồn, bối cảnh xuất bản hoặc cập nhật khi có, và các đoạn trích hoặc tóm tắt liên quan.
  5. Lưu giữ nguồn lưu sổ cái URL trước khi sinh để bài viết có thể được kiểm toán về sau.
  6. Lắp ráp prompt cung cấp cho mô hình chủ đề, các sự kiện triển khai riêng của Naly, ràng buộc viết, và bằng chứng đã truy xuất.
  7. Sinh tạo Markdown với phần tóm tắt bắt đầu bằng câu trả lời, các chế độ lỗi rõ ràng, và phần tài liệu tham khảo.
  8. Xác thực kiểm tra rằng mọi tài liệu tham khảo trong bài đã kết xuất đều ánh xạ tới một đối tượng nguồn đã lưu.
  9. Kết xuất chuyển Markdown thành HTML cho trang web trong khi áp dụng làm sạch và các kiểm tra sản xuất.

Điều này gần với mẫu truy xuất và sinh tăng cường được mô tả trong hướng dẫn RAG của Vercel: truy xuất ngữ cảnh liên quan trước, rồi kết hợp nó với câu hỏi của người dùng hoặc tác vụ trước khi sinh. Khác biệt là Naly không tối ưu cho hỗ trợ hội thoại. Naly tối ưu cho xuất bản bền vững, nơi URL nguồn là một phần của mô hình dữ liệu bài viết.

AI SDK là một lớp điều phối tự nhiên cho loại tác vụ này vì giao diện sinh văn bản của nó hỗ trợ tự động hóa không tương tác, gọi công cụ, kết quả nhiều bước, và metadata nguồn khi nhà cung cấp trả về nguồn URL. Ngay cả khi nhà cung cấp không trả về đối tượng nguồn gốc, Naly vẫn có thể gắn danh sách nguồn đã truy xuất của riêng mình vào hiện vật bài viết và xem nguồn gốc từ mô hình là bổ sung thay vì có thẩm quyền.

Tài liệu nghiên cứu nói gì

Công thức RAG ban đầu của Lewis et al. đã đóng khung tốt vấn đề cốt lõi: các mô hình ngôn ngữ tham số lưu dữ kiện trong trọng số, nhưng việc cập nhật tri thức đó và cung cấp xuất xứ vẫn khó. Mô hình tăng cường truy xuất của họ kết hợp một mô hình chuỗi với chỉ mục vector dày đặc và cho thấy khả năng sinh cụ thể hơn, đa dạng hơn, và đúng thực tế hơn so với baseline chỉ dùng tham số trên các tác vụ đòi hỏi nhiều tri thức.

Khảo sát RAG sau đó của Gao et al. khái quát ý tưởng này thành một phân loại: RAG ngây thơ, RAG nâng cao, và RAG mô-đun. Pipeline bài viết của Naly nên là mô-đun. Truy xuất, xếp hạng, lưu giữ nguồn, xây dựng prompt, sinh, xác thực tham chiếu, và kết xuất là các đơn vị riêng biệt với các chế độ lỗi riêng. Xem chúng là các đơn vị riêng giúp hệ thống dễ gỡ lỗi hơn khi một bài trích dẫn nguồn yếu hoặc bỏ lỡ nguồn tốt hơn.

Self-RAG bổ sung một cảnh báo quan trọng. Asai et al. lập luận rằng truy xuất một số đoạn cố định bất kể có cần truy xuất hay không có thể làm giảm chất lượng đầu ra. Với Naly, điều đó nghĩa là truy xuất top-k không nên là nghi thức. Một bài ngắn về tính năng framework ổn định có thể cần tài liệu chính thức và một bài báo; một bài nặng về tài liệu nghiên cứu có thể cần nhiều nguồn arXiv và một khảo sát. Độ sâu truy xuất nên đi theo rủi ro của tuyên bố.

RAGChecker đưa ra bài học đánh giá. Ru et al. lập luận rằng các hệ thống RAG cần chẩn đoán tinh vi ở cả truy xuất và sinh, đặc biệt với phản hồi dạng dài. Với Naly, đơn vị đánh giá không nên chỉ là chất lượng bài viết. Nó nên bao gồm recall truy xuất, mức độ liên quan của nguồn, hỗ trợ cho tuyên bố, độ phủ tham chiếu, và liệu các tuyên bố không được hỗ trợ có lọt vào Markdown cuối cùng hay không.

Đánh đổi thiết kế

Recall cao so với nhiễu thấp là đánh đổi trung tâm. Truy xuất nhiều hơn cải thiện cơ hội tìm đúng nguồn, nhưng cũng tăng khả năng các đoạn trích yếu đi vào prompt và lái mô hình. Naly nên ưu tiên một cách tiếp cận theo giai đoạn: thu thập rộng, lọc nghiêm ngặt, rồi nén gọn ngữ cảnh prompt.

Lưu giữ nguồn cải thiện khả năng kiểm toán, nhưng cũng tạo thêm công việc lưu trữ và bảo trì. URL trôi dạt, bài báo được sửa đổi, và trang tài liệu di chuyển. Bản ghi bền vững nên bao gồm URL chính tắc, timestamp lấy dữ liệu, tiêu đề, loại nguồn, và lý tưởng là digest nội dung hoặc ranh giới đoạn trích. Điều đó cho phép Naly phân biệt lỗi mô hình với nguồn đã thay đổi.

Viết bắt đầu bằng câu trả lời cải thiện giá trị cho độc giả, nhưng có thể nén bất định quá mạnh. Bài viết nên mở đầu bằng kết luận trong khi vẫn giữ một phần phía sau cho các chế độ lỗi và lưu ý. Tóm tắt bắt đầu bằng câu trả lời là điểm vào; nó không phải giấy phép để làm phẳng bằng chứng.

HTML đã kết xuất cải thiện phân phối và trải nghiệm đọc, nhưng tạo ra một ranh giới bảo mật. Marked nhanh và hữu ích cho phân tích Markdown, nhưng tài liệu của nó cảnh báo rõ rằng nó không làm sạch HTML đầu ra. Trình kết xuất bài viết của Naly nên làm sạch HTML đã sinh và giữ nguồn Markdown đáng tin cậy sẵn sàng để phát lại.

Chế độ lỗi

Bỏ sót khi truy xuất: bước tìm kiếm tìm được các nguồn có vẻ hợp lý nhưng không đầy đủ. Điều này thường xảy ra khi bộ lập kế hoạch truy vấn quá hẹp hoặc dùng thuật ngữ sản phẩm khác với tài liệu nghiên cứu. Giảm thiểu: dùng nhiều kiểu truy vấn, bao gồm tài liệu chính thức, và yêu cầu ít nhất hai nguồn chính yếu hoặc arXiv khi bài viết đưa ra tuyên bố nghiên cứu.

Rửa trích dẫn: một nguồn xuất hiện trong tài liệu tham khảo, nhưng thực ra không hỗ trợ câu gần đó. Điều này tệ hơn không có trích dẫn vì nó tạo ra sự tự tin giả. Giảm thiểu: xác thực tuyên bố với các đoạn trích nguồn và từ chối các bài có tham chiếu chỉ liên quan theo chủ đề.

Trôi dạt nguồn lỗi thời: một trang tài liệu chính thức thay đổi sau khi xuất bản. Giảm thiểu: lưu giữ metadata nguồn tại thời điểm sinh và ghi nhãn ngày. Với các nguồn dẫn dắt tuyên bố lớn, lưu snapshot hoặc digest nếu giấy phép cho phép.

Truy xuất quá mức: quá nhiều chunk khiến mô hình tóm tắt ngữ cảnh thay vì trả lời luận điểm của bài viết. Giảm thiểu: dùng xếp hạng nguồn, khử trùng lặp các tài liệu gần giống nhau, và giới hạn bằng chứng trong prompt theo mức độ liên quan với tuyên bố thay vì số lượng thô.

Đầu độc ngữ cảnh: trang spam, trang SEO được tạo tự động, hoặc bản tóm tắt chất lượng thấp xếp hạng cao hơn tài liệu chính yếu. Giảm thiểu: xếp tài liệu chính thức, arXiv, tiêu chuẩn, và kho mã nguồn cao hơn bình luận thứ cấp, trừ khi bài viết rõ ràng nói về phản ứng của ngành.

Rủi ro trình kết xuất: Markdown được sinh có thể chứa HTML thô, liên kết không an toàn, hoặc bảng sai định dạng. Giảm thiểu: làm sạch HTML đã kết xuất, chuẩn hóa liên kết, từ chối nội dung có thể thực thi script, và chạy các kiểm tra sản xuất nhất quán với hướng dẫn Next.js về hiệu năng, bảo mật, metadata, và khả năng tiếp cận.

Ghi chú triển khai

Dựa trên các sự kiện runtime hiện tại của Naly, kiến trúc sạch là một tác vụ TypeScript dùng ai@6.0.0-beta.105 cho điều phối mô hình, các công cụ truy xuất web và arXiv để thu thập bằng chứng, Drizzle ORM với Neon cho bản ghi bài viết và nguồn, marked@17.0.1 cho kết xuất Markdown sang HTML, và Next.js 16 cho bề mặt xuất bản.

Cơ sở dữ liệu nên xem nguồn là các hàng hạng nhất, không phải một blob văn bản Markdown. Một schema thực dụng có bảng bài viết, bảng nối article-source, và các trường nguồn cho URL, tiêu đề, loại nguồn, timestamp truy xuất, định danh chính tắc như arXiv ID khi có, và trạng thái trích xuất. Bản ghi bài viết sau đó có thể trỏ tới Markdown, HTML đã kết xuất, tóm tắt, các điểm chính, và metadata xuất bản.

Vercel Blob hữu ích cho các hiện vật lớn hơn hoặc đầu ra kết xuất bất biến, trong khi Postgres vẫn tốt hơn như sổ cái có thể truy vấn cho nguồn và metadata bài viết. Sự tách biệt đó giữ cho truy vấn kiểm toán rẻ: liệt kê mọi bài viết đã dùng một nguồn, mọi nguồn được một bài viết dùng, và mọi bài viết có trích xuất nguồn thất bại.

Prompt của trình sinh nên yêu cầu kỷ luật nguồn ngay trong cấu trúc đầu ra: không có tuyên bố không được hỗ trợ, không có URL bịa, và phần tài liệu tham khảo với liên kết phải khớp danh sách nguồn đã lưu. Mô hình có thể viết văn xuôi trôi chảy, nhưng tác vụ phải sở hữu sự thật về nguồn. Nếu mô hình phát ra một tham chiếu chưa được truy xuất, bộ xác thực nên đánh fail bài viết thay vì âm thầm xuất bản nó.

Cuối cùng, hành vi sản xuất rất quan trọng. Next.js đã cung cấp server components, code splitting, prerendering, và các mặc định caching, nhưng pipeline nội dung được tạo vẫn cần xử lý lỗi rõ ràng, kiểm tra bảo mật, metadata, và ý thức về Core Web Vitals. RAG giúp Naly viết bằng bằng chứng. Kỹ thuật sản xuất bảo đảm bằng chứng đó đến với độc giả nhanh chóng, an toàn, và lặp lại được.

Tài liệu tham khảo

Sources