LLM làm hỏng tài liệu khi được giao phó

• DELEGATE-52 là một benchmark đánh giá mức độ tài liệu được bảo toàn trung thực ra sao trong quy trình làm việc kiểu ủy nhiệm, nơi người dùng giao cho LLM các tác vụ chỉnh sửa tài liệu dài
• Benchmark này bao quát các tác vụ đòi hỏi chỉnh sửa tài liệu chuyên sâu trong 52 lĩnh vực chuyên môn như lập trình, tinh thể học, ký hiệu bản nhạc, v.v.; mô phỏng ví dụ được cấu thành từ việc ủy nhiệm 20 tác vụ liên tiếp
• Trong 19 thí nghiệm với LLM, ngay cả các mô hình frontier như Gemini 3.1 Pro, Claude 4.6 Opus và GPT 5.4 cũng làm hỏng trung bình 25% nội dung tài liệu khi kết thúc quy trình dài
• Việc làm hỏng tài liệu xuất hiện dưới dạng lỗi hiếm nhưng nghiêm trọng; mức suy giảm tăng lên khi kích thước tài liệu, độ dài tương tác và số lượng tệp gây nhiễu tăng, đồng thời việc dùng công cụ kiểu agent cũng không cải thiện hiệu năng
• Hiện tại, khó có thể xem LLM là tác nhân thay mặt đáng tin cậy trong chỉnh sửa tài liệu kiểu ủy nhiệm, và microsoft/DELEGATE52 cùng datasets/microsoft/DELEGATE52 đã được công bố như các tài nguyên liên quan đến DELEGATE-52

---

Dạng thất bại của chỉnh sửa kiểu ủy nhiệm

• Công việc kiểu ủy nhiệm dựa trên niềm tin rằng người dùng giao việc cho LLM và LLM sẽ hoàn thành mà không chèn lỗi vào tài liệu
• Trong các thí nghiệm quy mô lớn trên 19 LLM, các mô hình hiện nay làm suy giảm tài liệu trong quá trình ủy nhiệm
• Các mô hình khác thất bại nghiêm trọng hơn so với các mô hình frontier
• Việc làm hỏng tài liệu tích lũy trong các tương tác dài và âm thầm phá hỏng tài liệu

Các thay đổi tài liệu được nêu làm ví dụ

• Tài liệu Linux Kernel Architecture thuộc lĩnh vực Graph Diagrams được hiển thị ở mức 79% sau 4 lượt, 49% sau 10 lượt, 48% sau 14 lượt và 48% sau 20 lượt so với bản gốc trong Gemini 3.1 Pro
• Tài liệu 12-Shaft Twill Diamond thuộc lĩnh vực Textile Patterns được hiển thị ở mức 100% sau 4 lượt, 40% sau 10 lượt, 27% sau 14 lượt và 34% sau 20 lượt so với bản gốc trong Claude 4.6 Opus
• Tài liệu ActionBoy Palm Tree thuộc lĩnh vực 3D Objects được hiển thị ở mức 100% sau 4 lượt, 31% sau 10 lượt, 15% sau 14 lượt và 6% sau 20 lượt so với bản gốc trong GPT-5.2

Tài nguyên công khai

• microsoft/DELEGATE52
• datasets/microsoft/DELEGATE52

[GN⁺]

Ý kiến trên Hacker News

