Tăng cường đột biến cải thiện di truyền bằng mô hình ngôn ngữ lớn

tác giả: (1) Alexander EI Brownlee, Đại học Stirling, Vương quốc Anh; (2) James Callan, Đại học College London, Anh; (3) Karine Even-Mendoza, King's College London, Vương quốc Anh; (4) Alina Geiger, Đại học Johannes Gutenberg Mainz, Đức; (5) Carol Hanna, Đại học College London, Anh; (6) Justyna Petke, Đại học College London, Vương quốc Anh; (7) Federica Sarro, Đại học College London, Anh; (8) Dominik Sobania, Đại học Johannes Gutenberg Mainz, Đức. Tổng quan về nội dung trừu tượng Giới thiệu Thiết lập thử nghiệm Kết quả Kết luận và công việc tương lai Người giới thiệu trừu tượng Các mô hình ngôn ngữ lớn (LLM) đã được áp dụng thành công cho các nhiệm vụ kỹ thuật phần mềm, bao gồm cả sửa chữa chương trình. Tuy nhiên, ứng dụng của chúng trong các kỹ thuật dựa trên tìm kiếm như Cải thiện Di truyền (GI) phần lớn vẫn chưa được khám phá. Trong bài báo này, chúng tôi đánh giá việc sử dụng LLM làm toán tử đột biến cho GI để cải thiện quá trình tìm kiếm. Chúng tôi mở rộng bộ công cụ Gin Java GI để gọi API của OpenAI nhằm tạo các chỉnh sửa cho công cụ JCodec. Chúng tôi lấy mẫu ngẫu nhiên không gian chỉnh sửa bằng 5 loại chỉnh sửa khác nhau. Chúng tôi thấy rằng số lượng bản vá vượt qua bài kiểm tra đơn vị cao hơn tới 75% với các chỉnh sửa dựa trên LLM so với các chỉnh sửa Chèn tiêu chuẩn. Hơn nữa, chúng tôi nhận thấy rằng các bản vá được tìm thấy bằng LLM nhìn chung ít đa dạng hơn so với các chỉnh sửa tiêu chuẩn. Chúng tôi đã chạy GI với tính năng tìm kiếm cục bộ để tìm ra những cải tiến về thời gian chạy. Mặc dù nhiều bản vá cải tiến được tìm thấy bởi GI nâng cao LLM, nhưng bản vá cải thiện tốt nhất được tìm thấy bởi GI tiêu chuẩn. Giới thiệu Khi các hệ thống phần mềm ngày càng lớn hơn và phức tạp hơn, cần phải có nỗ lực thủ công đáng kể để duy trì chúng [2]. Để giảm bớt nỗ lực của nhà phát triển trong các nhiệm vụ tối ưu hóa và bảo trì phần mềm, các mô hình tự động là rất cần thiết. Cải thiện Di truyền (GI) [15] áp dụng các kỹ thuật dựa trên tìm kiếm để cải thiện các thuộc tính phi chức năng của phần mềm hiện có như thời gian thực thi cũng như các thuộc tính chức năng như sửa lỗi. Mặc dù GI đã thành công trong ngành [12,13] nhưng nó vẫn bị hạn chế bởi tập hợp các toán tử đột biến mà nó sử dụng trong tìm kiếm [14]. Mô hình ngôn ngữ lớn (LLM) có nhiều ứng dụng vì chúng có thể xử lý các truy vấn văn bản mà không cần đào tạo bổ sung cho nhiệm vụ cụ thể hiện tại. LLM đã được đào tạo trước trên hàng triệu kho mã trải rộng trên nhiều ngôn ngữ lập trình khác nhau [5]. Việc sử dụng chúng cho các nhiệm vụ kỹ thuật phần mềm đã đạt được thành công lớn [9,6], cho thấy cũng có triển vọng cho việc sửa chữa chương trình [17,19]. Kang và Yoo [10] đã gợi ý rằng có tiềm năng chưa được khai thác trong việc sử dụng LLM để tăng cường GI. GI sử dụng các toán tử đột biến giống nhau cho các nhiệm vụ tối ưu hóa khác nhau. Các toán tử này được thực hiện thủ công trước khi bắt đầu tìm kiếm và do đó dẫn đến không gian tìm kiếm bị hạn chế. Chúng tôi đưa ra giả thuyết rằng việc tăng cường các đề xuất bản vá LLM như một toán tử đột biến bổ sung sẽ làm phong phú không gian tìm kiếm và mang lại nhiều biến thể thành công hơn. Trong bài báo này, chúng tôi tiến hành một số thử nghiệm để khám phá xem liệu việc sử dụng LLM làm toán tử đột biến trong GI có thể cải thiện hiệu suất và hiệu quả của việc tìm kiếm hay không. Kết quả của chúng tôi cho thấy các bản vá do LLM tạo có tỷ lệ biên dịch lần lượt là 51,32% và 53,54% cho tìm kiếm ngẫu nhiên và tìm kiếm cục bộ (với danh mục Lời nhắc Trung bình). Các LLM trước đây (sử dụng mô hình LLM nguyên trạng) đã được chứng minh là tạo ra mã được biên dịch khoảng 40% thời gian [16,18]. Chúng tôi nhận thấy rằng các chỉnh sửa dựa trên LLM được lấy mẫu ngẫu nhiên được biên soạn và vượt qua các bài kiểm tra đơn vị thường xuyên hơn so với các chỉnh sửa GI tiêu chuẩn. Chúng tôi quan sát thấy rằng số lượng bản vá vượt qua bài kiểm tra đơn vị đối với các chỉnh sửa dựa trên LLM cao hơn tới 75% so với các chỉnh sửa GI Insert. Tuy nhiên, chúng tôi nhận thấy rằng các bản vá được tìm thấy bằng LLM ít đa dạng hơn. Đối với tìm kiếm cục bộ, cải thiện tốt nhất đạt được bằng cách sử dụng các chỉnh sửa Tuyên bố GI tiêu chuẩn, tiếp theo là các chỉnh sửa dựa trên LLM. Những phát hiện này chứng minh tiềm năng của LLM với tư cách là người vận hành đột biến và nêu bật sự cần thiết phải nghiên cứu sâu hơn trong lĩnh vực này. Thiết lập thử nghiệm Để phân tích việc sử dụng LLM làm toán tử đột biến trong GI, chúng tôi đã sử dụng mô hình GPT 3.5 Turbo của OpenAI và hộp công cụ GI Gin [3]. Chúng tôi đã thử nghiệm hai loại tìm kiếm được triển khai trong Gin: tìm kiếm ngẫu nhiên và tìm kiếm cục bộ. Các yêu cầu tới LLM bằng API OpenAI được thực hiện thông qua thư viện Langchain4J, với nhiệt độ 0,7. Dự án mục tiêu để cải thiện các thử nghiệm của chúng tôi là dự án JCodec [7] phổ biến được viết bằng Java. Các phương pháp 'Hot' mà các chỉnh sửa nhắm đến đã được xác định bằng cách sử dụng công cụ hồ sơ của Gin bằng cách lặp lại hồ sơ 20 lần và lấy kết hợp của tập hợp kết quả. Đối với các thử nghiệm lấy mẫu ngẫu nhiên, chúng tôi thiết lập các lần chạy với các chỉnh sửa ở cấp câu lệnh (sao chép/xóa/thay thế/hoán đổi từ [14] và chèn ngắt/tiếp tục/trả về từ [4]) và các chỉnh sửa LLM, tạo ngẫu nhiên 1000 mỗi loại . Thời gian chờ là 10000 mili giây đã được sử dụng cho mỗi bài kiểm tra đơn vị để nắm bắt các vòng lặp vô hạn do các chỉnh sửa đưa ra; vượt quá thời gian chờ được tính là thử nghiệm thất bại. Đối với tìm kiếm cục bộ, các thử nghiệm được thiết lập tương tự. Có 10 lần chạy lặp lại (một lần cho mỗi phương pháp trong số 10 phương pháp hot nhất) nhưng các lần chạy bị giới hạn ở 100 lần đánh giá dẫn đến tổng cộng 1000 lần đánh giá, phù hợp với tìm kiếm ngẫu nhiên. Trong thực tế, đây là 99 lần chỉnh sửa mỗi lần chạy vì lần chỉnh sửa đầu tiên được sử dụng để tính thời gian cho mã chưa được vá ban đầu. Chúng tôi đã thử nghiệm ba lời nhắc khác nhau để gửi yêu cầu tới LLM cho cả hai loại tìm kiếm: lời nhắc đơn giản, lời nhắc trung bình và lời nhắc chi tiết. Với cả ba lời nhắc, việc triển khai của chúng tôi yêu cầu có sẵn năm biến thể mã khác nhau. Lời nhắc đơn giản chỉ yêu cầu mã mà không có bất kỳ thông tin bổ sung nào. Lời nhắc trung bình cung cấp thêm thông tin về mã được cung cấp và các yêu cầu, như trong Hình 1. Cụ thể, chúng tôi cung cấp cho LLM ngôn ngữ lập trình được sử dụng, dự án chứa mã đó cũng như các hướng dẫn định dạng. Lời nhắc chi tiết mở rộng lời nhắc trung bình kèm theo ví dụ về một thay đổi hữu ích. Ví dụ này được lấy từ kết quả thu được của Brownlee et al. [4]. Bản vá này là một phiên bản thành công của chỉnh sửa chèn được áp dụng cho dự án jCodec (tức là một chỉnh sửa đã biên dịch, vượt qua các bài kiểm tra đơn vị và cung cấp khả năng tăng tốc so với mã gốc). Chúng tôi sử dụng cùng một ví dụ cho tất cả các yêu cầu nhắc nhở chi tiết được sử dụng trong các thử nghiệm của mình; điều này là do LLM có khả năng suy luận quy nạp trong đó người dùng trình bày thông tin cụ thể và LLM có thể sử dụng đầu vào đó để tạo ra các câu lệnh tổng quát hơn, được cải tiến hơn nữa trong GPT-4 [8]. Các chỉnh sửa LLM được áp dụng bằng cách chọn ngẫu nhiên một câu lệnh khối theo phương pháp 'nóng' mục tiêu. Nội dung của khối này nằm in the prompt. The first code block in the LLM response is identified. Gin uses JavaParser (https://javaparser.org) internally to represent target source files, so we attempt to parse the LLM suggestion with JavaParser, and replace the original block with the LLM suggestion. Kết quả Thử nghiệm đầu tiên so sánh các đột biến GI tiêu chuẩn, cụ thể là các chỉnh sửa Chèn và Câu lệnh, với các chỉnh sửa LLM sử dụng các lời nhắc chi tiết khác nhau (Đơn giản, Trung bình và Chi tiết) bằng cách sử dụng Lấy mẫu ngẫu nhiên. Bảng 1 hiển thị kết quả cho tất cả các bản vá cũng như chỉ cho các bản vá duy nhất. Chúng tôi báo cáo số lượng bản vá đã được phân tích cú pháp thành công bởi JavaParser (được đặt tên là Hợp lệ), số lượng được biên dịch và số lượng đã vượt qua tất cả các bài kiểm tra đơn vị (được đặt tên là Đã vượt qua). Chúng tôi đã loại trừ các bản vá có cú pháp tương đương với phần mềm gốc. Kết quả tốt nhất được in . đậm Chúng tôi thấy rằng mặc dù về cơ bản đã tìm thấy nhiều bản vá hợp lệ hơn với các chỉnh sửa Chèn và Tuyên bố tiêu chuẩn, nhưng có thể tìm thấy nhiều bản vá vượt qua hơn bằng cách sử dụng các chỉnh sửa do LLM tạo. Đặc biệt, đối với lời nhắc Trung bình và Chi tiết, 292 và 230 bản vá lần lượt vượt qua bài kiểm tra đơn vị. Đối với các chỉnh sửa Chèn và Câu lệnh, chỉ có 166 và 91 lần lượt vượt qua các bài kiểm tra đơn vị. Thông thường, các phương pháp phổ biến có tỷ lệ vượt qua bản vá thấp nhất/cao nhất sẽ khác nhau đối với mỗi nhà khai thác: hiểu được sự khác biệt này sẽ rất thú vị cho việc điều tra trong tương lai. Điều đáng chú ý là các bản vá LLM kém đa dạng hơn: các nhà khai thác đột biến tiêu chuẩn tìm thấy hơn 50% các bản vá độc đáo hơn so với LLM sử dụng Medium, và Lời nhắc chi tiết. Tuy nhiên, với lời nhắc Đơn giản, không một bản vá nào vượt qua được các bài kiểm tra đơn vị, vì các chỉnh sửa được đề xuất thường không thể phân tích được. Vì vậy, cần có những lời nhắc chi tiết để buộc LLM tạo ra các đầu ra có thể sử dụng được. Chúng tôi đã nghiên cứu sâu hơn về sự khác biệt giữa lời nhắc Trung bình và Chi tiết để hiểu sự giảm hiệu suất với Chi tiết (trong các bộ bản vá duy nhất) vì Phương tiện có số lượng bản vá được biên dịch và thông qua cao hơn. Ở cả hai cấp độ lời nhắc, phản hồi được tạo ra giống nhau cho 42 trường hợp (trong tổng số các trường hợp hợp lệ duy nhất). Tuy nhiên, Chi tiết có xu hướng tạo ra phản hồi dài hơn với trung bình 363 ký tự, trong khi Phương tiện có trung bình 304 ký tự. Chúng tôi đã kiểm tra thủ công một số phản hồi nhanh chóng Chi tiết, trong đó chúng tôi đã xác định được một số biến bao gồm các biến từ các tệp khác, có khả năng cung cấp sự mở rộng đáng kể cho tập hợp các biến thể mã mà GI có thể khám phá. Thử nghiệm thứ hai mở rộng phân tích của chúng tôi, so sánh hiệu suất của các chỉnh sửa tiêu chuẩn và LLM với Tìm kiếm Địa phương. Bảng 2 cho thấy kết quả của thử nghiệm Tìm kiếm cục bộ. Chúng tôi báo cáo số lượng các bản vá được biên dịch và chuyển giao cũng như số lượng các bản vá được cải tiến về thời gian chạy đã được tìm thấy. Hơn nữa, chúng tôi báo cáo mức cải thiện trung bình và tốt nhất tính bằng mili giây (ms). Trong bảng, chúng tôi loại trừ tất cả các bản vá trống. Như trước đây, kết quả tốt nhất được in . đậm Một lần nữa, chúng tôi thấy rằng có thể tìm thấy nhiều bản vá vượt qua bài kiểm tra đơn vị hơn với LLM bằng cách sử dụng lời nhắc Trung bình và Chi tiết. Ngoài ra, có thể tìm thấy nhiều cải tiến hơn bằng cách sử dụng LLM với những lời nhắc này. Cụ thể, với Trung bình và Chi tiết, chúng tôi tìm thấy lần lượt 164 và 196 cải tiến, trong khi chúng tôi chỉ tìm thấy 136 cải tiến với Chèn và 71 với Tuyên bố. Cải thiện tốt nhất có thể được tìm thấy với 508 ms với bản chỉnh sửa Tuyên bố. Cải tiến tốt nhất được tìm thấy khi sử dụng LLM (sử dụng lời nhắc Trung bình) chỉ có thể cải thiện thời gian chạy thêm 395 mili giây. Chúng tôi cũng đã kiểm tra một loạt nội dung chỉnh sửa trong kết quả Tìm kiếm địa phương để hiểu rõ hơn về sự khác biệt giữa lời nhắc Trung bình và Lời nhắc chi tiết do tỷ lệ tổng hợp các phản hồi của lời nhắc Chi tiết thấp. Trong ví dụ này, một chuỗi các chỉnh sửa nhằm mục đích đưa một đoạn gọi hàm vào nội tuyến. Lời nhắc Chi tiết đã cố gắng kết hợp cuộc gọi gần như ngay lập tức trong một vài lần chỉnh sửa, có thể dẫn đến mã không hợp lệ. Mặt khác, lời nhắc Phương tiện thực hiện những thay đổi ít căn bản hơn, dần dần tinh chỉnh mã. Nó bắt đầu bằng cách thay thế biểu thức toán tử bậc ba bằng câu lệnh if-then-else và lệnh gọi hàm hệ thống trước khi cố gắng nội tuyến lệnh gọi hàm clip. Kết luận và công việc tương lai Sự cải tiến về mặt di truyền của phần mềm phụ thuộc rất nhiều vào các toán tử đột biến mà nó sử dụng trong quá trình tìm kiếm. Để đa dạng hóa các toán tử và làm phong phú thêm không gian tìm kiếm, chúng tôi đã kết hợp Mô hình ngôn ngữ lớn (LLM) làm toán tử. . Nói chung, công việc trong tương lai nên xem xét các dự án ngoài mục tiêu của chúng tôi, jCodec. Các thử nghiệm của chúng tôi đã sử dụng API khiến chúng tôi không kiểm soát được các phản hồi do LLM tạo ra hoặc bất kỳ cách sửa đổi hoặc tối ưu hóa chúng nào. Mặc dù chúng tôi không quan sát thấy những thay đổi về hành vi trong quá trình thử nghiệm của mình, nhưng OpenAI có thể thay đổi mô hình bất kỳ lúc nào, vì vậy công việc trong tương lai nên xem xét các mô hình địa phương. Chúng tôi đã thử nghiệm chỉ với ba loại lời nhắc cho các yêu cầu LLM và trong số lượng lời nhắc giới hạn này đã tìm thấy sự khác biệt trong kết quả. Cuối cùng, việc triển khai phân tích cú pháp phản hồi từ LLM của chúng tôi tương đối đơn giản. Tuy nhiên, điều này chỉ có nghĩa là kết quả được báo cáo của chúng tôi là bi quan và nhà điều hành dựa trên LLM có thể đạt được sự cải thiện lớn hơn nữa. Hạn chế . Chúng tôi nhận thấy rằng, mặc dù đã tìm thấy nhiều bản vá hợp lệ và đa dạng hơn với các chỉnh sửa tiêu chuẩn sử dụng Lấy mẫu ngẫu nhiên, nhưng lại tìm thấy nhiều bản vá vượt qua bài kiểm tra đơn vị hơn với các chỉnh sửa dựa trên LLM. Ví dụ: với chỉnh sửa LLM bằng lời nhắc Trung bình, chúng tôi nhận thấy số bản vá vượt qua bài kiểm tra đơn vị cao hơn 75% so với chỉnh sửa Chèn cổ điển. Trong thử nghiệm Tìm kiếm cục bộ, chúng tôi đã tìm thấy cải tiến tốt nhất với bản chỉnh sửa Tuyên bố (508 mili giây). Cải thiện dựa trên LLM tốt nhất được tìm thấy với lời nhắc Trung bình (395 mili giây). Do đó, có tiềm năng trong việc khám phá các phương pháp kết hợp cả chỉnh sửa LLM và GI 'cổ điển'. Bản tóm tắt Thử nghiệm của chúng tôi cho thấy rằng lời nhắc được sử dụng cho yêu cầu LLM ảnh hưởng lớn đến kết quả. Vì vậy, trong công việc tương lai, chúng tôi hy vọng sẽ thử nghiệm nhiều hơn với kỹ thuật nhanh chóng. Cũng có thể hữu ích khi kết hợp các lời nhắc: ví dụ: bắt đầu bằng phương tiện, sau đó chuyển sang chi tiết để thực hiện các chỉnh sửa lớn hơn vượt ra khỏi mức tối thiểu cục bộ. Hơn nữa, khả năng kết hợp các chỉnh sửa LLM với các chỉnh sửa khác như sao chép/xóa/thay thế/hoán đổi hoặc mẫu PAR tiêu chuẩn [11] có thể rất thú vị. Cuối cùng, chúng tôi hy vọng có thể tiến hành thử nghiệm rộng rãi hơn trên các chương trình thử nghiệm bổ sung. Mã, cơ sở hạ tầng thử nghiệm và nhắc nhở LLM, dữ liệu từ đánh giá và kết quả có sẵn dưới dạng nguồn mở tại [1]. Mã này cũng nằm trong nhánh 'llm' của github.com/gintool/gin (cam kết 9fe9bdf; được phân nhánh từ cam kết chính 2359f57 đang chờ tích hợp hoàn toàn với Gin). Tính sẵn có của dữ liệu. UKRI EPSRC EP/P023991/1 và ERC 741278. Lời cảm ơn Người giới thiệu Công cụ tăng cường đột biến cải thiện di truyền bằng cách sử dụng mô hình ngôn ngữ lớn. Zenodo (Tháng 9 năm 2023). https://doi.org/10.5281/zenodo.8304433 B¨ohme, M., Soremekun, EO, Chattopadhyay, S., Ugherughe, E., Zeller, A.: Lỗi ở đâu và cách khắc phục? Một thử nghiệm với các học viên. Trong: Proc. Hội nghị chuyên đề ACM về nền tảng của kỹ thuật phần mềm. trang 117–128 (2017) Brownlee, AE, Petke, J., Alexander, B., Barr, ET, Wagner, M., White, DR: Gin: nghiên cứu cải tiến di truyền được thực hiện dễ dàng. Tại: GECCO. trang 985–993 (2019) Brownlee, AE, Petke, J., Rasburn, AF: Thêm các phím tắt để mã Java chạy nhanh hơn. Trong: IEEE CEC 2020. p. 1–8 Chen, M., Tworek, J., Jun, H., Yuan, Q., Pinto, HPdO, Kaplan, J., Edwards, H., Burda, Y., Joseph, N., Brockman, G., et al.: Đánh giá các mô hình ngôn ngữ lớn được đào tạo về mã. bản in trước arXiv arXiv:2107.03374 (2021) Fan, A., Gokkaya, B., Harman, M., Lyubarskiy, M., Sengupta, S., Yoo, S., Zhang, JM: Mô hình ngôn ngữ lớn cho công nghệ phần mềm: Khảo sát và các vấn đề mở (2023) Github - jcodec/jcodec: Kho lưu trữ chính của Jcodec, https://github.com/jcodec/jcodec Han, SJ, Ransom, KJ, Perfors, A., Kemp, C.: Lý luận quy nạp ở con người và các mô hình ngôn ngữ lớn. Nghiên cứu hệ thống nhận thức p. 101155 (2023) Hou, X., Liu, Y., Yang, Z., Grundy, J., Zhao, Y., Li, L., Wang, K., Luo, X., Lo, D., Wang, H.: Các mô hình ngôn ngữ lớn cho công nghệ phần mềm: Đánh giá tài liệu có hệ thống. arXiv:2308.10620 (2023) Kang, S., Yoo, S.: Hướng tới cải tiến di truyền phù hợp khách quan thông qua các mô hình ngôn ngữ lớn. arXiv:2304.09386 (2023) Kim, D., Nam, J., Song, J., Kim, S.: Tạo bản vá tự động học được từ các bản vá do con người viết (2013), http://logging.apache.org/log4j/ Kirbas, S., Windels, E., Mcbello, O., Kells, K., Pagano, M., Szalanski, R., Nowack, V., Winter, E., Counsell, S., Bowes, D., Hall, T., Haraldsson, S., Woodward, J.: Giới thiệu chương trình sửa chữa tự động ở Bloomberg. Phần mềm IEEE 38(4), 43–51 (2021) Marginean, A., Bader, J., Chandra, S., Harman, M., Jia, Y., Mao, K., Mols, A., Scott, A.: Sapfix: Tự động sửa chữa toàn diện tại tỉ lệ. Trong: ICSE-SEIP. trang 269– 278 (2019) Petke, J., Alexander, B., Barr, ET, Brownlee, AE, Wagner, M., White, DR: Cảnh quan chuyển đổi chương trình để sửa đổi chương trình tự động bằng Gin. Kỹ thuật phần mềm thực nghiệm 28(4), 1–41 (2023) Petke, J., Haraldsson, SO, Harman, M., Langdon, WB, White, DR, Woodward, JR: Cải tiến di truyền của phần mềm: Một cuộc khảo sát toàn diện. Giao dịch của IEEE về tính toán tiến hóa 22, 415–432 (2018) Siddiq, ML, Santos, J., Tanvir, RH, Ulfat, N., Rifat, FA, Lopes, VC: Khám phá tính hiệu quả của các mô hình ngôn ngữ lớn trong việc tạo ra các bài kiểm tra đơn vị. bản in trước arXiv arXiv:2305.00418 (2023) Sobania, D., Briesch, M., Hanna, C., Petke, J.: Phân tích hiệu suất sửa lỗi tự động của chatgpt. Trong: Hội thảo quốc tế IEEE/ACM năm 2023 về Sửa chữa chương trình tự động (APR). trang 23–30. Hiệp hội máy tính IEEE (2023) Xia, CS, Paltenghi, M., Tian, JL, Pradel, M., Zhang, L.: Làm mờ phổ quát thông qua các mô hình ngôn ngữ lớn. bản in trước arXiv arXiv:2308.04748 (2023) Xia, CS, Zhang, L.: Tiếp tục cuộc trò chuyện: Sửa 162 trong số 337 lỗi với giá 0,42 USD mỗi lỗi bằng cách sử dụng chatgpt. bản in trước arXiv arXiv:2304.00385 (2023) Bài viết này theo giấy phép CC 4.0. có sẵn trên arxiv