Chỉnh sửa nội dung một phần an toàn bởi các LLM agent

Đây là một vấn đề cụ thể nằm trong phạm vi rộng hơn về các vấn đề kiến trúc của các LLM agent hiện đại.

Vấn đề

Theo phương pháp CRUD thông thường, một trường văn bản lớn như content được cập nhật toàn bộ. Đối với một client tất định cổ điển, điều này thường có thể chấp nhận được. Đối với một LLM agent, mô hình như vậy rủi ro hơn: nếu nhiệm vụ là thay đổi một dòng, liên kết, đoạn văn hoặc phần duy nhất, agent vẫn buộc phải lấy tài liệu, tái tạo lại toàn bộ và gửi phiên bản đầy đủ mới.

Do đó, một chỉnh sửa nhỏ lại nhận về phạm vi tác động quá lớn. Các token và thao tác thừa xuất sinh, đi kèm với rủi ro vô tình làm thay đổi văn bản lân cận, mất một phần tài liệu, ghi đè phiên bản mới hơn hoặc thực hiện các thay đổi chưa lên kế hoạch.

Vấn đề này đã xuất hiện trên thực tế khi làm việc với Concepts fi1osof.ru: để sửa một liên kết nội bộ duy nhất, agent đã phải gửi lại toàn bộ content. Đối với một hệ thống nơi các AI agent phải thường xuyên tạo và duy trì các bài viết lớn, Concepts, các tác vụ và nội dung khác, phương thức chỉnh sửa này khó có khả năng mở rộng tốt.

Những gì đã có sẵn trong thực tiễn kỹ thuật

Ý tưởng sửa đổi một phần tài nguyên đã xuất hiện từ lâu trước LLM. RFC 5789 — PATCH Method for HTTP giới thiệu PATCH chính xác bởi vì PUT ngụ ý thay thế hoàn toàn biểu diễn của tài nguyên, trong khi nhiều ứng dụng chỉ cần thay đổi một phần của nó.

Đối với dữ liệu JSON có cấu trúc, RFC 6902 — JSON Patch mô tả chuỗi các thao tác add, remove, replace, move, copy, test. Đây là một tiền lệ quan trọng: client không truyền toàn bộ trạng thái mới, mà truyền một tập hợp các thay đổi đối với trạng thái hiện có.

Các coding agent hiện đại sử dụng một cách tiếp cận tương tự dành riêng cho LLM. Công cụ OpenAI Apply Patch cho phép mô hình sửa đổi các tệp thông qua các thao tác diff có cấu trúc thay vì trả về toàn bộ nội dung tệp. Coding agent GitHub Copilot cũng xây dựng quy trình làm việc xung quanh các thay đổi trong một nhánh riêng biệt và kiểm tra phần diff kết quả: tài liệu chính thức của GitHub.

Ở cấp độ tool-protocol, Model Context Protocol coi các công cụ là các thao tác tác động lên hệ thống bên ngoài: MCP Tools specification. Trong sự phát triển của MCP, từ vựng rủi ro của công cụ được chính thức hóa riêng biệt — readOnly, destructive, idempotent và các đặc điểm khác: Tool Annotations as Risk Vocabulary. Điều này không giải quyết trực tiếp bài toán chỉnh sửa một phần, nhưng xác nhận sự chuyển dịch chung từ "mô hình có một hàm" sang một mô tả chặt chẽ hơn về hậu quả của thao tác.

Đồng thời, hiện chưa có tiêu chuẩn chung nào được chấp nhận rộng rãi cho việc chỉnh sửa an toàn các tài liệu CMS/MDX tùy ý bởi các LLM agent. Các cơ chế patch của coding agent giải quyết bài toán gần gũi cho các tệp, và HTTP/JSON Patch cho các API cổ điển, nhưng việc chỉnh sửa nội dung nguyên bản của agent (agent-native content editing) vẫn là một vấn đề kỹ thuật riêng biệt.

Yêu cầu đối với giải pháp tương lai

Đối với haih-agent, cần có một cơ chế trong đó agent có thể sửa đổi phần tối thiểu cần thiết của tài liệu và không bắt buộc phải tạo lại toàn bộ content.

Các thuộc tính mong muốn:

• thay đổi phải mang tính cục bộ và có giới hạn;
• máy chủ phải xác minh rằng agent đang chỉnh sửa phiên bản tài liệu mà nó đã nhìn thấy;
• thao tác mơ hồ không được phép áp dụng một cách âm thầm;
• nhiều thay đổi lý tưởng nên được áp dụng một cách nguyên tử (atomically);
• sau khi sửa đổi, tài liệu phải trải qua quá trình xác thực lại MDX/Markdown;
• việc thay thế hoàn toàn content phải tiếp tục khả dụng cho các trường hợp thực sự cần viết lại toàn bộ tài liệu;
• cơ chế này phải phù hợp không chỉ cho Concepts, mà còn cho Tasks, Projects và các thực thể khác có các trường văn bản lớn.

Phương án 1. Chỉnh sửa một phần thông qua text matching

Phương án có ngữ cảnh tối ưu nhất là agent đọc Markdown/MDX thông thường và gửi các lệnh chứa đoạn mã nguồn dự kiến cùng bản thay thế của nó.

Về mặt khái niệm:

replace:
  match: "đoạn hiện có chính xác"
  with: "Markdown/MDX mới"
  expectedMatches: 1

Cơ chế có thể hỗ trợ một số thao tác phổ biến: thay thế, xóa, chèn trước hoặc sau đoạn tìm thấy. Đây không phải là các phương thức riêng biệt cho các liên kết, từ ngữ hay câu, mà là một ngôn ngữ chung về các thay đổi văn bản cục bộ.

Ưu điểm