• Hoài nghi về kết quả dùng công cụ

  Không có gì đáng ngạc nhiên khi nội dung dài bị hỏng nếu cứ cho qua lại qua LLM. Những người dùng LLM thường xuyên đều đã biết là không nên làm vậy

  Tôi ngạc nhiên khi bài báo nói rằng việc dùng công cụ không giúp ích, nhưng đồng thời cũng nói rõ họ chỉ triển khai một “agent harness cơ bản” chứ không phải một hệ thống hiện đại được tối ưu hóa

  Trên thực tế harness này chỉ có read_file() và write_file(), nên về cơ bản nó gần như chỉ là thêm một bước vào quy trình qua lại. Các harness cho coding agent ngày nay đầu tư rất nhiều vào thiết kế công cụ chỉnh sửa tệp, ví dụ có bộ công cụ chỉnh sửa của Claude: https://platform.claude.com/docs/en/agents-and-tools/tool-us...

  Các lệnh str_replace và insert là then chốt để tránh kiểu chỉnh sửa nguy hiểm phải ghi lại toàn bộ tệp

  Ít nhất họ cũng cung cấp công cụ run_python(), nên có khả năng các model tốt hơn đã dùng nó để thực hiện thay thế chuỗi. Tôi muốn xem liệu system prompt có khuyến khích thao tác dựa trên Python hay lại dẫn model đến việc đọc rồi ghi lại tệp hay không

  Tôi tìm thấy mã harness ở đây: https://github.com/microsoft/delegate52/blob/main/model_agen...

  Mẩu prompt liên quan ghi rằng “có thể tiếp cận theo cách bạn cho là hiệu quả nhất, dù là theo kiểu lập trình hay ghi trực tiếp vào tệp”

  Như thường thấy ở các bài báo kiểu này, kết quả phản ánh thiết kế harness mà tác giả dùng nhiều hơn là bản thân model. Dù là kỹ sư AI có kinh nghiệm hay prompt engineer, tôi tin rằng nếu lặp lại và cải thiện chính harness đó thì hoàn toàn có thể đạt kết quả tốt hơn trong bài kiểm tra này

  • Tôi đồng ý với phần lớn ý này, nhưng ngoại trừ đoạn “những người dùng LLM thường xuyên đều đã biết là không nên làm vậy”

    Trong bối cảnh LLM đang được đẩy vào khắp các tổ chức và đội nhóm hiện nay, có rất nhiều người, có khi là đa số, dùng LLM mỗi ngày nhưng chưa từng đụng đến thứ mang tính kỹ thuật như harness

    Với những người đó, hành vi được nói tới ở đây là một vấn đề lớn

  • Hơi liên quan một chút, nhưng tôi muốn thấy một harness dùng ed làm công cụ mặc định để chỉnh sửa/đọc tệp. Một nửa số lệnh bash mà Claude chạy trông vốn đã giống sed, nên nếu ed giữ được trạng thái thì có vẻ sẽ hữu ích

    Phải làm gì khi một trình soạn thảo đầy đủ ngốn quá nhiều băng thông^H token? Dùng trình soạn thảo chuẩn ed thôi

  • Đây gần giống một ví dụ dựng bù nhìn cho công việc của LLM

    Với tác vụ chỉnh sửa, chỉ nên cho phép các lệnh chỉnh sửa theo kiểu lập trình, và văn bản không nên đi qua LLM. LLM nên phân tích văn bản rồi xuất ra các lệnh để đạt mục tiêu dựa trên phản hồi

  • Trên HN có xu hướng diễn giải kết quả theo hướng tiêu cực nhất có thể, vì người ta cảm thấy bị đe dọa đến nghề nghiệp và bản sắc của mình

    Thực ra nếu bảo con người đọc tài liệu rồi diễn đạt lại toàn bộ tài liệu sau khi áp dụng các chỉnh sửa, họ có thể làm còn tệ hơn mức suy giảm 25%. Tất nhiên con người cũng có thể đạt mức suy giảm 0%, nhưng khi đó họ phải thuộc lòng tài liệu sau khi nhập nó hàng trăm lần. Trường hợp tương ứng ở LLM là huấn luyện, và nếu huấn luyện LLM trên tài liệu đó thì trong trường hợp này nó có thể tương đương với một người đã thuộc lòng tài liệu khi chỉnh sửa

    Nhưng đó không phải điểm cốt lõi. LLM có điểm giống con người, nên harness phải được thiết kế để LLM chỉnh sửa bằng cách tìm kiếm và sửa chính xác, giống như cách con người chỉnh sửa tài liệu. Mọi coding agent đều chỉnh sửa như vậy, nên bài báo này không thật sự liên quan lắm

  • Dù là do hạn chế tài nguyên hay để đơn giản hóa, những bài báo kiểu này thật đáng tiếc là bị giảm giá trị bởi phương pháp luận khó hiểu

• Tôi đã nói từ lâu rồi: hễ quét sơn AI lên bất kỳ văn bản nào thì chất lượng sẽ giảm, và cứ lặp lại thì nó sẽ tích lũy

  Cách gọi tôi thích nhất cho hiện tượng này là “cắt bỏ ngữ nghĩa” (semantic ablation): https://www.theregister.com/software/2026/02/16/semantic-abl...

  • Tôi vẫn gọi nó là hồi quy về trí thông minh trung bình
  • Tôi tò mò “cứ lặp lại” ở đây nghĩa là lặp trong cùng một phiên, hay mỗi lần là một phiên mới hoặc một cửa sổ ngữ cảnh mới

• Ý chính là “ủy quyền cần có niềm tin. Phải có kỳ vọng rằng LLM sẽ hoàn thành công việc trung thực mà không đưa lỗi vào tài liệu”, và đó cũng chính là lý do các harness cùng nghi thức prompt với hàng chục tệp Markdown không hoạt động màu hồng như quảng cáo. Thực chất nó gần như là một dạng ngụy khoa học mang tên agent engineering

  Agent engineering rốt cuộc cũng gần giống cái gọi là prompt engineering, chỉ khác là prompt giờ bị rải khắp hàng chục tệp Markdown và thư mục

