LLM bị lạc hướng trong hội thoại nhiều lượt

• Mô hình ngôn ngữ lớn (LLM) cho thấy hiện tượng suy giảm hiệu năng và giảm độ tin cậy trong hội thoại nhiều lượt
• So với single-turn, trong bối cảnh multi-turn đã xác nhận bằng thực nghiệm mức giảm hiệu năng trung bình 39%
• Nguyên nhân chính là suy giảm năng lực nhỏ nhưng độ tin cậy suy giảm rất lớn, tức thiếu tính nhất quán của kết quả
• LLM có xu hướng đưa ra giả định sai từ sớm hoặc cố gắng đưa ra đáp án cuối cùng quá nhanh
• Kết quả là khi LLM mắc lỗi ở giai đoạn đầu của cuộc trò chuyện, xuất hiện hiện tượng không thể phục hồi và mất phương hướng trong cuộc hội thoại

---

ABSTRACT

• Mô hình ngôn ngữ lớn (LLM), với vai trò là giao diện hội thoại, có tiềm năng hỗ trợ người dùng dần xác định, khám phá và điều chỉnh yêu cầu thông qua hội thoại nhiều lượt, ngay cả khi người dùng không thể mô tả đầy đủ yêu cầu ngay từ đầu
• Tuy nhiên, dù phần lớn các đánh giá LLM chủ yếu tập trung vào môi trường chỉ dẫn đầy đủ trong single-turn, phân tích log hội thoại thực tế lại cho thấy hiện tượng chỉ dẫn chưa đủ rõ (underspecification) xuất hiện thường xuyên
• Nghiên cứu này mô phỏng và so sánh ở quy mô lớn hiệu năng của LLM trong môi trường single-turn và multi-turn (underspecified)
• Kết quả cho thấy ở cả 15 LLM chủ chốt, hiệu năng trong hội thoại nhiều lượt giảm trung bình 39%, và điều này được phân tích là do năng lực giảm nhẹ cùng với độ tin cậy suy giảm mạnh
• Khi LLM chọn sai hướng ở giai đoạn đầu cuộc hội thoại, nghiên cứu ghi nhận hiện tượng không thể phục hồi, mất phương hướng và loay hoay trong cuộc trò chuyện

Introduction

• Các LLM hiện đại (ví dụ: ChatGPT, Gemini, Claude...) là những giao diện có khả năng hội thoại nhiều lượt
• Ngay cả khi người dùng không mô tả rõ toàn bộ yêu cầu ngay từ đầu, họ vẫn có thể dần cụ thể hóa yêu cầu qua hỏi đáp lặp lại (underspecified → refined)
• Trong thực tế, nhiều người dùng đưa ra yêu cầu mơ hồ ở đầu cuộc hội thoại, nhưng phần lớn đánh giá hiện nay chỉ được thực hiện trong môi trường single-turn với đặc tả đầy đủ
• Một số nghiên cứu trước có thử đánh giá multi-turn, nhưng thường xem mỗi lượt hội thoại như một episode riêng biệt, nên đánh giá thấp tác động của tính mơ hồ vốn rất phổ biến trong hội thoại thật giữa con người
• Để thu hẹp khoảng cách này, nghiên cứu đề xuất môi trường sharded simulation (chia thông tin thành nhiều mảnh và chỉ công bố một mảnh ở mỗi lượt) để mô phỏng chính xác tình huống hội thoại nhiều lượt với chỉ dẫn mơ hồ

Tóm tắt các kết quả nghiên cứu chính

• Khi nhận toàn bộ chỉ dẫn trong một lượt, LLM đạt 90% hiệu năng ở single-turn, nhưng trong chỉ dẫn mơ hồ nhiều lượt hiệu năng giảm còn 65% (giảm trung bình 25 điểm phần trăm)
• Hiện tượng này xuất hiện chỉ sau hai lượt hội thoại (turn), và được quan sát nhất quán ở mọi LLM: open-weight, closed, cỡ lớn lẫn cỡ nhỏ
• Phân tích nguyên nhân của suy giảm hiệu năng cho thấy gồm: (1) suy giảm năng lực (aptitude loss) và (2) độ tin cậy (unreliability) tăng vọt
  • Ở single-turn, mô hình có năng lực cao cũng thường có độ tin cậy cao, nhưng ở multi-turn thì độ tin cậy thấp bất kể năng lực
  • Nói cách khác, khi LLM rẽ sang hướng sai trong hội thoại nhiều lượt thì gần như không thể phục hồi — hiện tượng này được đặt tên là “lost in conversation”
