LangChain công bố bộ tiêu chuẩn đánh giá hệ thống hỏi đáp dữ liệu CSV

Đây là một bài viết khá dài. Chúng tôi sẽ đi sâu vào việc hỏi đáp dựa trên dữ liệu dạng bảng (tabular data). Mặc dù bài viết này thảo luận (và sử dụng) dữ liệu CSV, nhưng phần lớn các ý tưởng tương tự cũng có thể áp dụng cho dữ liệu SQL. Bài viết bao gồm:

Để giới thiệu sơ lược, giải pháp cải tiến mà chúng tôi đạt được là một agent tùy chỉnh sử dụng các hàm của OpenAI và có quyền truy cập vào hai công cụ: Python REPL và một bộ truy xuất (retriever).

Chúng tôi đã mã nguồn mở mọi thứ - ứng dụng dùng để thu thập phản hồi, tập dữ liệu, tập lệnh đánh giá - tại kho lưu trữ này. Chúng tôi cũng đã thực hiện một video trên YouTube hướng dẫn chi tiết nội dung trong blog này, nếu bạn thích hình thức đó hơn.

Động lực nền tảng

Hiện nay đã có một công thức khá chuẩn cho việc đặt câu hỏi trên dữ liệu văn bản. Mặt khác, một lĩnh vực mà chúng tôi liên tục nhận được yêu cầu cải thiện là dữ liệu dạng bảng (CSV). Rất nhiều dữ liệu doanh nghiệp nằm trong các tệp CSV, và việc cung cấp một giao diện ngôn ngữ tự nhiên cho chúng có thể giúp tạo ra những thông tin chi tiết dễ dàng hơn. Vấn đề là cách thực hiện điều này vẫn chưa thực sự rõ ràng.

Vài tuần trước, chúng tôi quyết định tập trung vào vấn đề này một thời gian nhưng nhanh chóng gặp phải một trở ngại – chúng tôi không thực sự biết người dùng mong muốn đặt những loại câu hỏi nào cho dữ liệu CSV, và chúng tôi cũng không có cách nào tốt để đánh giá các ứng dụng này.

💡

Việc đánh giá các ứng dụng LLM thường khó khăn do thiếu dữ liệu và thiếu các chỉ số đo lường.

Trong học máy truyền thống, bạn thường bắt đầu với một tập dữ liệu đầu vào và đầu ra, sau đó sử dụng nó để huấn luyện và đánh giá mô hình của mình. Tuy nhiên, vì các LLM là những "zero shot learner" tuyệt vời, giờ đây bạn có thể sử dụng một prompt để nhanh chóng xây dựng một ứng dụng chỉ dựa trên ý tưởng mà không cần dữ liệu. Mặc dù điều này cực kỳ mạnh mẽ trong việc giúp các nhà phát triển xây dựng ứng dụng mới nhanh chóng, nhưng nó lại gây khó khăn trong việc đánh giá vì bạn thiếu dữ liệu đó. Đây là lý do tại sao chúng tôi xây dựng LangSmith theo cách giúp việc tạo tập dữ liệu trở nên dễ dàng nhất có thể.

Tương tự, thường không có các chỉ số tốt để đánh giá ứng dụng LLM. Đầu ra thường là ngôn ngữ tự nhiên, và các chỉ số NLP truyền thống như BLEU và ROUGE không thực sự hiệu quả. Nhưng cái gì giỏi trong việc hiểu ngôn ngữ tự nhiên? Chính là các LLM! Chúng tôi khá lạc quan về việc đánh giá có sự hỗ trợ của LLM và đã đầu tư xây dựng một loạt các trình đánh giá sử dụng chính LLM để thực hiện việc này.

Vậy chúng tôi đã áp dụng những ý tưởng này như thế nào vào nhiệm vụ tạo ra một ứng dụng tốt hơn để trả lời câu hỏi trên dữ liệu dạng bảng? Chúng tôi sẽ đi sâu vào chi tiết trong các phần tiếp theo, nhưng ở cấp độ tổng quan, chúng tôi đã:

Ứng dụng ban đầu

Đầu tiên, chúng tôi bắt tay vào tạo một tập dữ liệu gồm các câu hỏi và câu trả lời đúng (ground truth). Một phần vấn đề ở đây là chúng tôi thậm chí không biết người dùng muốn đặt loại câu hỏi nào cho dữ liệu dạng bảng của họ. Chúng tôi có thể đã đưa ra một vài dự đoán có cơ sở, hoặc cố gắng tạo ra các câu hỏi tổng hợp. Nhưng thay vào đó, chúng tôi muốn tối ưu hóa cho các câu hỏi thực tế, vì chúng tôi cũng muốn khám phá xem người dùng thực sự muốn hỏi những gì.