• Đây là điều ít gây ngạc nhiên nhất tôi từng đọc gần đây về LLM

  LLM giống như meme JPEG. Mỗi lần lưu thành JPEG thì chất lượng giảm đi một ít cho đến cuối cùng không còn nhận ra được nữa

  Chỉ khác là với LLM, điểm xuất phát là ý định. Mỗi lần đi qua LLM, ý định lại bị suy giảm, và với những thứ như bài báo khoa học chính xác cao, các sắc thái tinh vi cùng độ chính xác mất dần từng chút trong quá trình diễn đạt lại

  LLM là cỗ máy hồi quy về mức trung bình. Càng ở xa khỏi phạm vi học của nó xét theo ngữ cảnh hiện tại hoặc tải công việc, nó càng có xu hướng kéo mọi thứ về một trạng thái cân bằng trừu tượng, đồng nhất hơn

  • Tôi chắc chắn đã gặp điều này khi code với LLM. Sau khi dồn dập làm xong một loạt tính năng, tôi nghĩ mình đã khá cẩn thận, nhưng về sau khi nhìn kỹ những đoạn mã nhỏ thì rất hay có khoảnh khắc kiểu “trời ơi”

    Sau đó tôi phải dành vài tiếng rà lại toàn bộ, cẩn thận sửa những chỗ không đi theo ý mình, những chỗ tôi diễn đạt chưa rõ, và những chỗ thói quen kỳ quặc của LLM phát tác

    Chất lượng mã bản thân nó đã quan trọng rồi, nhưng thứ tôi lo chính là vấn đề nén lặp này. Nếu codebase sạch và mô hình trong đầu tôi còn cập nhật, LLM có thể giúp làm tính năng nhanh mà vẫn để codebase ở trạng thái ổn. Nhưng một khi LLM bắt đầu làm bẩn codebase, những sai lầm hay hiểu nhầm trong quá khứ sẽ tích lũy và nó ngày càng dễ làm sai nhiều thứ hơn. Vì vậy tôi chỉ yên tâm dùng lại LLM sau khi đã “khôi phục” nó về trạng thái đúng

  • Trường hợp kết quả này thực sự thú vị và liên quan là khi coding agent tách một tệp nguồn lớn thành nhiều tệp nhỏ hơn. Opus và Claude Code thay vì dùng các thao tác giống con người như sao chép/dán, lại cố gắng đọc thuộc các đoạn mã nguồn dài từ trí nhớ rồi đặt chúng vào các tệp mới

    Việc di chuyển tệp thì dễ hơn một chút. LLM đôi khi cũng cố diễn đạt lại tệp từ trí nhớ, nhưng nếu bảo nó dùng git mv rồi sửa lỗi biên dịch thì nhìn chung làm khá ổn

    Ngược lại, chỉnh sửa thông thường thường hoạt động tốt nếu có model và cấu hình công cụ hợp lý. Ngay cả Qwen3.6 27B cũng làm ổn ở mức này. Với chỉnh sửa tại chỗ, còn có thể dùng git diff để xem lại những thay đổi ngoài dự kiến

  • Có một trò chơi trẻ con cũng minh họa điều này: https://en.wikipedia.org/wiki/Telephone_game

  • Một đồng nghiệp của tôi gọi LLM là “tầng bịa bậy”. Không hẳn là để miệt thị hoàn toàn, mà để nhấn mạnh rằng mỗi lần cho thứ gì đó đi qua LLM, kết quả đi ra ở đầu bên kia có thể không giống điều bạn mong đợi hoặc muốn có

    Nó giống như nghe ai đó đã uống vài ly trong quán bar kể lại thông tin trực tuyến mà họ nói là đã thấy ở đâu đó. Có thể đúng, nhưng rủi ro sai cũng khá cao

    Ví dụ bạn không nên dùng LLM để gọi API, thu thập dữ liệu rồi tạo báo cáo. Làm vậy tức là cho dữ liệu mang tính quyết định đi qua tầng bịa bậy, nên không thể tin cậy kết quả được. Thay vào đó, tốt hơn là dùng LLM để viết mã tạo ra đầu ra có tính quyết định từ dữ liệu có tính quyết định

    Tôi đã thấy đồng nghiệp để LLM tóm tắt dữ liệu mang tính quyết định từ API, rồi báo cáo sai lệch nặng không kém gì lúc nó đúng. Tùy bạn đang xem cái gì mà đây có thể là rủi ro thảm họa

  • Tôi đã gặp điều này khi chỉnh sửa CV. LLM loại bỏ mọi yếu tố giúp CV của tôi khác với một mẫu kỹ sư junior trung bình có kinh nghiệm bình thường. Mọi thứ đặc biệt, độc đáo hay khác biệt cuối cùng đều bị thay bằng những cụm từ chung chung

    Tất nhiên tôi không dùng kết quả đó, nhưng việc LLM cứ khăng khăng rằng nó tốt hơn bản gốc thật sự rất bực bội

    LLM hữu ích hơn nhiều khi đưa ra đề xuất sửa những mẩu rất nhỏ trong CV, ví dụ một câu hoặc khoảng ba câu, thay vì định hình toàn bộ hướng đi của cả CV