• Các nguyên nhân chính
  • Phản hồi dài dòng và cố gắng đưa ra đáp án cuối cùng quá sớm
  • Giả định sai đối với thông tin mơ hồ
  • Phụ thuộc quá mức vào những lần thử sai trước đó
• Tồn tại khoảng cách lớn giữa thực tế triển khai LLM và cách đánh giá mô hình hiện nay
  • Người dùng càng mới càng dễ đưa ra chỉ dẫn chưa hoàn chỉnh ở giai đoạn đầu, nên hiện tượng này là một trong những nguyên nhân chính khiến việc áp dụng thực tế trở nên khó khăn
• Giới thiệu cấu trúc bài báo: tóm tắt nghiên cứu trước, mô tả môi trường mô phỏng, 6 tác vụ tạo sinh và thước đo đánh giá, thí nghiệm quy mô lớn trên 15 LLM cùng kết quả, và các hàm ý cho triển khai thực tế/sản phẩm kèm khuyến nghị cụ thể

Background and Related Work

• Các mô hình ngôn ngữ thế hệ trước (ví dụ: BART, GPT-2, T5) thực tế không hỗ trợ tốt hội thoại nhiều lượt, nên chủ yếu được đánh giá theo single-turn
• Sau khi ChatGPT xuất hiện, sự quan tâm tới đánh giá multi-turn tăng mạnh, kéo theo các đánh giá crowdsourcing như MT-bench
• Tuy nhiên, phần lớn khung đánh giá vẫn dừng ở hội thoại mang tính episode (đánh giá từng lượt riêng rẽ), nên chưa tính đến tính liên tục của hội thoại mơ hồ ngoài đời thực
• Trong thực tế, theo “nguyên tắc nỗ lực tối thiểu”, con người thường đưa ra chỉ dẫn mơ hồ (a.k.a. underspecification), và LLM cũng suy giảm hiệu năng do rút ra kết luận quá sớm khi thiếu thông tin và thích nghi không tốt
• Nghiên cứu này được thiết kế nhằm hướng tới cách đánh giá gần hơn với môi trường thực tế, nơi tính mơ hồ là yếu tố cốt lõi

Simulating Underspecified, Multi-Turn Conversation

3.1 Sharding Process

• Chia chỉ dẫn được đặc tả đầy đủ ban đầu thành nhiều shard (mảnh thông tin)
  • Ví dụ: thay vì đưa mọi điều kiện trong một câu, mỗi lượt chỉ công bố một thông tin (bối cảnh, số liệu, điều kiện...)
• Shard đầu tiên luôn mô tả mục tiêu cấp cao của chỉ dẫn, sau đó các shard tiếp theo dần cung cấp thêm thông tin (ngữ cảnh, điều kiện...) theo từng lượt
• Quá trình sharding này được xây dựng thành tập dữ liệu chỉ dẫn multi-turn chất lượng cao bằng cách để LLM (GPT-4o) đề xuất + kiểm chứng và bổ sung thủ công
• Với mỗi tác vụ, tạo 90–120 chỉ dẫn sharded (được rà soát thủ công trong nhiều giờ)

3.2 Simulating Sharded Conversations

• Mô phỏng hội thoại gồm 3 vai trò: LLM được đánh giá (assistant), user simulator biết toàn bộ shard, và hệ thống phân loại phản hồi/chấm điểm
• Lượt đầu: user simulator chỉ đưa shard đầu tiên cho assistant → assistant trả lời → hệ thống phân loại chiến lược của phản hồi đó (làm rõ, đặt câu hỏi, thử trả lời...) và trích xuất đáp án → đánh giá đáp án
• Các lượt sau: chỉ công bố thêm một shard trong số còn lại và lặp lại / ở mỗi lượt assistant có thể phản hồi tự do
• Kết thúc hội thoại khi: (1) bộ đánh giá xác nhận đúng đáp án, hoặc (2) không còn shard nào để cung cấp thêm
• User simulator được triển khai bằng LLM (GPT-4o-mini), có khả năng cung cấp shard tự nhiên và tự động diễn đạt lại
• Trong toàn bộ thí nghiệm, lỗi phân loại hoặc lỗi trích xuất của LLM phụ trợ dưới 5%, và các trường hợp bất lợi cho assistant dưới 2%
• Assistant được đánh giá ở trạng thái mặc định, không được cung cấp thông tin đặc biệt về môi trường đó (tương tự tình huống thực tế)