💡

Trước khi ra mắt một ứng dụng, việc đoán xem người dùng sẽ tương tác với nó như thế nào có thể rất khó khăn. Thay vì đoán, một chiến lược là hãy ra mắt nhanh chóng, sớm và thu thập dữ liệu thực tế.

Để làm điều này, chúng tôi quyết định khởi chạy một ứng dụng demo nhanh và đưa nó ra thực tế. Sau đó, chúng tôi ghi lại các câu hỏi thực tế của người dùng cùng với bất kỳ phản hồi nào về câu trả lời mà họ nhận được. Để thu thập phản hồi, chúng tôi đã thêm một nút "thích"/"không thích" đơn giản vào ứng dụng. Chúng tôi sử dụng LangSmith để theo dõi tất cả các tương tác và phản hồi, sau đó xem xét thủ công các tương tác này và tạo ra một tập dữ liệu bao gồm những tương tác thú vị. Việc này được thực hiện dễ dàng từ giao diện LangSmith - có một nút "Add to Dataset" trên tất cả các nhật ký (logs).

Ngoài ra còn có câu hỏi về loại dữ liệu mà chúng tôi muốn thu thập. Chúng tôi đã xem xét hai cách tiếp cận: (1) để người dùng tải lên tệp CSV của riêng họ và đặt câu hỏi, (2) cố định tệp CSV và thu thập câu hỏi dựa trên đó. Chúng tôi chọn (2) vì một vài lý do. Thứ nhất - nó giúp mọi người dễ dàng trải nghiệm hơn, có khả năng dẫn đến nhiều phản hồi hơn. Thứ hai - nó có lẽ sẽ giúp việc đánh giá dễ dàng hơn. Thứ ba - chúng tôi đặc biệt muốn ghi lại và xem xét các câu hỏi của người dùng, và chúng tôi không muốn làm điều này trên bất kỳ tệp CSV bảo mật nào mà ai đó có thể tải lên. Tuy nhiên, cách này cũng có một vài nhược điểm. Chúng tôi phải chọn một tệp CSV để sử dụng, và tệp này có thể không đại diện cho các tệp CSV khác - cả về kích thước và cấu trúc dữ liệu, cũng như các loại câu hỏi mà mọi người có thể muốn đặt ra.

Đối với ứng dụng ví dụ, chúng tôi đã chọn tập dữ liệu Titanic kinh điển - một bản ghi về tất cả hành khách trên tàu Titanic và liệu họ có sống sót hay không, thường được sử dụng cho các dự án khoa học dữ liệu mẫu. Chúng tôi đã tạo ứng dụng đơn giản này bằng Streamlit, đưa nó ra thế giới và yêu cầu mọi người phản hồi. Bạn có thể xem ứng dụng đã lưu trữ tại đây và mã nguồn tại đây.

Thông qua đó, chúng tôi đã thu thập được khoảng 400 tương tác. Trong số đó, khoảng 200 tương tác có phản hồi. Sử dụng LangSmith, chúng tôi đã đi sâu vào các điểm dữ liệu có phản hồi xấu (và một số phản hồi tốt), gắn nhãn thủ công và thêm chúng vào tập dữ liệu mà chúng tôi đã tạo. Chúng tôi thực hiện việc này cho đến khi có khoảng 50 điểm dữ liệu.

Bây giờ là lúc để cải thiện hệ thống của chúng tôi! Trước khi nói về cách chúng tôi cải thiện, hãy cùng thảo luận (1) hệ thống ban đầu là gì, (2) nó có những vấn đề gì, và (3) làm thế nào chúng tôi đánh giá hệ thống để đo lường bất kỳ cải tiến nào.

Giải pháp ban đầu

Tập dữ liệu Titanic có sự kết hợp của nhiều cột. Một số là dạng số (tuổi, số anh chị em, giá vé), một số là dạng phân loại (ga lên tàu, số khoang) và có một cột văn bản (tên).

