- Chatbot hội thoại dài hạn, ngay cả khi có cửa sổ ngữ cảnh dài, vẫn khó phản ánh ổn định các điểm cốt lõi của những tương tác trong quá khứ vào câu trả lời; nghiên cứu này bàn về cách giảm vấn đề nhất quán bằng bộ nhớ tóm tắt đệ quy
- Quy trình cốt lõi là tạo bộ nhớ ban đầu từ một đoạn hội thoại ngắn, sau đó mỗi khi có thêm phiên mới thì tóm tắt chung bộ nhớ trước đó và hội thoại mới để cập nhật thành bộ nhớ mới nhất
- Phương pháp dựa trên truy xuất phụ thuộc vào bộ truy xuất để tìm chính xác phát ngôn quá khứ cần thiết, còn phương pháp dựa trên bộ nhớ hiện có có thể khiến chất lượng phản hồi dao động do thông tin cũ chưa được cập nhật
- Trong các thử nghiệm với LLM công khai và không công khai như Llama, ChatGLM, OpenAI GPT-3.5-Turbo, cả đánh giá tự động lẫn đánh giá của con người đều cho thấy tính nhất quán trong hội thoại dài hạn cao hơn các cách tiếp cận hiện có
- Phương pháp này cũng có thể dùng cùng cửa sổ ngữ cảnh dài hoặc LLM tăng cường truy xuất, nên có thể trở thành một lựa chọn thực tiễn để xử lý ngữ cảnh hội thoại rất dài mà không cần tăng vô tội vạ độ dài toàn bộ hội thoại
Chỉ ngữ cảnh dài là chưa đủ cho trí nhớ hội thoại dài hạn
- Các LLM như GPT-4, ChatGPT có thể thực hiện hội thoại linh hoạt và phù hợp ngữ cảnh trên nhiều chủ đề, nhưng trong hội thoại dài hạn chúng có thể bỏ sót thông tin quá khứ và tạo ra phản hồi thiếu nhất quán
- Dù cửa sổ ngữ cảnh dài cho phép xử lý toàn bộ lịch sử hội thoại làm đầu vào, khả năng hiểu các tương tác trong quá khứ và tích hợp thông tin cốt lõi vào câu trả lời vẫn còn hạn chế
- Các trường hợp tiêu biểu cần nhớ hội thoại quá khứ là bạn đồng hành AI cá nhân và dịch vụ hỗ trợ sức khỏe
- Bạn đồng hành AI cá nhân cần gợi nhớ các cuộc trò chuyện trước đó để hình thành mối quan hệ
- Dịch vụ hỗ trợ sức khỏe phải xem xét toàn bộ lịch sử hỏi đáp của bệnh nhân để đưa ra kết quả chẩn đoán
- Trong ví dụ của Multi-Session Chat Dataset, khi người dùng nhắc lại chủ đề “sáng tác nhạc” sau khoảng 20 lượt, phiên bản ChatGPT gpt-turbo-3.5-0301 đã trả lời rằng mình là “một mô hình ngôn ngữ AI không có nghề nghiệp theo nghĩa truyền thống”, tạo ra phản hồi không nhất quán với persona trước đó
Giới hạn của cách tiếp cận dựa trên truy xuất và dựa trên bộ nhớ
- Các cách tiếp cận tiêu biểu để tăng cường năng lực hội thoại dài hạn được chia thành phương pháp dựa trên truy xuất và phương pháp dựa trên bộ nhớ
- Phương pháp dựa trên truy xuất lưu các phát ngôn quá khứ trong kho lưu trữ, rồi dùng bộ truy xuất tìm lịch sử liên quan nhất với hội thoại hiện tại để phục vụ việc tạo phản hồi
- Hạn chế là khó có được một bộ truy xuất lý tưởng có thể nắm bắt đầy đủ ý nghĩa cần thiết cho hội thoại hiện tại
- Phương pháp dựa trên bộ nhớ lưu thông tin cốt lõi bằng cách tóm tắt hội thoại quá khứ thông qua một mô hình học riêng hoặc LLM mạnh
- Nếu thiếu cơ chế cập nhật lặp lại, thông tin cũ được giữ lại có thể trực tiếp làm hại chất lượng phản hồi
- MemoChat tái cấu trúc lịch sử hội thoại quá khứ theo từng chủ đề của người nói, và prompt LLM truy xuất từ bộ nhớ có cấu trúc khi sinh phản hồi
- MemoryBank đề xuất một cơ chế bộ nhớ: trước tiên tạo tóm tắt cho từng phiên hội thoại, rồi nén chúng thành tóm tắt toàn cục
- Nếu bộ nhớ đã lưu hoàn toàn cố định, sẽ khó bảo đảm tính nhất quán với hội thoại đang diễn ra
Tạo bộ nhớ được cập nhật đệ quy
- Phương pháp được đề xuất là một cách dạng plugin đơn giản, trong đó chính LLM tạo tóm tắt và liên tục cập nhật, rà soát ngữ cảnh quá khứ để lưu thông tin thời gian thực của người nói
- Quy trình gồm ba bước
- LLM sinh nhận ngữ cảnh hội thoại ngắn làm đầu vào và tạo tóm tắt ban đầu
- Sau đó kết hợp bộ nhớ trước đó với hội thoại tiếp theo để liên tục cập nhật tóm tắt hoặc bộ nhớ mới
- Chatbot dùng bộ nhớ mới nhất làm tham chiếu chính để trả lời hội thoại hiện tại
- Vì tóm tắt được tạo ra ngắn hơn rất nhiều so với toàn bộ hội thoại, có thể xử lý ngữ cảnh rất dài qua nhiều phiên mà không cần tăng tốn kém độ dài đầu vào tối đa
- Hội thoại dài hạn được định nghĩa là Multi-Session Dialogue gồm nhiều phiên
- Sử dụng tập phiên quá khứ
S = {S1, S2, ..., SN}, ngữ cảnh hội thoại của phiên hiện tạiCt, và phản hồi đúngrt - Mục tiêu là tạo phản hồi liên quan và nhất quán cao dựa trên các phiên quá khứ và ngữ cảnh hiện tại
- Sử dụng tập phiên quá khứ
- Bộ nhớ
Milà bộ nhớ có thể dùng tại thời điểm kết thúc phiên thứ i, và toàn bộ quá trình được định nghĩa là một quy trình tuần tự trong đó mỗi bộ nhớ chỉ phụ thuộc vào phiên hiện tại và bộ nhớ trước đó
Lặp bộ nhớ và tạo phản hồi
- Phương pháp đề xuất giao hai tác vụ cho một LLM bất kỳ
- Lặp bộ nhớ: tóm tắt đệ quy các thông tin cốt lõi theo dòng hội thoại dài hạn
- Tạo phản hồi dựa trên bộ nhớ: kết hợp bộ nhớ mới nhất với hội thoại hiện tại để tạo phản hồi phù hợp và nhất quán
- Lặp bộ nhớ là quá trình thu được bản tóm tắt nhất quán và cập nhật để chatbot sử dụng
- Một số nghiên cứu hiện có cập nhật bộ nhớ bằng cách áp dụng các “phép toán cứng” như replace, append, delete lên bản tóm tắt
- Cách này phụ thuộc vào hội thoại chất lượng cao có gắn nhãn thao tác, cản trở tính nhất quán ngữ nghĩa của tóm tắt và cũng không phù hợp để quản lý dài hạn
- Phương pháp đề xuất đưa cả ngữ cảnh hội thoại và bộ nhớ trước đó vào để LLM tạo bộ nhớ hoặc tóm tắt theo cách đệ quy
- Khi tận dụng tóm tắt trước đó, mô hình có thể tiêu hóa ngữ cảnh hội thoại hiện tại tốt hơn và tạo bộ nhớ chất lượng cao
- Trong ví dụ, sau phiên đầu tiên bộ nhớ ban đầu được tạo ra; sau phiên thứ hai, thông tin tính cách mới rằng “bot gần đây đã đăng ký một phòng gym mới hoạt động 24 giờ” được tích hợp vào bộ nhớ trước đó
Kết quả thử nghiệm và khả năng áp dụng
- Thử nghiệm được triển khai bằng các LLM công khai và không công khai mới nhất như Llama, ChatGLM, OpenAI GPT-3.5-Turbo
- Hiệu năng hội thoại dài hạn cao hơn các cách tiếp cận phổ biến hiện có trong cả đánh giá tự động lẫn đánh giá của con người
- Nghiên cứu kiểm chứng hiệu quả của việc dùng bộ nhớ tường minh cho hội thoại dài hạn, cũng như việc bộ nhớ do phương pháp đề xuất tạo ra dễ được LLM tiêu hóa hơn
- Khi kết hợp học trong ngữ cảnh (ICL), chất lượng phản hồi có thể được cải thiện thêm
- Trình bày cho LLM nhiều mẫu theo định dạng
(hội thoại, bộ nhớ, phản hồi đúng) - Giúp LLM tận dụng bộ nhớ đã tạo một cách linh hoạt hơn
- Trình bày cho LLM nhiều mẫu theo định dạng
- Với text-davinci-003, điểm BLEU được cải thiện khoảng +3%
- Phương pháp đề xuất bổ trợ cho các LLM có cửa sổ ngữ cảnh dài như GPT-3.5-Turbo-16k, LongLoRA-8k, cũng như các LLM tăng cường truy xuất như LLM-BM25, LLM-DPR
- Mã nguồn công khai được cung cấp tại qingyue2014/Rsum
1 bình luận
Ý kiến trên Hacker News
Mọi cách xây dựng bộ nhớ trong “không gian văn bản” đều cho cảm giác khá hacky
Để bảo toàn trọn vẹn ý nghĩa của mô hình, việc lưu vào không gian embedding dày đặc có vẻ tự nhiên hơn so với một quy trình chắp vá liên tục tái tạo bản tóm tắt
Ngoài ra, mô hình cần được huấn luyện để nhận biết và tận dụng bộ nhớ, và nếu có thể thì tốt nhất là được học trong thiết lập như vậy ngay từ đầu
Rốt cuộc là ta yêu cầu nó gắn thêm một từ tiếp theo vào cuộc hội thoại đã cho, và đến một lúc nào đó khi nó phát ra token kết thúc thì ứng dụng lại trao quyền điều khiển về cho người dùng
Tôi nghĩ không gian tiềm ẩn và không gian văn bản không xa nhau như ta tưởng. LLM khá vụng về nhưng rất giỏi nói năng, và viết code cũng tương tự nên nó làm tốt, nhưng lại sụp đổ ở những lĩnh vực cần tư duy trừu tượng thực sự như toán học
Những kiểu hack không gian văn bản này thực tế thường khá hiệu quả, và đó cũng là lý do các prompt như “hãy suy nghĩ từng bước” trở nên phổ biến
LoRA gần với hướng bạn nói hơn, và rất tuyệt trong việc nén nhiều hiểu biết vào rất ít dữ liệu. Tuy nhiên, việc điều chỉnh trọng số cho một cuộc hội thoại đơn lẻ hiện vẫn chưa thực tế, nên với mục đích đó chúng ta đang khám phá không gian văn bản
Việc tóm tắt điều gì đó trong đầu có thể cảm thấy “hacky”, nhưng tôi nghĩ một phần lớn cách trí nhớ vận hành trên thực tế cũng tương tự như vậy
https://news.northwestern.edu/stories/2012/09/your-memory-is...
Theo tôi hiểu, embedding về bản chất gần với nén mất dữ liệu. Còn với tóm tắt văn bản, ít nhất agent có thể kiểm chứng liệu bản tóm tắt đó có đại diện chính xác cho thông tin gốc hay không
Ở CodeRabbit, chúng tôi đã dùng cách này cho review PR tăng dần và các cuộc hội thoại trong ngữ cảnh thay đổi code
Nó khiến bot trông như có nhiều ngữ cảnh hơn thực tế rất nhiều, và là một trong vài mẹo chúng tôi dùng để mở rộng review code bằng AI đến cả các PR lớn (hơn 100 file)
Với mỗi commit, chúng tôi tóm tắt diff theo từng file, rồi lại tạo bản tóm tắt của các bản tóm tắt, và cập nhật tăng dần mỗi khi có commit được thêm vào PR. Bản tóm tắt của các bản tóm tắt này được lưu ẩn trong phần bình luận PR, và được dùng khi review từng file hoặc trả lời câu hỏi của người dùng
Một phần code là mã nguồn mở, và prompt liên quan dùng cho tóm tắt đệ quy nằm ở đây: https://github.com/coderabbitai/ai-pr-reviewer/blob/main/src...
[0]: coderabbit.ai
Nếu có, tôi cũng tò mò liệu bạn đã thử dùng function calling thay vì parse đầu ra văn bản tự do chưa
Nếu còn ở giai đoạn “code và script sẽ được công bố sau”, thì giờ khó mà tin bất kỳ tuyên bố nào
Có thể là thật, cũng có thể là nhảm nhí, nhưng nếu không có cách tái hiện thí nghiệm với chi phí thấp thì tôi xem những bài báo như vậy là thứ tác giả viết để đưa vào CV
Tôi đã chờ hơn 6 tháng các bài báo trong lĩnh vực LLM nói “code sẽ được công bố sau”, nhưng chẳng thấy dấu hiệu nào là sẽ thật sự công bố. Thậm chí một số bài còn trơ tráo đến mức đưa cả liên kết hỏng dẫn tới domain đỗ xe
Đã đến lúc cộng đồng cần nhìn nhận nghiêm túc thông lệ không công bố code như thế này
Trước đây tôi từng thử nghiệm một ý tưởng tương tự chỉ bằng cách tự chỉnh prompt trên dashboard API; có tiềm năng nhưng dường như không đáng với chi phí API. Có lẽ phương pháp vector embedding sẽ tốt hơn nhiều
Một ví dụ cá nhân: ở công ty có hàng nghìn “Briefings”, tức các panel ngoại tuyến kéo dài một giờ, đôi khi cả ngày
Chúng tôi đã tóm tắt thành công từng briefing, và các bản ghi âm được chép lại khá lộn xộn đã được tổ chức tốt thành bản tóm tắt năm đoạn
Phần liên quan hơn là chúng tôi đã phân loại từng briefing theo chủ đề và chủ đề con theo quan hệ 1:N. Mỗi chủ đề gom hàng chục briefing, mỗi chủ đề con gom khoảng hơn chục briefing, rồi chúng tôi lại tóm tắt các tập con của những bản tóm tắt liên quan và kiểm thử rộng rãi; kết quả với LLM rất tốt
Ban đầu tôi hoài nghi liệu cách này có hiệu quả không, nhưng nó hoạt động rất tốt. Nếu có cửa sổ ngữ cảnh đủ lớn thì tôi đã không làm vậy, nhưng may là nó không thành vấn đề
Tôi nghĩ chia vấn đề theo kiểu MapReduce sẽ hiệu quả hơn nhiều so với nhét tất cả vào một cửa sổ ngữ cảnh khổng lồ 32k rồi bắt nó giải một lần
Vài tháng trước tôi từng thử tạo bộ nhớ tóm tắt đệ quy bằng một mô hình mã nguồn mở, và nếu triển khai một cách ngây thơ thì nó rất hay bị mắc kẹt mãi trong một chủ đề nhất định
Vì có những mảnh thông tin sống sót qua mọi vòng tóm tắt
Không thể thu nhỏ bất kỳ khối văn bản nào thành một khối văn bản nhỏ hơn mà không mất chút thông tin nào
Nếu điều đó khả thi thì nghĩa là có thể nén vô hạn, và bất kỳ dataset nào cũng phải có thể rút xuống 1 bit rồi khôi phục hoàn hảo. Nhưng không thể làm vậy
Khi nén cuộc hội thoại thành bản tóm tắt, chắc chắn một phần thông tin sẽ biến mất. Dù có tinh chỉnh, gấp gọn hay dùng cách thông minh đến đâu, về bản chất vẫn xảy ra mất mát thông tin
Hơn nữa quá trình này là đệ quy, nên đến một lúc nào đó sẽ lại tóm tắt một tập các bản tóm tắt, và khi đó cũng mất đi một lượng thông tin nhất định
Vì vậy trong các trường hợp vụn vặt thì có thể hữu ích, nhưng đưa tóm tắt đệ quy vào prompt là khá ngớ ngẩn, và nếu bắt nó làm việc thực sự hữu ích thì gần như chắc chắn sẽ không hoạt động đúng. Khi không dùng tóm tắt đệ quy nhiều thì nó trông có vẻ hoạt động vì mất ít thông tin, nhưng nếu dùng thật thì rất có khả năng sẽ nhanh chóng lộ giới hạn
Chỉ riêng sang chấn hay quá trình phát triển cũng đủ cho thấy tâm trí con người dễ chệch quỹ đạo đến mức nào, nên ý tưởng về AI giống con người nghe có vẻ đầy hy vọng đến đâu
Bài báo hơi gây thất vọng. Hầu như không có chi tiết gì về kỹ thuật, chỉ có các bảng nói rằng phương pháp họ dùng cho kết quả tốt
Tôi biết đây là chuyện phổ biến trong khoa học ngày nay, nhưng với tư cách lập trình viên làm việc với LLM thì bài báo gần như không có giá trị. Tất nhiên danh tiếng học thuật của các tác giả sẽ tăng lên một chút, và có vẻ rất có khả năng đó mới là mục đích
Tôi cũng muốn thử viết chung vài bài báo kiểu này. Không biết phải viết khoảng bao nhiêu bài thì mới có thể đặt chức danh “ML researcher” lên đầu CV
Lẽ ra họ nên dành nhiều thời gian hơn cho ví dụ và prompt
Vài tuần trước tôi cũng đã viết điều tương tự, nhưng mọi người đang đơn giản hóa quá mức phần tóm tắt: https://news.ycombinator.com/item?id=37117515
Giá trị của bộ nhớ dài hạn khác nhau tinh tế tùy theo use case
Nếu xây dựng trợ lý gia đình, bạn cần dùng NER để nhận diện tên, hiểu người đó thích giọng điệu nào khi gửi tin nhắn cho họ, cũng như địa điểm và cách di chuyển
Nếu xây dựng bot hỗ trợ khách hàng, bạn cần nhận diện các truy vấn kéo dài thành cuộc trò chuyện dài hoặc các truy vấn dẫn đến việc đột ngột bỏ giỏ hàng
Chỉ với mức tóm tắt chung chung cũng có thể làm demo hào nhoáng, nhưng để tạo ra sản phẩm thật sự hữu ích lúc này thì phải tiến thêm một bước
Tôi không rõ ở đây có gì mới
Tóm tắt bộ nhớ lịch sử chat dựa trên LLM đã là một kỹ thuật nổi tiếng, được triển khai trong nhiều framework LLM. Nếu tóm tắt mỗi tin nhắn như trong bài báo thì sẽ thành nút thắt hiệu năng lớn và thêm độ trễ đáng kể vào vòng lặp chat
Nhiều triển khai dùng buffer kích thước cố định và tóm tắt dần các cụm bộ nhớ cũ bị đẩy ra khỏi buffer. Lý tưởng thì việc này cũng được xử lý bên ngoài vòng lặp chat
Tôi là một trong các tác giả của Zep, kho lưu trữ bộ nhớ dài hạn mã nguồn mở, và chúng tôi đã triển khai tóm tắt theo cách này
0: https://github.com/getzep/zep
https://github.com/paul-gauthier/aider/blob/main/aider/histo...
https://www.deeplearning.ai/short-courses/langchain-for-llm-...
Hơi lệch khỏi bài viết hay cuộc thảo luận, nhưng bộ nhớ ngắn thực sự là một giới hạn
Tuy nhiên tôi nghĩ hầu hết các phê bình về năng lực của GPT-4 cũng áp dụng y hệt, hoặc còn mạnh hơn, với con người
Trong tình huống bài kiểm tra Turing ngược, tôi không nghĩ có người sống nào có thể thuyết phục tôi rằng họ là GPT-4. Chỉ riêng các câu trả lời nhanh và gọn gàng của GPT-4 đã vượt xa năng lực con người
Thậm chí nếu một nhóm người có 60 phút để trả lời mỗi câu hỏi, họ vẫn có thể khó theo kịp phản hồi của GPT-4 trước các truy vấn thú vị. Có lẽ sẽ là một cuộc thi thú vị
Phần triển khai trong bài báo về cơ bản là nối thêm văn bản bộ nhớ như một phần của prompt
Tôi thắc mắc tại sao không dùng hệ thống lưu trữ và truy xuất không tiêu tốn token của cửa sổ ngữ cảnh. Ví dụ khi lưu, tức là khi prompt của người dùng đi vào, có thể tự động phân loại dữ liệu bằng tag; khi truy xuất, LLM có thể gửi truy vấn lọc theo các tag mà nó suy đoán trước khi trả lời
Trực giác của tôi là chỉ cần vài quy tắc ban đầu như tên tag hoặc phong cách được hard-code cũng có thể cho kết quả khá tốt