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

 (arxiv.org)
4 điểm bởi GN⁺ 2025-05-16 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trong tình huống người dùng không thể viết đầy đủ yêu cầu ngay từ đầu, hiệu năng của 15 LLM với chỉ thị không hoàn chỉnh, nhiều lượt giảm mạnh so với chỉ thị hoàn chỉnh, một lượt: trung bình trên 6 tác vụ sinh nội dung giảm từ 90% xuống 65%
  • Thí nghiệm được thiết kế bằng phương pháp sharding: chia các chỉ thị benchmark một lượt hiện có thành nhiều mảnh, để điều kiện và ngữ cảnh được hé lộ dần khi hội thoại tiến triển
  • Sự suy giảm hiệu năng chịu ảnh hưởng lớn từ độ bất ổn tăng lên hơn là chỉ do thiếu năng lực; trong hơn 200.000 cuộc hội thoại, mô hình phụ thuộc quá mức vào các giả định ban đầu và các nỗ lực đưa ra câu trả lời cuối cùng quá sớm
  • Các mô hình được kiểm thử trải dài từ Llama3.1-8B-Instruct đến Gemini 2.5 Pro, đồng thời sử dụng cả các tác vụ lập trình và sinh ngôn ngữ tự nhiên như Code, Database, Actions, Math, Data-to-Text, Summary
  • Dù đây là mô phỏng đơn giản hóa các cuộc hội thoại người-AI thực tế, mọi cuộc hội thoại đều được thiết kế để kết thúc với đủ thông tin giải quyết tác vụ; vì vậy mức giảm quan sát được có thể nhỏ hơn so với hội thoại nhiều lượt không hoàn chỉnh trong thực tế

Khoảng cách giữa đánh giá một lượt và cách dùng hội thoại thực tế

  • LLM được dùng qua giao diện hội thoại như ChatGPT, Gemini, Claude; ngay cả khi người dùng chưa thể xác định đầy đủ yêu cầu từ đầu, họ vẫn có thể định nghĩa, khám phá và chỉnh sửa yêu cầu qua nhiều lượt
  • Các đánh giá LLM hiện có chủ yếu tập trung vào môi trường chỉ thị hoàn chỉnh, một lượt, nhưng trong log hội thoại LLM, tình trạng chỉ dẫn của người dùng không hoàn chỉnh xuất hiện rất phổ biến
  • Nhiều đánh giá nhiều lượt hiện nay gần với cách tiếp cận episodic, xem hội thoại như một chuỗi các tác vụ con có thể đánh giá độc lập
    • Tuy có yêu cầu một phần khả năng hiểu ngữ cảnh giữa các lượt, nhưng khác với tình huống phải chủ động kết hợp thông tin từ các chỉ dẫn người dùng chưa hoàn chỉnh
    • Những tác vụ như vậy có thể khiến hiệu năng LLM trong hội thoại nhiều lượt trông cao hơn thực tế

Hội thoại nhiều lượt không hoàn chỉnh được tạo bằng sharding

  • Thí nghiệm chuyển các chỉ thị hoàn chỉnh từ benchmark một lượt chất lượng cao thành sharded instruction
    • Shard đầu tiên trình bày ý định cấp cao của tác vụ
    • Các shard tiếp theo lần lượt cung cấp điều kiện hoặc ngữ cảnh bổ sung từ chỉ thị gốc
    • Khi ghép tất cả shard lại, chúng chứa cùng lượng thông tin như chỉ thị hoàn chỉnh ban đầu
  • Ví dụ, bài toán quả cầu tuyết trong GSM8K ở dạng đề một lượt cung cấp tất cả điều kiện như “tạo 20 cái mỗi giờ”, “ghi âm 2 cái mỗi 15 phút”, “cần tổng cộng 60 cái”, còn phiên bản sharded công bố các điều kiện này thành nhiều lượt
  • Quá trình sharding được thực hiện bán tự động: GPT-4o tạo và kiểm chứng ứng viên, sau đó nhà nghiên cứu xem xét và chỉnh sửa