Mặc dù tên của một người không chứa quá nhiều văn bản, nhưng nó vẫn đủ để gây ra một số vấn đề. Ví dụ, nếu một câu hỏi được đặt ra về "John Smith", có rất nhiều biến thể về cách tên đó có thể được thể hiện: Mr. John Smith (danh xưng), Smith, John (thứ tự), Jon Smith (lỗi chính tả), John Jacob Smith (tên đệm), v.v. Điều này có thể gây khó khăn khi lọc các hàng chính xác theo tên, hoặc thậm chí thực hiện tra cứu. Do đó, ngay từ đầu chúng tôi biết rằng mình phải bao gồm một số chức năng dựa trên tìm kiếm mờ (fuzzy). Tuy nhiên, chúng tôi cũng đoán rằng mọi người sẽ muốn đặt các câu hỏi về tổng hợp ("ai đã trả nhiều tiền vé nhất") hoặc tương tự, vì vậy chúng tôi có lẽ cần một số chức năng để làm điều đó.

💡

Dữ liệu dạng bảng có chứa văn bản có thể đặc biệt khó xử lý, vì việc truy xuất có khả năng cần thiết dưới một hình thức nào đó, nhưng truy xuất thuần túy có lẽ là chưa đủ.

Truy xuất (Retrieval)

Đối với phần ngôn ngữ tự nhiên, chúng tôi muốn sử dụng một hệ thống truy xuất truyền thống. Chúng tôi không muốn làm quá phức tạp, vì vậy chúng tôi chỉ muốn sử dụng một vectorstore đơn giản và tra cứu kết quả dựa trên độ tương đồng cosine với câu hỏi đầu vào.

Để làm điều này, chúng tôi cần tải tệp CSV vào một vectorstore. Chúng tôi đã thực hiện việc này bằng cách sử dụng logic của CSVLoader. Những gì nó thực hiện bên dưới là:

Đi sâu hơn một chút vào điểm (2), có một vài cách bạn có thể biểu diễn một hàng CSV dưới dạng một tài liệu. Bạn có thể biểu diễn nó dưới dạng JSON, dưới dạng CSV, hoặc - như cách chúng tôi đã làm - một đoạn văn bản được định dạng. Cụ thể, nếu bạn có một hàng CSV với các giá trị sau: {"col1": "foo", "col2": "bar"} thì sau khi định dạng, nó sẽ trông như thế này:

col1: foocol2: bar

Mặc dù điều này có vẻ không thú vị lắm, nhưng một phần LỚN của các ứng dụng LLM là kỹ thuật dữ liệu (data engineering) phù hợp để truyền đạt dữ liệu đến LLM một cách hiệu quả nhất. Theo kinh nghiệm, chúng tôi nhận thấy cách biểu diễn dữ liệu dạng bảng (và cả JSON) này là hiệu quả nhất khi các giá trị có thể chứa các giá trị văn bản.

Ngôn ngữ truy vấn

Ngoài việc truy xuất, chúng tôi cũng nhận thấy mọi người sẽ muốn đặt những câu hỏi đòi hỏi một loại ngôn ngữ truy vấn nào đó. Ví dụ - "ai đã trả nhiều tiền vé nhất". Có hai cách tiếp cận mà chúng tôi đã xem xét ở đây.

Thứ nhất, chúng tôi cân nhắc sử dụng Python REPL và yêu cầu mô hình ngôn ngữ viết mã để giúp trả lời câu hỏi của người dùng. Cách này có lợi ích là rất linh hoạt. Nó cũng có nhược điểm là có thể QUÁ linh hoạt - nó có thể cho phép thực thi mã tùy ý.

Thứ hai, chúng tôi cân nhắc sử dụng kork để cấp quyền truy cập vào một tập hợp các hàm được xác định trước. kork là một thư viện về cơ bản cho phép danh sách trắng (whitelist) các hàm có thể được sử dụng. Nó ít tổng quát hơn - bạn phải khai báo tất cả các hàm có thể chạy - nhưng nó an toàn hơn.

Để bắt đầu, chúng tôi đã chọn kork. Chúng tôi không hoàn toàn chắc chắn về những gì mọi người sẽ hỏi, vì vậy chúng tôi đã định nghĩa một vài hàm (filter, sum, contains) và cấp quyền truy cập cho nó.

Giải pháp đầu tiên của chúng tôi chạy truy xuất và kork song song, sau đó kết hợp các câu trả lời lại với nhau.

Gỡ lỗi với LangSmith

Mọi người bắt đầu đặt câu hỏi và các phản hồi bắt đầu đổ về. Chỉ khoảng 1/3 phản hồi là tích cực. Điều gì đã xảy ra? Có hai nguồn lỗi chính: