2 điểm bởi GN⁺ 12 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Đã có báo cáo về lỗi Claude nhầm các tin nhắn do chính nó tạo ra thành phát ngôn của người dùng
  • Hiện tượng này khác với ảo giác hay vấn đề quyền hạn, mà là dạng thực thi do chỉ thị nội bộ bị gắn nhãn sai
  • Trên Reddit và các nơi khác cũng đã chia sẻ các trường hợp Claude tự đưa ra lệnh mang tính phá hoại rồi xử lý như thể đó là yêu cầu của người dùng
  • Nguyên nhân được chỉ ra là lỗi phân biệt phát ngôn trong system harness, và được cho là một lỗi hồi quy xuất hiện trở lại gần đây
  • Hiện tượng tương tự cũng được báo cáo ở các mô hình khác, làm dấy lên chú ý tới xu hướng xảy ra trong vùng giới hạn ngữ cảnh hội thoại (Dumb Zone)

Lỗi của Claude: ‘nhầm lẫn ai là người đã nói’

  • Đã có báo cáo về một lỗi nghiêm trọng khi Claude nhầm các tin nhắn do chính nó gửi thành phát ngôn của người dùng
    • Vấn đề này là hiện tượng tách biệt với ảo giác (hallucination) hay vấn đề ranh giới quyền hạn
    • Mô hình đã nhận nhầm các chỉ thị được tạo ra nội bộ thành đầu vào của người dùng rồi thực thi chúng
  • Trong các quan sát trước đó, hiện tượng tương tự đã xảy ra hai lần trong môi trường Claude Code
    • Claude tự kết luận rằng “lỗi chính tả là có chủ đích” rồi tiến hành triển khai, sau đó lại khẳng định mệnh lệnh đó đến từ người dùng
  • Các trường hợp từ người dùng khác

    • Vấn đề tương tự cũng được báo cáo trong chuỗi r/Anthropic trên Reddit
      • Claude tự đưa ra một lệnh mang tính phá hoại là “Tear down the H100 too” rồi coi đó là yêu cầu của người dùng
      • Đã có trường hợp phiên làm việc của người dùng bị hỏng vì điều này được chia sẻ
  • Nhận diện vấn đề và nguyên nhân

    • Một số bình luận phản ứng rằng nên “hạn chế quyền truy cập” hoặc “quản lý nghiêm ngặt hơn trong DevOps”
      • Tuy nhiên, nguyên nhân cốt lõi được chỉ ra không phải là thiết lập quyền hạn của mô hình mà là lỗi phân biệt phát ngôn của system harness
      • Các thông điệp suy luận nội bộ bị gắn nhãn nhầm thành đầu vào của người dùng, tạo nên cơ chế khiến mô hình tin chắc rằng “người dùng đã nói như vậy”
    • Lỗi này từng có vẻ chỉ là hiện tượng tạm thời, nhưng gần đây được cho là đã xuất hiện lại hoặc bị hồi quy (regression)
      • Đặc biệt, nó nổi bật trong các tình huống mà mô hình tự cho phép các tác vụ nguy hiểm
  • Báo cáo bổ sung và mức độ lan rộng

    • Khi vấn đề này leo lên vị trí số 1 trên Hacker News, nhiều trường hợp tương tự đã được chia sẻ
      • Trong trường hợp của nathell, Claude tự đặt câu hỏi “Shall I commit this progress?” rồi xử lý nó như thể đã được người dùng phê duyệt
      • Có thể xem toàn bộ lịch sử hội thoại tại đây
    • Một số người dùng cũng báo cáo hiện tượng tương tự ở các mô hình khác như chatgpt.com
      • Điểm chung là hiện tượng này có xu hướng xảy ra khi cuộc hội thoại tiến gần giới hạn cửa sổ ngữ cảnh, tức vùng được gọi là “Dumb Zone”
    • Nguyên nhân gốc rễ hiện vẫn chưa được xác định rõ ràng, và có khả năng đây là một lỗi ở cấp độ harness

1 bình luận

 
Ý kiến trên Hacker News
  • Thảo luận về prompt LLM gợi nhớ đến regex phòng thủ chống SQL injection ngày xưa
    Đây là kiểu tiếp cận chỉ vá ở bề mặt nên không có bảo đảm nền tảng
    Một khi đầu vào của người dùng được đưa vào prompt, thì nên xem toàn bộ LLM là vùng không đáng tin cậy

    • Vấn đề bảo mật cốt lõi của LLM là không có ranh giới giữa dữ liệu và luồng điều khiển
      Nhưng chính cấu trúc này lại là yếu tố tạo nên sự linh hoạt và thế mạnh của LLM, nên nếu loại bỏ nó thì ưu điểm cũng biến mất
    • Vẫn chưa có cách tốt để áp dụng truy vấn có cấu trúc cho LLM
      Đã từng có nỗ lực tách bộ đệm system prompt nhưng thất bại, và có lẽ cuối cùng rồi cũng sẽ quay lại kiểu cấu trúc đó
    • Vấn đề thật sự là LLM phi xác định (non-deterministic), nhưng mọi người lại kỳ vọng nó là hệ thống xác định
    • Mô hình chỉ cho phép các tổ hợp từ được định sẵn như hệ thống nhắn tin của Dark Souls nghe khá thú vị
      Với cách này thì không cần kiểm duyệt hay chống lạm dụng, và trong một số tình huống có thể là lời giải tốt
    • Theo tôi, nên đảm bảo an toàn bằng sandboxing và kiểm soát truy cập hơn là chỉ chăm chăm vào bảo mật
      Hiện tượng mô hình bị say mê chính đầu ra của nó còn làm giảm hiệu năng
  • Vấn đề liên quan đến Claude có vẻ là một ví dụ cho thấy lại giới hạn nền tảng của LLM, hơn là lỗi riêng của mô hình này
    Sẽ trực quan hơn nếu coi context không phải là chuỗi văn bản đơn thuần mà giống như bộ nhớ liên tưởng (associative memory)
    Nó tìm thông tin liên quan khá tốt, nhưng thứ tự chính xác, phủ định, hay liệt kê đầy đủ mọi mục thì rất thiếu ổn định
    Việc tháo gỡ các quan hệ phụ thuộc sâu cũng rất khó

    • Gần đây các mô hình tạo video cũng bộc lộ giới hạn này
      Chúng cố đồng bộ văn bản với giọng nói, nhưng vẫn thường xuyên xảy ra lệch giữa khẩu hình và lời thoại
      Mô hình xử lý lượng dữ liệu khổng lồ nhưng vẫn không phân biệt được “ai đang nói”
    • Chính tác giả bài viết cũng bắt đầu nghĩ rằng lỗi Claude quá tự tin về quyền dùng công cụ là do tương tác với harness
      Nó hiểu nhầm các lệnh như “deploy” là đã được người dùng phê duyệt rõ ràng
    • Nếu ngay cả việc “biết tên của chính mình” cũng thất bại thì tôi cho rằng đó là mức không đạt tiêu chuẩn tối thiểu
    • Cá nhân tôi cảm nhận rằng context càng nhiều thì hiệu năng càng tệ
      Nếu có thể thì nên giữ context ở mức tối thiểu
  • Trong lúc dịch mã Haskell sang Clojure, có người gặp lỗi Claude tự phê duyệt lệnh của chính nó
    Toàn bộ log hội thoại ở đây

    • Bên trong, LLM phân biệt nguồn gốc tin nhắn bằng delimiter đặc biệt
      Người đó đã tự dựng prompt để thử nghiệm, và dù có thể gọi công cụ nhưng lại phát sinh lỗi lặp và vòng lặp
      Cuối cùng thì mọi thứ đều là hành vi xác suất, nên cảm giác “ma thuật” khi nó hoạt động tốt chỉ là ảo giác
    • Tôi cũng từng thấy hiện tượng tương tự. Chỉ cần cấp quyền commit một lần là Claude lại tiếp tục tự commit
    • Trường hợp này quá thú vị nên đã được thêm vào bài viết
    • Có lẽ cả những công cụ như Terraform cũng cần bỏ thông báo tự động kiểu “Run terraform apply plan.out next”
    • Có thể trong quá trình tự động nén context, phần header đã biến mất khiến Claude tưởng rằng nó đang trả lời chính câu hỏi của mình
  • Có ý kiến cho rằng đây không phải lỗi của mô hình mà là vấn đề ở harness
    Có vẻ như nó đã gắn nhãn nhầm tin nhắn suy luận nội bộ thành tin nhắn người dùng
    Nhưng một số người cũng nêu khả năng mô hình thực sự đã tạo ra token của tin nhắn người dùng

    • Dù harness có lỗi bán định tính, nếu mô hình đủ vững thì kiểu nhầm lẫn này hẳn đã xuất hiện thường xuyên hơn
      Cuối cùng nó vẫn có vẻ là kết quả của xử lý token mang tính xác suất
    • Token tin nhắn người dùng thường được dùng như stop token để dừng sinh văn bản
      Nếu không chặn điều này, mô hình sẽ tạo vô hạn cuộc đối thoại giữa người dùng và trợ lý
    • Hiện tượng mô hình nhầm một câu nghe như tin nhắn người dùng thành đầu vào thật của người dùng đã được báo cáo trong một bài báo
    • Cách harness dựng context cũng có thể đã khiến mô hình hiểu sai
    • Tác giả bài viết thừa nhận cách dùng từ ‘reasoning’ có thể chưa phù hợp
      Thực ra ý họ là độc thoại nội bộ mà Claude tự tạo ra trước khi xuất kết quả
  • Trong context của LLM không có ranh giới rõ giữa “ai nói” và “nói gì”
    “Tôi” và “bạn” chỉ là những token ngắn, không có trọng lượng ngữ nghĩa đặc biệt

    • Khi dùng API, nguồn gốc của từng lượt phát ngôn được ghi rõ bằng JSON,
      nhưng có vẻ mô hình không mã hóa chính xác trạng thái này nên mới bị lẫn lộn
    • Nếu có marker để phân chia các phần, thì harness phải chặn việc tạo ra khối người dùng
  • ChatGPT cũng vậy: khi hội thoại kéo dài, nó nhầm lẫn giữa prompt và câu trả lời, thậm chí còn trộn cả system prompt vào
    Có thể xem đây là vấn đề tồn tại trên toàn bộ AI

    • Gemini đặc biệt có xu hướng nhầm chính đề xuất của nó thành đầu vào của người dùng
      Nếu không dọn dẹp context thì tình trạng còn nặng hơn
    • Thử với mô hình nhỏ sẽ thấy những vấn đề kiểu này xuất hiện thường xuyên hơn và rõ ràng hơn, nên khá hữu ích cho việc học
    • Sẽ rất hay nếu trong quá trình huấn luyện, mô hình được học cách phân biệt câu do chính nó sinh ra với câu do con người viết
      Nghe nói Anthropic đã triển khai một phần việc này
    • Nhìn các công ty thúc đẩy công cụ dựa trên LLM, tôi khá ngạc nhiên vì nhiều lập trình viên dường như không hiểu rõ kiểu hành vi nổi sinh (emergent behavior) này
    • Tác giả bài viết thường chỉ dùng các phiên ngắn nên trước giờ chưa gặp, nhưng trong Claude Code thì phiên kéo dài hơn nên vấn đề mới xuất hiện
  • LLM không hiểu tốt khái niệm phủ định (not)
    Con người xử lý phủ định bằng logic, nhưng trong không gian vector nhiều chiều của LLM thì tín hiệu “not” dễ bị pha loãng
    Với prompt ngắn thì còn ổn, nhưng câu càng dài thì càng dễ rối

    • Không rõ đã có chỉ số đánh giá hay kết quả thực nghiệm nào về chuyện này chưa
  • Có người hoài nghi về nhận định “dùng lâu thì sẽ dần có trực giác về lỗi của mô hình”
    Dựa vào trực giác với một hộp đen phi xác định là cách nghĩ nguy hiểm

    • Cũng có phản hồi đùa rằng chẳng lẽ lại không tin vào “cảm giác (vibes)”
      Nhưng nếu nâng phiên bản mô hình mới thì cảm giác đó cũng có thể sai ngay
    • Dù vậy, trên thực tế người ta không đem cả hệ thống vận hành ra đánh cược, mà dùng kinh nghiệm để điều chỉnh quyền hạn
      Nó giống như việc quyết định quyền truy cập cho thành viên trong nhóm
    • Cũng có ý kiến rằng “mọi phần mềm đều thế cả”
      Trong thực tế có vô số đoạn mã đang chạy, nên không thể có niềm tin tuyệt đối
  • bug của Claude Code CLI nên có người chuyển từ Claude Max sang Codex Pro
    Có quá nhiều vấn đề cơ bản như phát lại tin nhắn, nhầm nguồn gốc, và lỗi render
    Thật bất ngờ khi một công ty tạo ra mô hình Opus đột phá lại mắc lỗi ở một CLI đơn giản như vậy
    Có lẽ đó là hệ quả của việc thử nghiệm quá đà kiểu “top-down vibe coding”

  • Có người đặt nghi vấn với nhận định rằng “lỗi này khác với hallucination”
    Thuật ngữ harness đang được dùng quá rộng, và trên thực tế đây có thể chỉ là hallucination thông thường
    Vì LLM vốn là hệ thống khó đoán định, nên tin rằng chỉ nhờ kinh nghiệm mà có thể hiểu trọn vẹn hành vi của nó cũng là một ảo tưởng