Cấu trúc mô phỏng hội thoại

  • Mô phỏng nhiều lượt có ba chủ thể
    • assistant được đánh giá: LLM cần đo hiệu năng
    • user simulator: LLM biết toàn bộ sharded instruction và công bố shard tiếp theo ở mỗi lượt
    • system: thành phần phân loại phản hồi của assistant và đánh giá nỗ lực trả lời
  • Ở lượt đầu, user simulator chỉ công bố shard đầu tiên, còn assistant phản hồi bằng văn bản tự do
  • Phản hồi của assistant được phân loại vào một trong 7 chiến lược
    • clarification
    • refusal
    • hedging
    • interrogation
    • discussion
    • missing
    • answer attempt
  • Nếu được phân loại là answer attempt, answer extractor sẽ trích xuất phạm vi câu trả lời cần thiết để đánh giá, như đoạn mã, con số, SQL; sau đó evaluator theo từng tác vụ sẽ chấm điểm
  • Hội thoại kết thúc khi xảy ra một trong hai điều kiện
    • Nỗ lực trả lời của assistant được đánh giá là đúng
    • Không còn shard nào để công bố khi bắt đầu lượt mới
  • user simulator, strategy classifier và answer extractor được triển khai bằng GPT-4o-mini dựa trên prompt
  • Kết quả gán nhãn thủ công hàng trăm cuộc hội thoại cho thấy lỗi của user simulator, classifier và extractor xảy ra ở dưới 5% số hội thoại được kiểm tra; lỗi gây bất lợi cho mô hình assistant dưới 2%

Năm loại mô phỏng được so sánh

  • FULL là mô phỏng một lượt cung cấp chỉ thị hoàn chỉnh ban đầu ngay ở lượt đầu, được dùng làm đường cơ sở hiệu năng
  • SHARDED là hội thoại nhiều lượt, không hoàn chỉnh, trong đó các shard được công bố qua nhiều lượt; đây là môi trường đánh giá cốt lõi
  • CONCAT ghép các shard thành chỉ thị dạng bullet-point trong một lượt rồi cung cấp
    • Tính không hoàn chỉnh được loại bỏ như FULL
    • Cách diễn đạt lại sinh ra trong quá trình sharding được giữ lại như SHARDED
    • Nếu mô hình thành công ở FULL và CONCAT nhưng thất bại ở SHARDED, nguyên nhân có thể là bản thân tính nhiều lượt và không hoàn chỉnh, thay vì mất thông tin
  • RECAP sau hội thoại SHARDED sẽ trình bày lại toàn bộ shard một lần ở cuối để cho LLM cơ hội trả lời cuối cùng
  • SNOWBALL ở mỗi lượt nhắc lại shard mới cùng tất cả shard đã công bố đến thời điểm đó, cung cấp một bản tóm tắt tích lũy theo từng lượt

Tác vụ và benchmark được sử dụng

  • Thí nghiệm gồm 6 tác vụ sinh nội dung, bao gồm cả trường hợp sử dụng lập trình và sinh ngôn ngữ tự nhiên
  • Mỗi tác vụ chuẩn bị 90–120 sharded instruction, tổng cộng 600 instruction
  • Cấu trúc tác vụ:
    • Code: viết hàm Python dựa trên HumanEval, LiveCodeBench
    • Database: sinh text-to-SQL dựa trên Spider
    • Actions: sinh lời gọi hàm API dựa trên Berkeley Function Calling Leaderboard
    • Math: giải bài toán đố toán tiểu học dựa trên GSM8K
    • Data-to-Text: sinh câu mô tả dữ liệu bảng dựa trên ToTTo
    • Summary: tóm tắt và tạo trích dẫn cho một tập tài liệu dựa trên Summary of a Haystack
  • Các chỉ số đánh giá tái sử dụng chỉ số của benchmark gốc
    • Code và Database dùng độ chính xác dựa trên thực thi
    • Actions và Math dùng tương đương ngữ nghĩa với đáp án tham chiếu hoặc đáp án số
    • Data-to-Text dùng BLEU
    • Summary dùng “Joint Score” theo kiểu LLM-as-a-judge, đo độ bao phủ thông tin và độ chính xác khi gán nguồn
  • Độ chính xác nhị phân cũng được ánh xạ về thang 0–100 để tổng hợp điểm của mọi tác vụ trên cùng một thang đo