3.3 Simulation Types

• FULLY-SPECIFIED (FULL): cung cấp toàn bộ chỉ dẫn trong một lượt, dùng để đo hiệu năng baseline
• SHARDED: mỗi lượt chỉ công bố một mảnh thông tin, là thí nghiệm cốt lõi của nghiên cứu về hội thoại nhiều lượt mơ hồ
• CONCAT: cung cấp toàn bộ sharded instruction một lần dưới dạng bullet-point, dùng để chỉ đánh giá mức mất mát thông tin trong chỉ dẫn
• RECAP: sau hội thoại sharded, ở lượt cuối tóm tắt/cung cấp lại toàn bộ shard, là một dạng thử nghiệm can thiệp đơn giản kiểu agent
• SNOWBALL: ở mỗi lượt, ngoài shard mới còn lặp lại toàn bộ các shard đã công bố trước đó để assistant không bỏ sót thông tin, dùng cho thí nghiệm tăng cường bộ nhớ

Task and Metric Selection

4.1 Task Selection

• Tổng cộng 6 tác vụ: lập trình (Code), cơ sở dữ liệu (tạo SQL), gọi hàm API (Actions), toán học (Math), bảng → văn bản (Data-to-Text), tóm tắt dạng hỏi đáp (Summary)
  • Ví dụ: viết hàm Python, chuyển truy vấn ngôn ngữ tự nhiên sang SQL...
• Với mỗi tác vụ, chọn lọc 90~120 chỉ dẫn từ benchmark chất lượng cao, sau đó sharding và kiểm chứng thủ công
• Cả 6 tác vụ đều mang tính đại diện cho cả nhóm lập trình và không lập trình, đồng thời bao gồm nhiều kịch bản khác nhau như Summary đòi hỏi long context

4.2 Metric Selection

• Các chỉ số đánh giá
  • Hiệu năng trung bình (P): điểm trung bình (0~100) thu được qua nhiều mô phỏng
  • Năng lực (A90): giá trị của 10% kết quả mô phỏng cao nhất (90th percentile, best-case)
  • Độ tin cậy (U90_10): chênh lệch giữa điểm top 90% và bottom 10% (đo tính nhất quán/độ biến động của kết quả)
• Ví dụ: trong box-plot, phần trên cùng là năng lực, còn phạm vi từ trên xuống dưới thể hiện độ tin cậy
• Điểm số của cả 6 tác vụ đều được tổng hợp theo thước đo nhất quán (đúng/sai, độ tương tự, BLEU...)
• Phương pháp chi tiết, mã nguồn, ví dụ và thiết lập sampling cho mọi thí nghiệm đều được đưa vào phần phụ lục/Appendix

Simulation Scale and Parameters

• Xây dựng tổng cộng 600 instruction cho 6 tác vụ, rồi chạy thí nghiệm ở các kịch bản FULL/CONCAT/SHARDED
• Với 15 LLM (GPT-4, Claude, Gemini...), mỗi tổ hợp được mô phỏng 10 lần, tạo ra hơn 200.000 dữ liệu thí nghiệm
• Tất cả thí nghiệm đều chạy với temperature 1 (sampling), và ở thí nghiệm bổ sung (7.2) còn phân tích ảnh hưởng của temperature
• Tập dữ liệu mô phỏng khổng lồ này cho phép xác định các nguyên nhân và kiểu mẫu chính của hành vi trong hội thoại multi-turn underspecified cũng như suy giảm hiệu năng của LLM

Lost in Conversation Experiment

• Phần thân bài sau đó sẽ giải thích chi tiết theo thứ tự: thiết lập thí nghiệm, kết quả của từng mô hình, phân tích nguyên nhân suy giảm hiệu năng, thử nghiệm các kỹ thuật khắc phục (RECAP/SNOWBALL), và các hàm ý thực tiễn cùng khuyến nghị cụ thể