• mức tăng ngữ cảnh tối thiểu: agent tiếp tục đọc MDX nguồn nhỏ gọn;
• dễ giải thích cho mô hình và con người;
• phù hợp cho các thay đổi cục bộ nhỏ và trung bình;
• máy chủ có thể từ chối thao tác một cách an toàn nếu không tìm thấy match hoặc tìm thấy một cách mơ hồ;
• độ phức tạp tương đối nhỏ cho lần triển khai đầu tiên.

Nhược điểm

• exact matching rất nhạy cảm với các thay đổi văn bản đã xảy ra trước đó;
• đôi khi agent phải truyền một đoạn ngữ cảnh duy nhất khá lớn;
• các thao tác cấu trúc như "thêm một mục cụ thể vào danh sách này" được thể hiện ít tự nhiên hơn;
• text matching hiểu ít hơn về ngữ nghĩa của tài liệu MDX.

Phương án 2. Đọc và định địa chỉ thông qua MDX AST

MDX đã có biểu diễn cấu trúc thông qua hệ sinh thái unified/remark. remark-mdx cho phép phân tích cú pháp MDX thành một cây cú pháp (syntax tree). Định dạng unist cơ bản chứa position.start và position.end cho các nút (nodes); các điểm có thể bao gồm offset, nghĩa là một nút có thể được liên kết với một phạm vi chính xác trong tệp nguồn: unist specification.

Trong mô hình như vậy, agent đọc một Concept không chỉ dưới dạng văn bản, mà dưới dạng một cây: heading, paragraph, link, listItem, phần tử MDX JSX, v.v. Sau đó, nó có thể định địa chỉ một nút hoặc phạm vi cụ thể và chỉ gửi Markdown/MDX mới cho phần bị thay đổi.

Điều quan trọng là sau đó không bắt buộc phải tuần tự hóa lại toàn bộ AST. Các vị trí có thể được sử dụng để sửa đổi phạm vi tương ứng của source gốc, giữ nguyên phần còn lại của tài liệu theo từng byte (byte-for-byte).

Ưu điểm

• agent nhìn thấy cấu trúc thực tế của tài liệu, chứ không chỉ là chuỗi ký tự;
• dễ dàng phân biệt an toàn các tiêu đề, liên kết, danh sách, thành phần MDX và các nút khác;
• các thay đổi cấu trúc có thể chính xác và tự nhiên hơn;
• có tiềm năng cung cấp nền tảng vững chắc cho các thao tác nội dung nguyên bản của agent trong tương lai.

Nhược điểm

• AST lớn hơn đáng kể so với Markdown/MDX nguồn và có thể gây ra sự bùng nổ về ngữ cảnh truyền tải và chi phí;
• cần giải quyết bài toán định địa chỉ các nút ổn định đến mức nào giữa thời điểm đọc và ghi;
• các offset trở nên không hợp lệ sau khi tài liệu bị thay đổi đồng thời (concurrent modification);
• giao diện lệnh cho agent trở nên phức tạp hơn;
• một AST đầy đủ cho các bài viết lớn có thể tốn kém một cách bất hợp lý nếu chỉ cần thay đổi một dòng duy nhất.

Sự kết hợp có thể

Hai cách tiếp cận không nhất thiết loại trừ lẫn nhau.

Chế độ cơ bản có thể sử dụng MDX nguồn nhỏ gọn kết hợp text matching cho hầu hết các chỉnh sửa. AST có thể được tích hợp theo yêu cầu: đối với một thay đổi cấu trúc phức tạp, agent yêu cầu cây chỉ cho phần hoặc tài liệu cần thiết, sau đó thực hiện thao tác theo địa chỉ.

Sự kết hợp này có khả năng duy trì ưu điểm chính của Markdown — tính nhỏ gọn của ngữ cảnh — đồng thời giữ lại chế độ cấu trúc cho các trường hợp mà plain-text patch quá mong manh.

Bảo vệ chống lại phiên bản lỗi thời

Bất kể phương pháp định địa chỉ nào được chọn, việc kiểm soát phiên bản là cần thiết. RFC 5789 đặc biệt lưu ý về rủi ro xung đột PATCH và việc sử dụng các yêu cầu có điều kiện (conditional requests)/ETag để ngăn chặn việc áp dụng thay đổi lên trạng thái tài nguyên không mong muốn.

Đối với haih-agent, giải pháp tương đương có thể là revision/hash/updatedAt: agent nhận phiên bản cùng với tài liệu, và patch chỉ được áp dụng nếu phiên bản đó không thay đổi. Nếu không, thao tác sẽ bị từ chối và agent sẽ đọc lại ngữ cảnh hiện tại.

Trạng thái hiện tại

Đây là quá trình nghiên cứu các vấn đề kiến trúc, không phải là mô tả tính năng đã được triển khai.

Việc triển khai partial/agent-safe editing trong haih-agent vẫn chưa bắt đầu. Hiện tại, các yêu cầu, thực tiễn ngành hiện tại và hai phương án chính cho giải pháp của riêng chúng tôi đang được ấn định: chỉnh sửa nhỏ gọn thông qua text matching và chỉnh sửa cấu trúc thông qua MDX AST.

Việc quay lại triển khai chắc chắn nằm trong kế hoạch: với xu hướng phát triển hiện tại của fi1osof.ru và các trang web khác, các AI agent sẽ phải làm việc rất nhiều với khối lượng nội dung lớn. Việc ghi đè toàn bộ một bài viết khổng lồ chỉ để thay đổi các dòng, đoạn hoặc khối riêng lẻ tạo ra chi phí không đáng có và rủi ro mất dữ liệu. Do đó, chỉnh sửa một phần an toàn không còn là một tiện ích, mà trở thành một lớp cơ sở hạ tầng cần thiết cho CMS do agent quản lý.