Đo hiệu năng, năng lực và độ bất ổn

  • Vì đầu ra LLM có tính xác suất, cùng một instruction và loại mô phỏng được chạy lặp lại N=10 lần
  • Mỗi lần chạy được đánh giá bằng điểm trong khoảng 0–100
  • Ba chỉ số được sử dụng
    • Hiệu năng trung bình P: trung bình điểm của các lần chạy lặp lại
    • aptitude A90: phân vị thứ 90 của điểm số, ước tính hiệu năng best-case trong 10% lần chạy tốt nhất
    • unreliability U90-10: chênh lệch giữa phân vị thứ 90 và phân vị thứ 10, đo khoảng cách giữa best-case và worst-case
  • Ở một lượt, các mô hình có aptitude cao có xu hướng đáng tin cậy hơn, nhưng ở nhiều lượt, unreliability cao xuất hiện ở mọi LLM bất kể aptitude

Kết quả thí nghiệm quy mô lớn

  • Thí nghiệm chính được thực hiện trên 600 instruction, 3 loại mô phỏng (FULL, CONCAT, SHARDED) và 15 LLM
  • Mỗi tổ hợp được lặp lại 10 lần, mô phỏng hơn 200.000 cuộc hội thoại
  • Mọi mô phỏng được thực hiện với temperature mặc định T=1; ảnh hưởng của temperature lên aptitude và reliability được xử lý trong thí nghiệm phụ riêng
  • Nhìn chung, hiệu năng trung bình của hội thoại nhiều lượt không hoàn chỉnh là 65%, thấp hơn 25 điểm so với hiệu năng một lượt 90% khi nhận toàn bộ chỉ thị ngay từ đầu
  • Hiện tượng suy giảm hiệu năng nhiều lượt xuất hiện phổ biến từ các mô hình open-weight nhỏ đến các mô hình mới nhất
    • Đối tượng kiểm thử bao gồm các mô hình open-weight nhỏ như Llama3.1-8B-Instruct và các mô hình mới nhất như Gemini 2.5 Pro
    • Figure 1 hiển thị ví dụ gồm Claude 3.7 Sonnet, Deepseek-R1, o3, GPT-4.1, Gemini 2.5 Pro
  • Mức giảm hiệu năng trung bình trên 6 tác vụ sinh nội dung là 39%, và Figure 1 cho thấy mức suy giảm hiệu năng khoảng -35% trong thiết lập nhiều lượt

Vì sao mô hình bị lạc hướng

  • Sự suy giảm hiệu năng được tách thành hai yếu tố
    • aptitude giảm: bản thân hiệu năng best-case giảm một phần
    • unreliability tăng: chênh lệch chất lượng giữa các lần chạy tăng mạnh
  • Theo Figure 1, trong bối cảnh nhiều lượt, aptitude giảm -15% và unreliability tăng +112%
  • Mô hình có xu hướng nhìn vào thông tin ban đầu chưa hoàn chỉnh rồi tạo ra giả định sai, đồng thời cố đưa ra câu trả lời cuối cùng quá sớm ở giai đoạn đầu hội thoại
  • Ngay cả khi thông tin mới được cung cấp sau đó, mô hình vẫn phụ thuộc quá mức vào nỗ lực trả lời sai trước đó và không thể điều chỉnh hướng đi
  • Hiện tượng một khi đi sai hướng trong hội thoại nhiều lượt không hoàn chỉnh thì không thể phục hồi được định nghĩa là lost in conversation