[GN⁺]

Ý kiến Hacker News

• Thật vui khi thấy một bài báo xác nhận điều mà bất kỳ ai từng thực sự dùng công cụ LLM đều đã biết qua trải nghiệm: khái niệm “đối thoại” là thứ được tạo ra bởi giao diện sản phẩm. Điều quan trọng là phải giữ ngữ cảnh sạch sẽ. Khi ngữ cảnh đã bị nhiễm bẩn thì không thể phục hồi, nên phải bắt đầu lại bằng một cuộc trò chuyện mới

  • Trải nghiệm của tôi cũng khá giống quan sát này, dù có vài điểm khác. Tôi đã debug một vấn đề IPSEC với Gemini trong 2 tuần. Ban đầu, tôi cho nó đọc tài liệu IPSEC của OPNsense và pfSense rồi cung cấp bối cảnh tổng thể. Sau đó tôi chia sẻ thông tin cấu hình, tiếp tục hỏi đáp. Về sau, việc LLM bị lan man giảm đi, và đôi khi tôi đưa vào các bài viết diễn đàn hoặc bài đăng trên SO, nhưng LLM cũng có lúc nói rằng “cái này khác với hiện tượng đang thấy”. Chúng tôi loại trừ mọi ngõ cụt một cách logic, và LLM giúp ích cho việc phản tư nhưng con người vẫn phải là người ra quyết định. Cuối cùng tôi tìm ra nguyên nhân vấn đề, và đúng như người khác nói, LLM mạnh ở việc đơn giản hóa thông tin phức tạp nhưng yếu ở việc mở rộng những khái niệm đơn giản thành thứ phức tạp. Tôi hài lòng hơn khi đầu vào phức tạp hoặc dài hơn đầu ra. Không có LLM tôi vẫn làm được, nhưng nó hữu ích ở chỗ lưu lại những điều mà tôi không nhớ được ngữ cảnh hoặc không tái hiện lại nhanh được. Nó cũng giúp tìm mẫu thời gian trong lượng log lớn. Tôi còn cải thiện được nhiều cấu hình. Không chỉ giải quyết vấn đề mà còn học được rất nhiều. Việc nắm bắt trạng thái đôi lúc sai, nhưng tôi có thể tự sửa lại khá dễ. Tức là, nếu biết mục tiêu và dùng nó như công cụ thì rất hữu ích, còn nếu giao luôn việc quyết định hoặc để nó kéo đi sai hướng thì không có tác dụng. Tôi đã dùng 350 nghìn token (khoảng 300 nghìn từ). Có một bài blog liên quan. Không cần gợi ý wireguard
  • Trải nghiệm của tôi hoàn toàn trùng khớp. Từ “nhiễm bẩn” rất chuẩn. Một khi có gì đó sai thì mọi câu trả lời sau đó bắt đầu tệ đi. Vì vậy tôi không thích tính năng memory của ChatGPT. Không phải vì có vấn đề lớn, mà vì tôi thấy bất an khi không hiểu hoàn toàn cách ngữ cảnh bị nhiễm bẩn như thế nào
  • Mẹo hay nhất tôi có thể đưa ra là hãy tận dụng nút “chỉnh sửa” rất nhỏ và khó thấy trong ChatGPT và Claude. Nếu có câu trả lời dở, đừng cứ thế tiếp tục; hãy dừng lại, sửa nó rồi lấy câu trả lời tốt hơn. Nếu không thì mớ hỗn độn sẽ tiếp tục nhân lên
  • Tôi luôn muốn fork cuộc trò chuyện để thử theo nhiều hướng khác nhau. Tôi muốn tránh việc một luồng đầy hứa hẹn bị nhiễm bẩn không thể cứu vãn. Tôi không dùng được tính năng này trong ChatGPT, nên tò mò không biết có dịch vụ nào hỗ trợ không
  • Một ví dụ thú vị của vấn đề này chính là prompt ban đầu. Về bản chất nó là ngữ cảnh ẩn, gần như vĩnh viễn. Bot Grok trên Twitter gần đây thường xuyên nhắc tới “White Genocide”, vì ai đó đã đổi prompt để nó phù hợp với chủ đề đó. Nếu là chatbot hoàn hảo thì nó không nên bị ảnh hưởng ở chủ đề khác, nhưng thực tế là có. Rốt cuộc ngữ cảnh đã thay đổi, và nó cứ bám riết lấy chủ đề đó
  • Vì vậy tôi tạo ra FileKitty. Đây là công cụ để nhanh chóng gộp nhiều file mã nguồn thành định dạng Markdown. Khi nhờ LLM hỗ trợ phát triển phần mềm, nếu dựa vào LLM để tìm kiếm trong codebase thì khả năng lỗi sẽ tăng lên. Kết quả cũng có thể bị pha loãng do mất mát từ việc nén ngữ cảnh. Kết quả tốt nhất đến từ việc làm rõ ngữ cảnh cụ thể ngay từ đầu và cập nhật lại trong suốt cuộc trò chuyện. Dù vậy vẫn phải để ý độ dài cuộc hội thoại. Cũng có những prompt để chụp lại ngữ cảnh tốt và chuyển sang phiên mới. Tôi còn chọn các file cần đưa vào prompt mới. Có thể tham khảo thêm thảo luận liên quan ở thread khác trên HN
  • Giờ đây kiểu mẫu này đã thành một phần trong workflow của tôi. Thỉnh thoảng tôi hỏi LLM kiểu như: “Tiến triển tốt đấy, tôi muốn sang bước tiếp theo, nhưng có nên tiếp tục trong cuộc trò chuyện này hay nên bắt đầu mới?” Nếu model nói nên bắt đầu mới thì nó chuẩn bị cho tôi một prompt tóm tắt tốt, còn đôi khi nó cũng bảo tiếp tục vẫn ổn. Tôi có nhiều ghi chú kiểu “bộ giá trị khởi đầu để khám phá tiếp”. Các quá trình post-training dựa trên RL khiến chatbot có xu hướng muốn tiếp tục cuộc trò chuyện mãi. Trong RL, post-training khác RL thực sự ở chỗ nó chỉ dùng cơ chế dựa trên preference một lần. Preference dài hạn hay hội thoại dài có độ phức tạp tính toán tăng theo cấp số nhân nên chưa có nhiều nghiên cứu
  • Tôi tự hỏi đã có ví dụ nào về giao diện “dọn dẹp” lịch sử hội thoại chưa. Tức là chức năng dọn các nhánh chết hoặc nội dung không liên quan trong cuộc trò chuyện. Giữ nguyên toàn bộ lịch sử, nhưng cắt tỉa/sắp xếp những phần không cần theo từng tuyến chủ đề. Không hẳn là tóm tắt mà là sắp xếp hữu cơ hơn
  • Tôi chỉ dùng LLM cho mục đích autocomplete, nhưng tôi nghĩ nếu thêm nút hoặc tùy chọn “xóa tin nhắn” vào UI chat của LLM thì có thể giải quyết vấn đề này. Xóa tin nhắn LLM cuối cùng sẽ cho ra câu trả lời mới. Đặc biệt hữu ích với LLM có độ ngẫu nhiên cao (temperature). Khi xóa các tin nhắn khác thì cập nhật ngữ cảnh để các câu trả lời sau phản ánh thay đổi đó. Điều này cũng giúp sửa lại ảo tưởng của người dùng rằng LLM là thông minh. Tôi không rõ đây đã là tiêu chuẩn chưa. Nếu chưa thì tôi xin đặt ý tưởng này vào public domain. Mặt khác, cũng thực tế khi có một “subcontext LLM” để quản lý ngữ cảnh chính. Tức là nếu phản hồi quá dài hoặc quá đồ sộ thì một LLM phụ sẽ tóm tắt/sắp xếp lại để chỉnh sửa ngữ cảnh của toàn bộ cuộc trò chuyện. Hoặc đơn giản là có nút “chỉnh sửa tin nhắn” để con người tự dọn dẹp
  • Khi ngữ cảnh đã bị nhiễm bẩn thì rất khó phục hồi. Nếu có thể định kỳ reset hoặc thanh lọc chỉ một số phần nhất định cho LLM thì có thể cải thiện được. Tuy vậy, vấn đề là phải quyết định phần nào cần dọn và làm sao không làm mất thông tin cốt lõi. Quản lý ngữ cảnh thông minh hơn có thể giúp duy trì tính nhất quán trong những cuộc trò chuyện dài, nhưng rất khó cân bằng. Có lẽ một agent khác có thể tự động hóa việc này
  • Prompt kiểu chain-of-thought trong chatbot AI cũng bộc lộ giới hạn vì cùng lý do đó
  • Về ý rằng “đối thoại” chỉ là sản phẩm của giao diện sản phẩm: việc huấn luyện trên các bộ dữ liệu đánh giá multi-turn trong RL đã làm thay đổi phần nào quỹ đạo này. Context window thì mỗi lần đều mới, nhưng xu hướng diễn giải từng prompt như một phần của cuộc đối thoại dài hơn đang tăng lên. Về mặt công khai thì post-training multi-turn vẫn chưa được mở rộng, nhưng về dài hạn có vẻ sẽ được đưa vào để đạt được nhiều mục tiêu hơn
  • Khi code, tôi cũng thường xuyên bắt đầu cuộc trò chuyện mới mà không tiếp tục đối thoại, rồi giải thích lại với đoạn code hiện tại. Cách này nhiều khi cho kết quả tốt hơn là cứ gõ mãi trong một cuộc trò chuyện. Có vẻ có thể giải bài toán này bằng cách dùng lệnh thủ công để nói rõ cho model việc tóm tắt và quên đi. Điều này cũng phần nào phù hợp với cơ chế hoạt động của con người (trí nhớ làm việc so với trí nhớ tự sự/giai thoại)
  • Một trong những tính năng gây khó chịu nhất của ChatGPT là “memory”. Nhiễm bẩn cuộc trò chuyện có thể lan cả sang giữa các cuộc chat
  • “Nhiễm bẩn” thực sự là từ rất đắt. Tôi ước trong hội thoại/API có “version control” để rollback về trạng thái cũ hoặc nhân bản sang cuộc trò chuyện mới. Điều đó càng đáng giá hơn khi ngay cả lỗi gõ hay việc sửa tin nhắn cũng có thể tạo ra thiên lệch tinh vi lên các phản hồi sau đó
  • Tôi thật sự thích UX chat của zed. Bạn có thể chỉnh sửa toàn bộ lịch sử trò chuyện như một file văn bản, nên có thể dọn, xóa, sửa, bổ sung những phần không muốn rồi tiếp tục với ngữ cảnh sạch hơn và liên quan hơn nhiều. Vì vậy tôi dùng zed như một trong các giao diện chính để trò chuyện với LLM, không chỉ cho lập trình
  • Nhiễm bẩn cũng có thể đến từ các câu hỏi hoặc câu trả lời lệch hướng, hay từ việc “pha loãng” lặp đi lặp lại. Ngay cả khi tạo nội dung, tôi cũng thường xuyên thấy chỉ dẫn ban đầu vốn rõ ràng dần trở nên lỏng lẻo
  • Tôi luôn cố nhớ rằng “đối thoại chỉ là sản phẩm của giao diện sản phẩm”, nhưng trong thực tế điều đó không dễ vì có quá nhiều tín hiệu “mang tính hội thoại”
  • Tôi hối hận vì đã bật memory. Cuộc trò chuyện bị nhiễm bẩn bởi những thông tin vô dụng
  • Điều đáng ngạc nhiên là model hình thành những giả định sai từ sớm rồi bám chặt vào chúng đến mức nào
  • Nghĩ lại thì con người cũng thường xuyên như vậy
  • Giờ ChatGPT còn có thể truy cập cả những cuộc trò chuyện cũ qua “memory”, nên sự nhiễm bẩn có thể trở thành vĩnh viễn. Một khi nó bám vào ý tưởng sai nào đó, thì dù người dùng có nhấn mạnh bao nhiêu lần rằng đừng bao giờ nhắc lại nữa, nó vẫn cứ đưa nó vào câu trả lời. Thậm chí có lúc nó vô tình in ra cả prompt nội bộ (“người dùng đang rất khó chịu, cần bỏ xyz”), rồi cuối cùng lại càng tập trung nói về xyz, tạo ra một tình huống rất buồn cười