• Vấn đề là chúng ta bắt LLM làm quá nhiều việc. Agent nên được thiết kế sao cho dùng LLM như một lớp mỏng nhất có thể để chuyển ý định ngôn ngữ tự nhiên thành quy trình có tính quyết định, và phải giảm tối đa số vòng qua lại với LLM

  • Ai thử làm thứ gì chỉ hơi phức tạp một chút rồi cũng sẽ thấy rõ điều này. Nếu xây dựng một pipeline kết hợp luồng tiền xử lý, nhắm mục tiêu theo ngữ nghĩa, gọi ngữ cảnh ở mức tối thiểu với API LLM, bạn sẽ có được một bước tự động hóa rất mạnh

    Khi kết hợp với một bước kiểm chứng riêng, LLM sẽ từ đồ chơi trở thành công cụ hữu ích

  • Chỉ khi không còn con người chen vào kiểu quy trình lặp như vậy nữa thì mới thật sự là quy trình tự động hóa

• Tôi thường chỉ bảo agent xử lý việc viết tài liệu như giai đoạn render cuối cùng. LLM rất giỏi trong việc gom góp và xâu chuỗi tri thức rải rác, nên tôi thích lưu tri thức dưới dạng các ý tưởng và dữ kiện có thể tổ hợp lại

  Cách thực tế đã cho kết quả tốt là đưa cho agent một thư mục và yêu cầu nó tạo một tệp Markdown độc lập cho mỗi dữ kiện hoặc phát hiện tìm được. Mỗi tệp có metadata ở phần đầu để dễ tìm kiếm

  Làm như vậy sẽ tách phần lớn công việc khỏi kiểu rối rắm “nghiên cứu và lưu liên tục theo định dạng tài liệu cuối cùng” thành hai việc gắn kết hơn: “nghiên cứu các dữ kiện và phát hiện giúp ích cho tài liệu” và “lắp ráp tài liệu”

  Đây không phải lời giải hoàn chỉnh, nhưng nó cải thiện khả năng tái sử dụng của các phát hiện, giống như khi con người làm việc

• Chẳng phải điều này cũng đúng với con người sao? Đó cũng là lý do trẻ con chơi “truyền tin” và thấy thông điệp bị méo đi như thế nào. Giải pháp là cung cấp một nguồn sự thật duy nhất

• Tôi đang làm công cụ để chống lại kiểu suy giảm này: https://github.com/JigSpec/JigSpec

• Tôi thật sự thích phương pháp đánh giá ở đây. Nó kiểm tra độ trung thực bằng cách cho một chuỗi các bước có thể đảo ngược đi qua lại

  Điều gây ấn tượng là ngay cả với những tác vụ bề ngoài có vẻ dễ để máy tính xử lý, các model tuyến đầu vẫn tích lũy lỗi

  Tôi tự hỏi liệu kết quả mạnh hơn ở Python chỉ là sản phẩm của một bài đánh giá thiên về Python, hay điều đó cũng đúng với các ngôn ngữ đa dụng phổ biến khác, và liệu có liên quan đến yếu tố cụ thể nào trong quá trình huấn luyện không

• Chúng ta phần lớn đã biết rằng model không thất bại vì vô số lỗi nhỏ, kiểu “ngàn vết cắt”. Ở một số vòng, nó tái dựng gần như hoàn hảo, rồi ở vài vòng khác lại gặp thất bại chí mạng làm mất hơn 10–30 điểm chỉ trong một lần

  Tương tự, sự suy giảm ở model yếu chủ yếu đến từ việc xóa mất nội dung, còn ở model tuyến đầu thì đến từ việc làm hỏng nội dung. Đó là lý do chúng ta cứ phải xoay chỉnh harness, nhiệt độ và những thứ tương tự như vậy