Giới hạn và hàm ý thực tiễn

  • Mô phỏng hoàn toàn tự động không đại diện nguyên vẹn cho hội thoại người-AI thực tế
  • Môi trường thí nghiệm đã được đơn giản hóa và lý tưởng hóa
    • Hội thoại được bảo đảm kết thúc với đủ thông tin để giải tác vụ
    • Các hành vi bất ngờ có thể xảy ra trong môi trường thực tế, như hội thoại đi chệch hướng, bị hạn chế
  • Do thiết kế này, mức suy giảm hiệu năng quan sát được có thể là đánh giá thấp so với suy giảm xảy ra trong các hội thoại người-AI nhiều lượt không hoàn chỉnh thực tế
  • Các tổ chức xây dựng sản phẩm hội thoại dựa trên LLM và người dùng cuối nên đánh giá độ tin cậy nhiều lượt cùng với năng lực một lượt
  • Với người dùng mới, những người khó viết yêu cầu không hoàn chỉnh thành yêu cầu đầy đủ ngay từ đầu, suy giảm hiệu năng nhiều lượt có thể là nguyên nhân làm giảm mức độ phổ biến của hệ thống AI

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-05-16
Các ý kiến trên Hacker News

  • Với những ai từng dùng công cụ LLM, thật đáng mừng khi một bài báo xác nhận điều mà ta đã biết theo kinh nghiệm. Việc duy trì ngữ cảnh sạch là quan trọng, còn “cuộc hội thoại” chỉ là một cấu trúc do giao diện sản phẩm tạo ra và gây hại cho chất lượng phản hồi của chính LLM. Một khi ngữ cảnh đã bị nhiễm bẩn thì không khôi phục được, nên phải bắt đầu lại bằng một cuộc chat mới

    • Trải nghiệm của tôi phần nào khớp với quan sát này, nhưng cũng có trường hợp khác. Tôi đã debug một vấn đề IPSEC bằng Gemini trong 2 tuần: ban đầu tôi đưa vào toàn bộ tài liệu IPSEC của OPNsense và pfSense, cho biết bối cảnh công việc, rồi thêm cấu hình của cả hai phía sau khi loại bỏ thông tin nhạy cảm. Sau đó tôi chạy một vòng phản hồi dài: tải log lên, đặt câu hỏi và nhận câu trả lời
      Đến cuối 2 tuần, LLM đã bớt lan man hơn nhiều; ngay cả khi tôi đưa vào cả một thread diễn đàn hay bài Stack Overflow, nó vẫn phân biệt được rằng “đây không phải hiện tượng đang thấy ở đây, vì [ngữ cảnh hoặc phát hiện trước đó]”. Những ngõ cụt thì tôi vẫn phải loại trừ bằng lập luận và báo lại cho nó, nhưng cuối cùng đã tìm ra nguyên nhân
      Điều này có vẻ cũng khớp với nhận định rằng LLM mạnh ở việc nén thông tin phức tạp thành đơn giản, và yếu ở việc mở rộng một ý tưởng đơn giản thành thứ phức tạp. Khi đầu vào lớn hơn hoặc phức tạp hơn đầu ra, kết quả khá thỏa mãn
      Không có LLM thì tôi vẫn làm được, nhưng nó hữu ích như một kho lưu trữ khi tôi quên các dữ kiện đã đưa vào từ đầu hoặc không kịp nhớ ra trong ngữ cảnh mới, và cũng hữu ích để tìm các mẫu thời gian trong những file log lớn. Tôi không chỉ sửa một vấn đề mà còn tối ưu nhiều cấu hình và học được khá nhiều. Thỉnh thoảng nó sai về trạng thái tham số hiện tại, nhưng dễ sửa. Nếu biết mình đang đi đâu và dùng nó như một công cụ thì nó có ích, nhưng không nên giao quyền quyết định cho nó hoặc để nó kéo mình đi sai hướng
      Tổng mức sử dụng vào khoảng 350k token. Bài blog liên quan ở https://du.nkel.dev/blog/2021-11-19_pfsense_opnsense_ipsec_cgnat/, dù không trùng trực tiếp với vấn đề cụ thể này. Xin miễn đề xuất WireGuard
    • Hoàn toàn khớp với trải nghiệm của tôi. Cách nói “nhiễm bẩn” rất hay. Một khi có gì đó sai, cảm giác như mọi phản hồi sau đó đều tệ đi, nên tôi cũng thấy tính năng Memory của ChatGPT hơi lửng lơ. Tôi không cảm thấy nó gây vấn đề lớn, nhưng không thích việc nó làm bẩn ngữ cảnh theo cách mà tôi không hiểu hết
    • Từ lâu tôi đã nói rằng ước gì có thể fork cuộc hội thoại. Tôi muốn thử nghiệm xem trao đổi sẽ đi theo hướng nào mà không làm nhiễm bẩn không thể quay lại một mạch đang hứa hẹn. ChatGPT không làm được, và tôi tò mò liệu có nơi nào cung cấp tính năng này không
    • Mẹo số một tôi dạy là hãy tích cực dùng nút “edit” rất nhỏ và gần như bị giấu trong ChatGPT và Claude. Nếu nhận được phản hồi tệ, đừng tiếp tục chồng lên nó; hãy dừng lại, chỉnh sửa để có phản hồi tốt hơn, để rác không sinh thêm rác
    • Một ví dụ nhỏ thú vị của vấn đề này là prompt ban đầu. Vì trên thực tế nó là một ngữ cảnh vĩnh viễn, ẩn và gần như không thể xóa. Hiện bot “Grok” của Twitter gần đây bắt đầu thường xuyên nhắc đến “White Genocide”, khá kỳ lạ
      Rất có thể gần đây ai đó đã chỉnh prompt để chỉ định quan điểm về diệt chủng người da trắng, và với một chatbot hoàn hảo thì điều đó sẽ không quan trọng khi hỏi về chủ đề khác, nhưng trong thực tế thì có. Vì nó là một phần của ngữ cảnh, nên giờ nó bắt đầu nói về chuyện đó

  • Điều này trông giống một khía cạnh của sự quá tự tin đã biết rõ và việc không có khả năng tự phản tỉnh. Nếu xác suất tiên nghiệm quá thấp, nó không nhận ra rằng cần yêu cầu thêm thông tin chi tiết. Nhìn vào đầu ra của các mô hình suy luận, gần như không thấy ý định đặt câu hỏi làm rõ; khi bối rối, chúng chỉ đoán vô tận xem người dùng muốn nói gì
    Điều này cũng có hàm ý đối với sự khôn ngoan của ý tưởng “thay thế lập trình viên con người”. Vì một trong những phần khó của nghề này là tương tác với các bên liên quan và biến những ý tưởng mơ hồ, thường rối rắm, thành đặc tả chính xác

    • Về “không có khả năng tự phản tỉnh”, tôi nghĩ mẹo cốt lõi khi xử lý LLM là nhận ra rằng không có chủ thể thực sự nào cả, và người dùng đang bị cuốn vào câu chuyện tạm gác hoài nghi
      Trong phần lớn trường hợp, người dùng đang viết lời thoại cho nhân vật User trong một tài liệu kịch bản phim, còn thuật toán LLM chỉ định kỳ tự động hoàn thành lời thoại còn dang dở của nhân vật Chatbot
      Bạn có thể phỏng vấn một ma cà rồng tên DraculaBot, nhưng nhân vật đó chỉ có thể “tự phản tỉnh” theo cách nông cạn và hư cấu như “thèm máu” hay “biến thành đàn dơi”
    • Việc LLM không đặt được câu hỏi làm rõ chính là thiếu sót tôi gặp khi kiểm thử các bài toán mở được mô tả mơ hồ. Đó là trong bối cảnh thử các tình huống nghịch lý với DeepSeek-R1 và Claude-3.7-Sonnet; bài viết thí nghiệm ở https://pankajpansari.github.io/posts/paradoxes/
    • Lập trình viên thực sự dành rất nhiều thời gian để tìm hiểu mọi người thật sự muốn gì. LLM vẫn coi phỏng đoán như một tính năng
    • Đọc điều này khiến tôi có cảm giác như đang xem những người thông minh bị một Emacs doctor tốt hơn đánh lừa. LLM không tự suy ngẫm, cũng chẳng tự tin. Nó “chỉ” đang đề xuất tự động hoàn thành văn bản
      Vì vậy khi phần tự động hoàn thành bắt đầu tệ đi, bạn phải bắt đầu lại. Không có khái niệm nào cả, chỉ có khối khổng lồ gồm các từ mà văn bản huấn luyện đã cho thấy và những đoạn văn bản tiếp theo có khả năng xảy ra
    • Liên quan đến ý tưởng “thay thế lập trình viên con người”, trớ trêu là làm việc với lập trình viên junior cũng khá giống thế này. Giao việc xong, rồi sau đó phải cầm chó và đèn pin vào sâu trong rừng để đi tìm họ. Vì họ cứ tiến bừa, giả định, không hỏi, rồi lạc đường

  • Tôi thường yêu cầu LLM tạo một bản tóm tắt ngắn gọn theo dạng prompt của những gì đã thảo luận đến giờ. Chỉnh sửa nó cho phù hợp rồi dùng để bắt đầu một cuộc hội thoại mới không mang hành lý cũ, cách này rất hiệu quả. Có lẽ chẳng bao lâu nữa sẽ được tự động hóa

    • Cursor đã thử tự động làm việc này. Nếu không dùng các mô hình ngữ cảnh lớn như Gemini 2.5 Pro thì có lẽ vẫn có thể như vậy. Nhưng bản tóm tắt bỏ sót quá nhiều chi tiết nên khó dùng nguyên trạng
    • Claude Code có lệnh /compact để tóm tắt cuộc hội thoại đến thời điểm hiện tại nhằm tiết kiệm token ngữ cảnh

  • Vì vậy họ đã tạo TSCE (Two-Step Contextual Enrichment). Khi thử nghiệm bằng GPT-35-turbo với 300 tác vụ được trộn lẫn, kết quả cải thiện +30 điểm phần trăm
    Đây là framework mã nguồn mở miễn phí và có thể thử trực tiếp trong kho lưu trữ: https://github.com/AutomationOptimization/tsce_demo
    Họ cũng thử nghiệm lại 300 lần trên gpt-4.1 với tác vụ loại bỏ dấu “em-dash” nổi bật mà mọi người ghét. So sánh baseline một lượt với TSCE bằng cùng chỉ dẫn và prompt “Remove the em-dashes from my linkedin post. . .”
    Trong 300 lần, baseline thất bại 149/300 lần trong việc loại bỏ em-dash, còn TSCE thất bại 18/300 lần. Nó hoạt động, và toàn bộ dữ liệu cùng script kiểm thử đều có trong kho lưu trữ

    • Có vẻ như đã lãng phí quá nhiều kilowatt-giờ cho một tác vụ tìm-thay thế. Không biết họ đã nghe đến text.replace("—", "-") chưa
    • Chỉ cần chỉnh nhẹ ví dụ baseline về em dash, GPT-4.1 đã đạt tỷ lệ thành công 100% mà không cần thêm lượt gọi, chi phí token hay khoe mẽ kỹ thuật
      System prompt: "Remove every em-dash (—) from the following text while leaving other characters unchanged.\n\nReturn only the cleaned text."
      User prompt:
      Temperature: 0.0

  • Tôi đang làm khá thành công một giải pháp cho vấn đề này và sẽ sớm chia sẻ thêm. Có 2 hệ thống: hệ thống đầu tiên là chính LLM, hệ thống còn lại hoạt động như một kiểu người tuyển chọn suy nghĩ
    Nó động thêm vào và lấy ra một phần ngữ cảnh, không dựa trên định nghĩa tường minh mà dựa vào khả năng “lấp chỗ trống” của LLM. Hệ thống này giúp LLM phân rã vấn đề thành các tác vụ nhỏ, rồi các tác vụ nhỏ đó cuối cùng được tổng hợp thành toàn bộ tác vụ

    • Ý tưởng hay. Về cơ bản là tạo sinh tăng cường truy xuất (RAG) đặt trên chat
      Có lẽ trong tương lai sự phân tách các tầng bộ nhớ kiểu này sẽ rõ ràng hơn. Có thể chia thành bộ nhớ bậc một là dữ liệu huấn luyện, bộ nhớ bậc hai là ngữ cảnh, và bộ nhớ bậc ba là RAG
    • Nghe như một ý tưởng thú vị. Dù hiện tại chỉ mới ở mức vài prompt, tôi vẫn khuyên nên công bố những gì bạn có cho mọi người. Người khác có thể xem và cải thiện; nếu đó là ý tưởng hay, nó sẽ được tiếp nhận, được người khác phát triển và thậm chí có đời sống riêng
    • Cái này thuộc loại nhà phê bình tinh thần trong Emotion Machine
    • Vậy là Map-Reduce-of-Thought à?

  • Thật ngạc nhiên khi phân nhánh/fork không phải là tính năng cốt lõi trong các công cụ chat chính. Có thể chỉnh sửa phản hồi, nhưng làm vậy thì nhiều ngữ cảnh khác biến mất
    Luồng của tôi đại khái là 1) lập kế hoạch 2) triển khai 3) phân nhánh (vì tính năng hoặc vấn đề phụ thuộc kỳ lạ) 4) quay lại bước 2. Cắt tỉa prompt và phân nhánh nên là công cụ hạng nhất trong bất kỳ cách dùng LLM nào

    • Google AI Studio ít nhất có tính năng này. Tuy nhiên cách triển khai của nó khá khó hiểu, và đó có thể là lý do nó chưa xuất hiện nhiều trong các công cụ “hướng người tiêu dùng” hơn
    • Tôi từng cân nhắc làm một thứ như vậy một thời gian. BetterChatGPT ít nhất có trải nghiệm xóa lịch sử khá ổn. Nhưng tôi đồng ý rằng bước tiếp theo là phân nhánh

  • Có một vấn đề dễ thấy khi xây dựng giao diện LLM xoay quanh hội thoại một lượt. Phần lớn mọi người kỳ vọng hội thoại tuyến tính
    Tôi đã tạo bot Telegram http://t.me/experai_bot như một UI đa dụng cho LLM, với tính năng được giảm bớt phần nào và thiết kế xoay quanh ý tưởng “tin nhắn không phải trả lời là cuộc trò chuyện mới”. Nếu muốn giữ ngữ cảnh, chỉ cần tiếp tục trả lời vào câu trả lời của bot. Những người không phải người dùng nâng cao thấy ý tưởng này khó hiểu
    Tôi cũng từng thấy khi mô hình OpenAI trả lời cùng một câu hỏi, chỉ cần có một system message rất nhỏ cũng làm hiệu năng tệ hơn. Ví dụ danh sách lựa chọn trong câu trả lời ngắn hơn. Điều này xảy ra với 3.5 và 4o, còn các mô hình mới nhất thì tôi không biết. Vì vậy mặc định tôi quyết định không thêm system message. Dù vậy nếu cần vẫn có thể thêm, cũng có thể bật tắt và kết hợp chúng

  • Cảm giác hiện nay mảng LLM đầy những người cứ giải đi giải lại cùng một vấn đề

    • Trong một số workflow thì ổn, nhưng cái này giống chăn mèo hơn là “học”
    • Ai cũng muốn góp thêm phần prompt engineering xuất sắc của riêng mình

  • Đây là lý do chính khiến tôi tạo promptdown. Tôi muốn có thể chỉnh sửa toàn bộ lịch sử chat ở mỗi lượt, và điều đó không dễ trong giao diện chat tiêu chuẩn chỉ cho phép thêm vào
    https://github.com/t-kalinowski/promptdown

  • Tôi luôn cảm thấy sự chế giễu dành cho thuật ngữ “prompt engineering” một phần xuất phát từ việc mọi người đánh giá quá cao tầm quan trọng của prompt ban đầu và đánh giá quá thấp tầm quan trọng của việc quản lý ngữ cảnh trong quá trình trò chuyện
    Qua kinh nghiệm, bạn sẽ có cảm giác về cách điều khiển mô hình và khi nào nên bắt đầu cuộc trò chuyện mới. System prompt hay prompt ban đầu cũng quan trọng, nhưng nếu ngây thơ kéo cuộc trò chuyện quá dài thì chúng cũng chẳng cứu được gì

    • Đúng vậy. Prompt engineering không chỉ là tạo ra câu đầu tiên hoàn hảo, mà gần với quản lý hội thoại hơn. Bạn sẽ dần có cảm giác khi nào luồng bắt đầu lệch hướng và khi nào cần khởi tạo lại