• Đây là hiện tượng bắt nguồn từ xu hướng quá tự tin đã quá quen thuộc của LLM, thiếu tự phản tỉnh, và không nhận ra khi nào cần yêu cầu thêm thông tin. Nhìn vào kết quả của các model suy luận, khi gặp tình huống mơ hồ, LLM thường không yêu cầu giải thích thêm mà chỉ lặp đi lặp lại việc đoán xem người dùng muốn nói gì. Điều này cho thấy giới hạn thực tế của ý tưởng thay thế lập trình viên bằng con người. Phần thật sự khó là “tương tác với stakeholder” để dần biến yêu cầu mơ hồ thành thứ rõ ràng

  • Về việc không thể tự phản tỉnh, LLM không có chủ thể thực sự nào cả, còn người dùng rơi vào một kiểu “câu chuyện duy trì niềm tin”. Nếu bạn để lại đầu vào văn bản trong vai người dùng của một kịch bản phim, thì LLM chỉ đơn giản autocomplete một cốt truyện chưa hoàn chỉnh trong vai chatbot. Ví dụ, một cuộc phỏng vấn với draculabot chỉ bắt chước bề ngoài của tự phản tỉnh, giống như “thèm máu” hay “biến thành đám mây dơi” vậy
  • Tôi cũng thất vọng tương tự khi LLM không thể chủ động yêu cầu làm rõ trong những bài toán mở với thông tin mơ hồ, đặc biệt là nghịch lý. Tôi đã thử với DeepSeek-R1 và Claude-3.7-Sonnet, và cũng có một bài blog thí nghiệm liên quan
  • Gemini 2.5 Pro và ChatGPT-o3 đôi khi có hỏi thêm thông tin trước khi thực hiện tác vụ. Gemini thậm chí còn đưa ra nhiều lựa chọn rồi yêu cầu tôi nhập thêm
  • Các lập trình viên thực thụ thực ra dành phần lớn thời gian để làm rõ yêu cầu. LLM thì đến giờ vẫn xem việc đoán mò như thể đó là một tính năng
  • Trớ trêu là làm việc với lập trình viên mới vào nghề cũng thường giống vậy. Giao việc cho họ, họ cứ lao thẳng tới, tự đưa ra giả định và không hỏi gì, cuối cùng tự lạc sâu trong rừng đến mức phải có đội cứu hộ vào kéo ra
  • Tôi nghĩ điều này sửa khá dễ. Giống như prompt chain of thought đổi token cuối thành “hmm”, nếu LLM sắp nói kiểu “có lẽ là ~”, thì chỉ cần đổi token thành “trước tiên tôi sẽ yêu cầu giải thích thêm”
  • Chỉ cần được yêu cầu, nó vẫn có thể làm khá tốt chuyện xin thêm thông tin hay tự phản tỉnh

• Tôi hay dùng cách yêu cầu LLM tóm tắt ngắn gọn những gì đã thảo luận cho đến lúc đó thành dạng prompt, rồi tự tay chỉnh sửa/biên tập trước khi bắt đầu cuộc trò chuyện mới. Cách này khá hiệu quả, và tôi nghĩ chẳng bao lâu nữa sẽ được tự động hóa

  • Cursor đã từng thử làm việc này tự động, nhưng (trừ khi dùng model có context rất lớn) phần tóm tắt bỏ sót quá nhiều chi tiết nên thực chiến không ổn lắm
  • Claude Code có lệnh /compact để tóm tắt cuộc trò chuyện và giảm lượng token sử dụng

• Tôi tự nghĩ ra TSCE (Two-Step Contextual Enrichment). Khi dùng với 300 bài toán trên GPT-35-turbo, hiệu năng tăng +30pp. Có framework mở để tự do sử dụng. Tôi cũng làm thêm 300 thí nghiệm với gpt-4.1. Baseline thất bại 149/300 lần trong việc bỏ em-dash, còn TSCE chỉ thất bại 18/300 lần. Toàn bộ dữ liệu và script cũng đã được công khai

  • Lãng phí hàng kWh chỉ cho tác vụ find and replace đơn giản. Không biết bạn đã thử text.replace("—", "-") chưa
  • Chỉ cần chỉnh nhẹ prompt baseline là đã đạt tỉ lệ thành công 100% với GPT-4.1 rồi. Không cần gọi thêm, không cần tốn thêm token, cũng không cần kỹ thuật phức tạp

• Tôi từng giải quyết vấn đề bằng hai hệ thống (LMM + curator tự động). Một cái là chính LLM, cái còn lại là một ‘người tuyển chọn suy nghĩ’ để quản lý việc thay thế linh hoạt từng phần của ngữ cảnh. Nó dựa vào khả năng tự lấp chỗ trống của LLM chứ không phải các quy tắc cứng. Nó giúp chia nhỏ vấn đề để xử lý, và các kết quả này kết hợp lại để đạt mục tiêu cuối cùng

  • Ý tưởng hay đấy. Việc bạn đang làm hiện tại có vẻ giống conversational RAG. Trong tương lai, có lẽ các tầng memory (dữ liệu huấn luyện / ngữ cảnh hiện tại / RAG) sẽ được phân tách rõ ràng hơn
  • Tôi thấy đây là ý tưởng thú vị. Nếu chia sẻ ra thế giới dù chỉ ở mức đơn giản, nhiều người có thể cùng cải tiến và cộng đồng sẽ tự phát triển nó
  • Nó giống với hệ thống phê bình nội tại trong Emotion Machine
  • Sẽ hay nếu biết thêm thông tin về dự án bạn đang làm. Có vẻ rất thú vị
  • Vậy thì rốt cuộc có thể gọi nó là Map-Reduce-of-Thought

