Sau 6 tháng làm việc trên CodeGen Dev Tool (GPT Pilot), đây là điều tôi học được

Trong 6 tháng qua, tôi đã làm việc trên GPT Pilot ( https://github.com/Pythagora-io/gpt-pilot ) để hiểu chúng tôi thực sự có thể tự động hóa việc mã hóa bằng AI đến mức nào, vì vậy tôi muốn chia sẻ những gì chúng tôi đã học được cho đến nay và nó có thể đi bao xa.

Khi tôi bắt đầu xây dựng GPT Pilot, tôi đã viết bài đăng trên blog này về cách hình dung nó. Bây giờ, tôi muốn chia sẻ suy nghĩ đã được sửa đổi của mình và tìm hiểu xem điều gì hiệu quả và điều gì không hiệu quả.

Cuối cùng, bạn sẽ thấy các ví dụ về ứng dụng được tạo bằng GPT Pilot và cách bạn có thể tạo ứng dụng bằng cặp lập trình viên AI thực sự .

Ý tưởng đằng sau thí điểm GPT là gì?

GPT Pilot được hình dung là nhà phát triển AI thực sự - không phải là chương trình tự động hoàn thành hay chatbot . Đúng hơn, chính nhà phát triển là người lập kế hoạch về cách xây dựng ứng dụng hoặc tính năng của bạn và bắt đầu viết mã. Nó muốn tự mình thực hiện hầu hết việc mã hóa, nhưng khi gặp khó khăn, nó cần làm rõ về các yêu cầu nhất định hoặc yêu cầu xem xét mã, nó sẽ nhờ bạn trợ giúp.

AI có giống như một nhà phát triển cấp dưới không? Hoặc…

Tôi thường thấy các công cụ dựa trên CodeGen GPT-4 cho biết họ đang xây dựng một nhà phát triển AI cấp dưới.

Bằng cách nào đó, tôi luôn gặp vấn đề với điều đó bởi vì khi tôi sử dụng ChatGPT để viết mã, nó đưa ra cho tôi những câu trả lời và ý tưởng mà chỉ một cấp trên mới có thể đưa ra - điều mà hoàn toàn không một nhà phát triển cấp dưới nào có thể nắm bắt được. Tuy nhiên, không có LLM nào có thể xây dựng một ứng dụng gần như tốt như một nhà phát triển cấp cao, nhưng kiến thức mà GPT-4 có về mã hóa vượt xa bất kỳ nhà phát triển cấp dưới nào.

Tôi có thể nói rằng GPT-4 có rất nhiều kiến thức về mọi phần của quá trình phát triển phần mềm giống như nó là nhà phát triển cao cấp nhất trên thế giới nhưng lại có trí nhớ của một con cá vàng. Tôi hình dung nó như một con robot siêu phàm chỉ đứng giữa phòng và mỗi lần chỉ có thể thực hiện một hành động nhỏ chứ không thể kết hợp nhiều hành động và làm việc lặp đi lặp lại. Bạn phải nói cho nó biết chính xác nó nên làm gì tiếp theo.

Đây là những gì chúng tôi đang theo đuổi với GPT Pilot – chúng tôi muốn tạo ra một khuôn khổ tư duy cho LLM để giúp robot siêu phàm đó liên tục hoạt động bằng cách sửa đổi các hành động trước đó, có vòng phản hồi và xác định xem nó nên làm gì tiếp theo theo thứ tự để hoàn thành mục tiêu cuối cùng, đó là xây dựng một ứng dụng sẵn sàng sản xuất.

Trong bài đăng trên blog mà tôi đã đề cập ở trên , tôi đã phác thảo những trụ cột chính mà GPT Pilot được xây dựng trên đó. Tuy nhiên, những điều này đã thay đổi một chút dựa trên những hiểu biết của nhóm chúng tôi, vì vậy đây là những trụ cột được sửa đổi:

1. Cần có con người để giám sát AI không chỉ vì AI chưa đủ tốt mà còn vì bạn có thể muốn thay đổi cách thức hoạt động hoặc chăm sóc nó được triển khai. Thông thường, nhà phát triển hoặc người quản lý sản phẩm sẽ quyết định thay đổi nó sau khi thấy quá trình triển khai trông như thế nào.

   
   

2. Hoặc, bạn nhận ra có nhiều trường hợp khó khăn hơn dự kiến ban đầu và nghĩ rằng việc tái cấu trúc cách triển khai hiện tại sẽ dễ dàng hơn là khắc phục mọi vấn đề. Vấn đề là khi bạn hoàn thành toàn bộ ứng dụng và sau đó cố gắng cấu trúc lại nó - đây là lúc mọi việc trở nên khó khăn hơn nhiều vì mọi thay đổi sẽ ảnh hưởng đến tất cả các tính năng khác.

   
   

   Mặt khác, nếu bạn thực hiện việc tái cấu trúc trước khi thực hiện các thay đổi của mình, bạn sẽ có thể tiếp tục với các tính năng tiếp theo bên cạnh mã được viết tốt. Đây là lý do tại sao điều quan trọng đối với nhà phát triển AI là phải có con người tham gia mỗi khi thực hiện một nhiệm vụ .

   
   

   Bằng cách này, con người có thể xem xét việc triển khai từng nhiệm vụ (giống như xem xét mã trước khi hợp nhất một PR) trước khi GPT Pilot tiếp tục thực hiện nhiệm vụ tiếp theo. Nếu con người nói cho GPT Pilot biết điều gì sai, thì việc khắc phục các vấn đề trong chính nhiệm vụ đó sẽ dễ dàng hơn nhiều. Đồng thời, LLM có bối cảnh về những gì cần phải làm trong nhiệm vụ và những gì đã được thực hiện cho đến nay.

   
   

3. AI có thể lặp lại những sai lầm của chính mình. Tôi có cảm giác rằng nhiều người đánh giá khả năng viết mã của ChatGPT dựa trên mức độ hiệu quả của nó trong lần đầu tiên bạn yêu cầu nó viết mã thứ gì đó. Nếu nó không tạo ra mã hoạt động, nhiều người sẽ cho rằng nó không ấn tượng. Trên thực tế, con người hầu như không bao giờ viết mã hoạt động ngay lần thử đầu tiên . Thay vào đó, bạn viết mã, chạy mã, xem lỗi và lặp lại. Đây chính xác là những gì GPT Pilot cho phép GPT-4 thực hiện – sau khi viết mã, GPT Pilot có thể chạy mã, lấy đầu ra và hỏi LLM xem đầu ra có đúng không, có cần sửa lỗi gì không và nếu có thì bằng cách nào .

   
   

4. Phát triển phần mềm có thể được phối hợp . Có rất nhiều quy trình lặp đi lặp lại mà tất cả các nhà phát triển đều phải trải qua khi xây dựng một ứng dụng. Một trong các quy trình có thể là – viết mã, chạy mã, đọc lỗi, thay đổi mã, chạy lại mã, v.v. Một quy trình khác ở cấp độ cao hơn có thể là – nhận một nhiệm vụ, triển khai nó, kiểm tra quá trình triển khai (lặp lại cho đến khi tất cả các thử nghiệm đều vượt qua) , gửi để xem xét, khắc phục sự cố (lặp lại cho đến khi người đánh giá phê duyệt) và triển khai. Nhiều quy trình trong số này có thể được sắp xếp nếu chúng ta có người ra quyết định thông minh trong vòng lặp (như LLM).

   
   

5. Quá trình mã hóa không phải là một đường thẳng . Khi tạo phiên bản GPT Pilot đầu tiên, chúng tôi nghĩ rằng nó sẽ cần phải lặp lại các tác vụ, triển khai mã, sửa lỗi và tiếp tục. Trên thực tế, bạn không liên tục tiến bộ khi mã hóa một ứng dụng – bạn liên tục viết lại mã của mình.

   
   

   Đôi khi, bạn cấu trúc lại cơ sở mã vì sau lần triển khai đầu tiên, bạn nhận ra rằng có cách tốt hơn để triển khai một cái gì đó. Những lần khác, bạn làm điều đó vì có sự thay đổi về yêu cầu. Giống như tôi đã đề cập ở #1, sau khi bạn nhận thấy một giải pháp không hiệu quả, đôi khi bạn cần thực hiện lại một loạt thay đổi, nghĩ về một giải pháp thay thế cho vấn đề và thử giải quyết theo cách đó.

   
   

   Để làm cho GPT Pilot hoặc bất kỳ nhà phát triển AI nào khác hoạt động trên quy mô lớn, nó cần phải có một cơ chế cho phép nó quay trở lại, chọn một con đường thay thế và thực hiện lại một nhiệm vụ.

Chúng ta đã học được gì?

Nói chung, LLM là một công nghệ mới mà mọi người đang cố gắng hiểu - nó hoạt động như thế nào, có thể làm gì tốt hơn, cách thực hiện kỹ thuật nhanh chóng phù hợp, v.v. Cách tiếp cận của chúng tôi là tập trung vào việc xây dựng lớp ứng dụng thay vì làm việc để có được LLM để tạo ra kết quả tốt hơn .

Lý do là LLM sẽ trở nên tốt hơn và nếu chúng tôi dành hàng tuần để tối ưu hóa lời nhắc, vấn đề đó có thể được giải quyết hoàn toàn bằng phiên bản GPT mới.

Thay vào đó, chúng tôi đang tập trung vào trải nghiệm người dùng sẽ trông như thế nào và cần có cơ chế nào để kiểm soát LLM nhằm cho phép nó hoạt động liên tục, ngày càng tiến gần hơn đến giải pháp cuối cùng. Vì vậy, đây là những bài học của chúng tôi cho đến nay:

1. Mô tả ban đầu về ứng dụng quan trọng hơn nhiều so với chúng tôi nghĩ . Suy nghĩ ban đầu của chúng tôi là, với thông tin đầu vào của con người, GPT Pilot sẽ có thể điều hướng đúng hướng và ngày càng tiến gần hơn đến giải pháp hoạt động, ngay cả khi mô tả ban đầu còn mơ hồ.

   
   

   Tuy nhiên, suy nghĩ của GPT Pilot phân nhánh xuyên suốt các lời nhắc, bắt đầu từ phần mô tả ban đầu. Và cùng với đó, nếu có điều gì đó sai lệch trong lời nhắc ban đầu, tất cả thông tin khác mà GPT Pilot có sẽ dẫn đến sai hướng. Vì vậy, khi bạn sửa nó dần dần, nó sẽ đi sâu vào cách sai lầm này đến mức gần như không thể đi đúng hướng.

   
   

   Bây giờ, khi tôi viết bài này, điều đó có vẻ quá hiển nhiên, nhưng đó là điều chúng tôi cần tìm hiểu – tập trung nhiều hơn vào mô tả ban đầu. Vì vậy, chúng tôi đã xây dựng một tác nhân mới có tên là “Spec Writer”, tác nhân này làm việc với bạn để chia nhỏ các yêu cầu của dự án trước khi bắt đầu viết mã.

   
   

2. Mã hóa không phải là một đường thẳng . Như tôi đã đề cập ở trên trong phần trụ cột, việc tái cấu trúc luôn diễn ra và GPT Pilot cũng phải làm như vậy. Chúng tôi chưa triển khai giải pháp cho vấn đề này, nhưng nó có thể sẽ hoạt động bằng cách bổ sung khả năng cho GPT Pilot tạo các điểm đánh dấu xung quanh cây quyết định của mình để bất cứ khi nào có điều gì đó không hoạt động, nó có thể xem xét các điểm đánh dấu và suy nghĩ xem nó có thể có ở đâu Đã sai lầm.

   
   

3. Đại lý có thể tự xem xét . Suy nghĩ của tôi là nếu một nhân viên xem lại những gì nhân viên kia đã làm thì điều đó sẽ là dư thừa vì chính LLM đó đang xử lý lại cùng một thông tin. Nhưng hóa ra khi một đại lý đánh giá công việc của một đại lý khác thì nó lại hoạt động hiệu quả đến mức đáng kinh ngạc. Chúng tôi có 2 nhân viên “Người đánh giá” khác nhau xem xét cách triển khai mã.

   
   

   Một người thực hiện nó ở cấp độ cao, chẳng hạn như cách thực hiện toàn bộ nhiệm vụ và một người khác xem xét từng thay đổi trước khi chúng được thực hiện thành một tệp (như thực hiện lệnh git add -p).

   
   

4. LLM hoạt động tốt nhất khi chúng có thể tập trung vào một vấn đề so với nhiều vấn đề trong một lời nhắc. Ví dụ: nếu bạn yêu cầu GPT Pilot thực hiện 2 thay đổi khác nhau trong một mô tả, nó sẽ khó tập trung vào cả hai. Vì vậy, chúng tôi chia mỗi đầu vào của con người thành nhiều phần trong trường hợp đầu vào chứa nhiều yêu cầu khác nhau.

   
   

5. Nhật ký chi tiết giúp đỡ . Điều này hiện rất rõ ràng, nhưng ban đầu, chúng tôi không yêu cầu GPT-4 thêm bất kỳ nhật ký nào xung quanh mã. Giờ đây, GPT-4 sẽ tạo mã bằng tính năng ghi nhật ký chi tiết để khi bạn chạy ứng dụng và gặp lỗi, GPT-4 sẽ gỡ lỗi dễ dàng hơn nhiều khi thấy nhật ký nào đã được ghi và vị trí của nhật ký đó trong mã.

   
   

6. Việc chia cơ sở mã thành các tệp nhỏ hơn sẽ giúp ích rất nhiều . Đây cũng là một kết luận hiển nhiên, nhưng chúng tôi phải tìm hiểu nó. GPT-4 sẽ dễ dàng triển khai các tính năng và sửa lỗi hơn nhiều nếu mã được chia thành nhiều tệp thay vì một vài tệp lớn. Giống như con người chúng ta nghĩ – việc xử lý những đoạn mã nhỏ sẽ dễ dàng hơn nhiều so với những đoạn mã lớn. Chúng tôi làm điều đó bằng cách tạo ra các mức độ trừu tượng – hàm, lớp, v.v.

   
   

   Một trong những cách dễ nhất để khiến LLM tạo ra một bản tóm tắt dễ quản lý hơn chỉ là yêu cầu nó tạo nhiều mã mô-đun hơn và chia nó thành nhiều tệp hơn. Nó hoạt động rất tốt và kết quả cuối cùng cũng tốt hơn cho chúng tôi, những nhà phát triển.

   
   

7. Để con người có thể sửa mã, họ cần được hiển thị rõ ràng những gì được viết trong nhiệm vụ và ý tưởng đằng sau nó . Mục tiêu của GPT Pilot là thực hiện 90% tất cả các nhiệm vụ mã hóa và giao 10% còn lại cho con người. 10% này thường bao gồm các bản sửa lỗi hoặc những thay đổi nhỏ mà LLM khó nhận ra, nhưng đối với con người, đó có thể là một thay đổi đơn giản.

   
   

   Tuy nhiên, vấn đề là không dễ để nói cho con người biết điều gì không hoạt động và họ nên xem mã nào. Nếu GPT Pilot viết 3.000 dòng mã, thì nhà phát triển con người, nếu muốn trợ giúp GPT Pilot, cần phải hiểu toàn bộ cơ sở mã trước khi đi sâu vào mã thực tế.

   
   

   Trong các phiên bản tương lai của GPT Pilot, nhà phát triển con người sẽ có phần giải thích chi tiết về mã nào đã được thêm vào nhiệm vụ hiện tại và lý do đằng sau nó. Bằng cách này, bạn sẽ có thể trợ giúp GPT Pilot.

   
   

8. Con người thật lười biếng . LLM tốt hơn nên đặt câu hỏi cho con người hơn là để con người suy nghĩ về tất cả các lỗi có thể xảy ra. Một lần nữa, điều rất rõ ràng là khi nhìn lại, nhưng một trong những điều chúng tôi nhận thấy là mọi người sẵn sàng trả lời các câu hỏi mà GPT Pilot hỏi họ thay vì có trường nhập liệu mở để họ có thể viết phản hồi không bị giới hạn.

   
   

9. Thật khó để khiến một LLM có tư duy sáng tạo . Đây là một trong những bài học lớn nhất đối với tôi. Tôi nghĩ bạn có thể nhắc GPT-4 bằng cách cung cấp cho nó một số giải pháp mà nó đã sử dụng để khắc phục sự cố và yêu cầu nó nghĩ ra giải pháp khác. Tuy nhiên, điều này không hề dễ dàng như người ta tưởng.

   
   

   Điều cuối cùng chúng tôi làm là yêu cầu LLM liệt kê tất cả các giải pháp khả thi mà nó có thể nghĩ ra và lưu chúng vào bộ nhớ. Khi cần thử điều gì khác, chúng tôi đưa ra các giải pháp thay thế và yêu cầu nó thử một giải pháp khác nhưng cụ thể.

Ứng dụng được tạo bằng GPT Pilot

Hiện tại, bạn có thể tạo các ứng dụng đơn giản nhưng không hề tầm thường với GPT Pilot. Chúng tôi cũng đã thấy mọi người tạo ra những ứng dụng rất ấn tượng bằng GPT Pilot, chẳng hạn như một ứng dụng có thể tinh chỉnh mô hình ResNet để đếm số cây cọ và sau đó, khi bạn tải hình ảnh lên, hãy đếm số cây trong đó. Dưới đây là một số ứng dụng chúng tôi đã tạo cùng với mã, số liệu thống kê và bản trình diễn:

Phòng thí nghiệm nhanh chóng ( DEMO )

Hãy coi đây như Sân chơi OpenAI trên steroid – nó cho phép bạn tải cuộc trò chuyện từ một mảng JSON hoặc nhập thủ công, chạy cuộc trò chuyện với LLM X số lần, lưu cuộc trò chuyện vào cơ sở dữ liệu và tải lại. Chúng tôi thực sự sử dụng ứng dụng này khi chúng tôi thiết kế lời nhắc và muốn xem nó hoạt động như thế nào.

Playground không đủ tốt vì việc chạy lại nhiều lần một lời nhắc sẽ tốn thời gian. Với Nhắc Lab, bạn có thể chọn số lần chạy và để ứng dụng chạy lời nhắc nhiều lần.

Sau khi hoàn tất, bạn có thể phân tích kết quả. Điều này có thể hữu ích cho những người đang xây dựng ứng dụng AI và cần tối ưu hóa lời nhắc của họ.

• ⏳ Thời gian sử dụng: ~2 ngày
• 💾 Kho lưu trữ Github

Công cụ phân tích cơ sở dữ liệu SQLite ( DEMO )

Đây cũng là một ứng dụng chúng tôi sử dụng nội bộ để phân tích cơ sở dữ liệu SQLite cục bộ. Nó lấy dữ liệu từ cơ sở dữ liệu theo định dạng rất cụ thể cho cấu trúc cơ sở dữ liệu GPT Pilot nhưng có thể dễ dàng sửa đổi để phù hợp với các cấu trúc khác.

Nó đọc và tải lên cơ sở dữ liệu SQLite của bạn, chia các hàng theo một trường cụ thể, giải nén các hàng thành giá trị, tải dữ liệu hội thoại LLM vào một biểu mẫu và cho phép bạn chỉ cần thay đổi một trong các thông báo và gửi yêu cầu LLM tới GPT-4 để xem kết quả sẽ như thế nào.

Bằng cách này, bạn có thể phân tích các cuộc trò chuyện mà các đại lý của GPT Pilot có với LLM và dễ dàng khám phá điều gì sẽ xảy ra nếu các lời nhắc khác nhau.

• ⏳ Thời gian sử dụng: ~2 ngày
• 💾 Kho lưu trữ Github

Người thì thầm mã ( DEMO )

Code Whisper là một dự án thú vị mà chúng tôi đã tạo ra để giới thiệu. Ý tưởng là bạn có thể sử dụng nó để đặt câu hỏi LLM về cơ sở mã của mình. Bạn dán liên kết tới kho lưu trữ Github công khai.

Sau đó, nó sao chép kho lưu trữ, gửi các tệp liên quan đến LLM để phân tích, tạo mô tả cho từng tệp về chức năng của mã và lưu các mô tả đó vào cơ sở dữ liệu.

Sau đó, bạn có thể đặt câu hỏi cho ứng dụng về cơ sở mã và cơ sở mã sẽ hiển thị cho bạn câu trả lời. Trong bản demo này, chúng tôi sử dụng GPT-3.5.

• ⏳ Thời gian sử dụng: 7 giờ
• 💾 Kho lưu trữ Github

Lịch sử ngôi sao ( DEMO )

Tôi đã phát hành các dự án nguồn mở trong nhiều năm nay và tôi luôn muốn xem kho lưu trữ Github của mình phát triển nhanh như thế nào so với các kho lưu trữ thành công khác trên https://star-history.com/ . Vấn đề là trên Star History, tôi không thể phóng to biểu đồ, vì vậy một repo mới có 1.000 sao không thể so sánh với một repo lớn có 50.000 vì bạn không thể thấy repo lớn hơn hoạt động như thế nào khi bắt đầu .

Vì vậy, tôi đã yêu cầu GPT Pilot xây dựng chức năng này. Nó loại bỏ các kho lưu trữ Github dành cho những người ngắm sao, lưu chúng vào cơ sở dữ liệu, vẽ chúng trên biểu đồ và cho phép phóng to và thu nhỏ biểu đồ.

• ⏳ Thời gian sử dụng: 6 tiếng
• 💾 Kho lưu trữ Github

Phần kết luận

Tôi hy vọng bạn đã hiểu rõ hơn về tình trạng hiện tại, các vấn đề và phát hiện mà chúng tôi giải quyết tại GPT Pilot.

Vì vậy, để tóm tắt lại:

Chúng tôi nghĩ rằng một công cụ dành cho nhà phát triển AI thực sự phải dựa trên các trụ cột sau:

• Cần có con người để giám sát AI.

  
  

• Chúng ta nên cho phép AI lặp lại những sai lầm của chính nó.

  
  

• Việc phát triển phần mềm có thể được điều phối , việc này cần được triển khai trên một lớp phía trên LLM.

  
  

• Nhà phát triển AI phải có khả năng cấu trúc lại cơ sở mã vì trên thực tế, quá trình mã hóa không phải là một đường thẳng.

Cho đến nay, chúng ta đã học được rằng:

1. Mô tả ứng dụng ban đầu quan trọng hơn nhiều so với chúng tôi nghĩ

2. Mã hóa không phải là một đường thẳng, các đại lý có thể tự xem xét

3. LLM hoạt động tốt nhất khi chúng tập trung vào một vấn đề so với nhiều vấn đề trong một lời nhắc

4. Nhật ký chi tiết làm nên điều kỳ diệu

5. Việc chia cơ sở mã thành các tệp nhỏ hơn sẽ giúp ích rất nhiều

6. Để con người có thể sửa được mã

7. Chúng phải được thể hiện rõ ràng những gì đã được viết và ý tưởng đằng sau nó

8. Con người thật lười biếng

9. Thật khó để khiến LLM suy nghĩ sáng tạo

   
   

Bạn nghĩ sao? Bạn có nhận thấy bất kỳ hành vi nào trong số này khi tương tác với LLM hay bạn có quan điểm khác về bất kỳ hành vi nào trong số này?

Tôi sẽ rất vui khi nhận được phản hồi từ bạn, vì vậy hãy để lại nhận xét bên dưới hoặc gửi email cho tôi theo địa chỉ [email protected] .

Bạn có thể thử tạo ứng dụng có AI bằng GPT Pilot tại đây:

• Kho lưu trữ mã nguồn mở GPT Pilot
• Tiện ích mở rộng GPT Pilot VS Code

Nếu bạn thích bài đăng này, điều đó sẽ rất có ý nghĩa nếu bạn gắn dấu sao cho repo GPT Pilot Github và nếu bạn dùng thử, hãy cho chúng tôi biết suy nghĩ của bạn. Phản hồi của bạn thực sự quan trọng đối với toàn bộ Nhóm thí điểm GPT.

Cũng được xuất bản ở đây