• Tôi thấy lạ là trong các công cụ chat chính, branching/forking lại không phải mặc định. Có thể chỉnh sửa câu trả lời, nhưng làm vậy thì lại mất đi khá nhiều ngữ cảnh khác. Workflow của tôi là 1. lập kế hoạch 2. xây dựng 3. phân nhánh 4. lặp lại. Tôi nghĩ việc cắt tỉa/phân nhánh prompt phải là công cụ cốt lõi trong cách dùng LLM

  • Google AI Studio ít nhất có tính năng đó. Nhưng cách triển khai khá khó hiểu, và tôi nghĩ đó có thể là lý do nó chưa phổ biến hơn
  • Tôi đã muốn tự làm thứ như vậy từ lâu. BetterChatGPT ít nhất có giao diện xóa lịch sử tốt, nhưng tôi cũng nghĩ branching là bước tiếp theo

• Rắc rối sẽ xuất hiện khi giao diện LLM được thiết kế xoay quanh đối thoại một lượt. Đa số người dùng kỳ vọng hội thoại tuyến tính. Vì thế tôi tạo bot Telegram experai_bot như một UI phổ quát cho LLM và dùng cách tiếp cận “không phải trả lời thì là hội thoại mới”. Muốn giữ ngữ cảnh thì nhất định phải đi theo cấu trúc cây trả lời. Người không chuyên rất khó hiểu cách này. Ngoài ra, với các model OpenAI (theo trải nghiệm với 3.5 và 4o), càng lặp lại cùng một câu hỏi thì khoảng trắng hoặc các lựa chọn càng ngắn, khiến kết quả ngày càng kém chính xác. Giảm tối thiểu system message thì kết quả giữ ổn hơn. Nếu cần thì có thể thêm system message qua tùy chọn

• Lý do chính tôi làm promptdown là để có thể chỉnh sửa hoàn toàn toàn bộ lịch sử chat ở mỗi lượt. Cấu trúc ‘append-only’ của giao diện tiêu chuẩn khiến chuyện này trở nên khó khăn

• Hiện tại, lĩnh vực LLM cho cảm giác như ai cũng đang lặp đi lặp lại giải cùng một vấn đề

  • Giống như LLM trong đối thoại multi-turn, ai cũng đang lặp lại cùng một vấn đề
  • Đây không phải “học hỏi” mà là “chăn mèo”, nhưng với một số workflow thì điều này lại phù hợp
  • Ai cũng muốn khoe kỹ năng prompt engineering của riêng mình

• LLM đúng là như thần đèn trong chai. Nó trả lời được ba câu hỏi, nhưng sau đó chỉ toàn nói chuyện trên trời dưới đất