CodeGen Geliştirme Aracı (GPT Pilot) Üzerinde 6 Ay Çalıştıktan Sonra Öğrendiğim Şey Bu

Son 6 aydır, yapay zeka ile kodlamayı gerçekten ne kadar otomatikleştirebileceğimizi anlamak için GPT Pilot ( https://github.com/Pythagora-io/gpt-pilot ) üzerinde çalışıyorum, bu yüzden öğrendiklerimizi paylaşmak istedim. şimdiye kadar ve ne kadar ileri gidebileceği.

GPT Pilot'u oluşturmaya başladığımda bunun nasıl tasavvur edildiğine dair bu blog yazısını yazdım. Şimdi revize edilmiş düşüncemi paylaşmak ve neyin işe yarayıp neyin yaramadığını incelemek istiyorum.

Son olarak, GPT Pilot ile oluşturulan uygulama örneklerini ve gerçek bir AI çifti programlayıcıyla nasıl uygulama oluşturabileceğinizi göreceksiniz.

GPT Pilot'un Arkasındaki Fikir Nedir?

GPT Pilot, bir otomatik tamamlama veya sohbet robotu değil , gerçek bir yapay zeka geliştiricisi olarak tasarlandı. Daha ziyade, uygulamanızın veya özelliğinizin nasıl oluşturulması gerektiğine dair bir plan oluşturan ve kodlamaya başlayan bir geliştiricidir. Kodlamanın çoğunu kendisi yapmak istiyor ancak takılıp kaldığında, verilen gereksinimler hakkında açıklamaya ihtiyaç duyduğunda veya kod incelemesi gerektiğinde sizden yardım istiyor.

Yapay Zeka Kıdemsiz Geliştirici Gibi mi? Veya…

Sık sık CodeGen GPT-4 tabanlı araçların bir yapay zeka geliştiricisi oluşturduklarını söylediğini görüyorum.

Her nasılsa bu konuda her zaman bir sorun yaşadım çünkü kodlama için ChatGPT'yi kullandığımda, bana yalnızca süper kıdemli bir kişinin verebileceği cevaplar ve fikirler veriyor; hiçbir kıdemsiz geliştiricinin kesinlikle kavrayamayacağı bir şey. Yine de hiçbir Yüksek Lisans, kıdemli bir geliştiricinin yapabileceği kadar iyi bir uygulama geliştiremez; ancak GPT-4'ün kodlamayla ilgili sahip olduğu bilgi, herhangi bir kıdemsiz geliştiricinin çok ötesindedir.

GPT-4'ün, yazılım geliştirmenin her aşaması hakkında, dünyadaki en kıdemli geliştirici gibi çok fazla bilgiye sahip olduğunu, ancak bir Japon balığı hafızasına sahip olduğunu söyleyebilirim. Onu bir odanın ortasında duran ve aynı anda yalnızca tek bir küçük eylemi yapabilen, ancak birçok eylemi birleştiremeyen ve tekrar tekrar çalışamayan insanüstü bir robot olarak hayal ediyorum. Bundan sonra ne yapması gerektiğini ona tam olarak anlatmalısınız.

GPT Pilot ile peşinde olduğumuz şey bu; Yüksek Lisans için, insanüstü robotun önceki eylemlerini gözden geçirerek sürekli çalışmasını, bir geri bildirim döngüsüne sahip olmasını ve sırayla ne yapması gerektiğini belirlemesini sağlayacak bir düşünce çerçevesi oluşturmak istiyoruz. üretime hazır bir uygulama oluşturmak olan nihai hedefi tamamlamak.

Yukarıda bahsettiğim blog yazısında GPT Pilot'un üzerine inşa edildiği ana sütunları özetledim. Ancak bunlar ekibimizin öğrendiklerine göre biraz değişti; işte revize edilen temel ilkeler:

1. Yalnızca yapay zeka yeterince iyi olmadığı için değil, aynı zamanda bir şeyin çalışma şeklini veya uygulandıktan sonra nasıl görüneceğini değiştirmek isteyebileceğiniz için yapay zekayı denetleyecek bir insana ihtiyaç vardır . Bir geliştiricinin veya ürün yöneticisinin, bir uygulamanın neye benzediğini gördükten sonra onu değiştirmeye karar vermesi yaygındır.

   
   

2. Veya başlangıçta beklediğinizden daha fazla uç durum olduğunu fark ediyorsunuz ve mevcut uygulamanızı yeniden düzenlemenin her sorunu düzeltmekten daha kolay olduğunu düşünüyorsunuz. Sorun, uygulamanın tamamını bitirdiğinizde ve ardından onu yeniden düzenlemeye çalıştığınızda ortaya çıkar; bu, her değişikliğin diğer tüm özellikleri etkileyeceği için daha da zorlaştığı zamandır.

   
   

   Öte yandan, değişikliklerinizi gerçekleştirmeden önce yeniden düzenleme işlemini yaparsanız, iyi yazılmış kodun yanı sıra sonraki özelliklere de devam edebilirsiniz. Bu nedenle bir yapay zeka geliştiricisinin, bir görev uygulandığında döngüde bir insanın bulunması çok önemlidir .

   
   

   Bu şekilde, insan, GPT Pilot bir sonraki göreve geçmeden önce her görevin uygulanmasını (tıpkı bir PR birleştirmeden önce yapılan kod incelemesi gibi) inceleyebilir. Bir insan GPT Pilot'a neyin yanlış olduğunu söylerse, görevin içindeki sorunları düzeltmek çok daha kolay olacaktır. Aynı zamanda Yüksek Lisans, görevde yapılması gerekenlerin ve şu ana kadar yapılanların bağlamına da sahiptir.

   
   

3. Yapay zeka kendi hatalarını yineleyebilir. Pek çok kişinin ChatGPT'nin kod yazma yeteneğini, ondan bir şeyi kodlamasını ilk istediğinizde ne kadar iyi sunduğuna göre değerlendirdiğini hissediyorum. Eğer çalışan bir kod üretmiyorsa çoğu kişi bunun etkileyici olmadığını düşünecektir. Gerçekte insanlar neredeyse hiçbir zaman ilk denemede çalışan kod yazmazlar . Bunun yerine kodu yazar, çalıştırır, hataları görür ve yinelersiniz. Bu tam olarak GPT Pilot'un GPT-4'ün yapmasını sağladığı şeydir; kodu yazdıktan sonra, GPT Pilot kodu çalıştırabilir, çıktıyı alabilir ve LLM'ye çıktının doğru olup olmadığını, bir şeyin düzeltilmesi gerekip gerekmediğini ve eğer öyleyse nasıl düzeltileceğini sorabilir. .

   
   

4. Yazılım geliştirme düzenlenebilir . Bir uygulama geliştirirken tüm geliştiricilerin geçtiği birçok tekrarlayan rutin vardır. Rutinlerden biri kod yazmak, çalıştırmak, hataları okumak, kodu değiştirmek, yeniden çalıştırmak vb. olabilir. Bir başka üst düzey rutin ise bir görevi almak, uygulamak, uygulamayı test etmek olabilir (tüm testler geçinceye kadar tekrarlayın) , incelemeye gönderin, sorunları düzeltin (inceleyici onaylayana kadar tekrarlayın) ve dağıtın. Döngüde akıllı bir karar vericimiz varsa (LLM gibi) bu rutinlerin çoğu düzenlenebilir.

   
   

5. Kodlama süreci düz bir çizgi değildir . GPT Pilot'un ilk sürümünü oluşturduğumuzda, görevlerin tekrarlanması, kodun uygulanması, düzeltilmesi ve devam edilmesi gerektiğini düşündük. Gerçekte, bir uygulamayı kodlarken sürekli ilerlemezsiniz; kodunuzu her zaman yeniden yazarsınız.

   
   

   Bazen kod tabanını yeniden düzenlersiniz çünkü ilk uygulamadan sonra bir şeyi uygulamanın daha iyi bir yolu olduğunu fark edersiniz. Diğer zamanlarda bunu gereksinimlerdeki bir değişiklik nedeniyle yaparsınız. 1. maddede bahsettiğim gibi, bir çözümün işe yaramadığını gördükten sonra bazen bir dizi değişikliği geri almanız, soruna alternatif bir çözüm düşünmeniz ve sorunu bu şekilde çözmeyi denemeniz gerekir.

   
   

   GPT Pilot'un veya herhangi bir yapay zeka geliştiricisinin geniş ölçekte çalışmasını sağlamak için geri dönmesini, alternatif bir yol seçmesini ve bir görevi yeniden uygulamasını sağlayacak bir mekanizmaya sahip olması gerekir.

Ne Öğrendik?

Yüksek Lisans genel olarak herkesin anlamaya çalıştığı yeni bir teknolojidir - nasıl çalışır, ne daha iyi yapılabilir, uygun istem mühendisliği nasıl yapılır vb. Yaklaşımımız, uygulama katmanını oluşturmaya çalışmak yerine uygulama katmanını oluşturmaya odaklanmaktır. Daha iyi sonuçlar elde etmek için LLM'ler .

Bunun nedeni, Yüksek Lisans'ların daha iyi olacağı ve eğer bir istemi optimize etmek için haftalarca çaba harcarsak, GPT'nin yeni sürümüyle bu sorunun tamamen çözülebileceğidir.

Bunun yerine, kullanıcı deneyiminin nasıl görünmesi gerektiğine ve LLM'nin sürekli çalışmasını, nihai çözüme giderek daha fazla yaklaşmasını sağlamak için kontrol etmek için hangi mekanizmalara ihtiyaç duyulduğuna odaklanıyoruz. İşte şu ana kadar öğrendiklerimiz:

1. Uygulamanın ilk açıklaması düşündüğümüzden çok daha önemli . Başlangıçtaki düşüncemiz, ilk açıklama belirsiz olsa bile, GPT Pilot'un insanın girdisiyle doğru yönde ilerleyebileceği ve çalışma çözümüne giderek daha fazla yaklaşabileceği yönündeydi.

   
   

   Ancak GPT Pilot'un düşüncesi, ilk açıklamadan başlayarak istemlerin tamamına yayılır. Ve bununla birlikte, ilk istemde yanıltıcı bir şey varsa, GPT Pilot'un sahip olduğu diğer tüm bilgiler yanlış yöne yönlendirecektir. Yani, onu baştan sona düzelttiğinizde, bu yanlış yolun o kadar derinlerine inecektir ki, onu doğru yola sokmak neredeyse imkânsız olacaktır.

   
   

   Şimdi, ben bunu yazarken, bu çok açık görünüyor, ama bu öğrenmemiz gereken bir şey; ilk açıklamaya daha çok odaklanmak. Bu nedenle, kodlamaya başlamadan önce proje gereksinimlerini ayrıntılı olarak belirlemek için sizinle birlikte çalışan "Spec Writer" adında yeni bir aracı oluşturduk.

   
   

2. Kodlama düz bir çizgi değildir . Yukarıda sütunlar bölümünde bahsettiğim gibi, yeniden düzenleme her zaman gerçekleşir ve GPT Pilot'un da bunu yapması gerekir. Bunun için henüz bir çözüm uygulamadık, ancak GPT Pilot'un karar ağacının etrafında işaretleyiciler oluşturma yeteneğinin eklenmesiyle işe yarayacak, böylece bir şey yolunda gitmediğinde işaretçileri inceleyebilir ve nerede olabileceğini düşünebilir. yanlış bir hareket yaptı.

   
   

3. Temsilciler kendilerini inceleyebilirler . Benim düşüncem, bir temsilcinin diğer temsilcinin yaptığını gözden geçirmesi durumunda bunun gereksiz olacağıydı çünkü aynı LLM aynı bilgiyi yeniden işliyor. Ancak bir temsilci başka bir temsilcinin çalışmasını incelediğinde, bunun inanılmaz derecede iyi çalıştığı ortaya çıktı. Kodun nasıl uygulandığını inceleyen 2 farklı "İnceleyici" aracımız var.

   
   

   Biri bunu tüm görevin nasıl uygulandığı gibi yüksek düzeyde yapar ve diğeri her değişikliği bir dosyaya yapılmadan önce inceler (git add -p yapmak gibi).

   
   

4. Yüksek Lisans'lar, tek bir istemde birden fazla soruna kıyasla tek bir soruna odaklanabildikleri zaman en iyi şekilde çalışırlar . Örneğin GPT Pilot'a tek bir açıklamada 2 farklı değişiklik yapmasını söylerseniz ikisine de odaklanmakta zorluk çekecektir. Bu nedenle, girdinin birkaç farklı istek içermesi durumunda her insan girdisini birden çok parçaya böleriz.

   
   

5. Ayrıntılı günlükler yardımcı olur . Bu artık çok açık, ancak başlangıçta GPT-4'e kodun etrafına herhangi bir günlük eklemesini söylemedik. Artık ayrıntılı günlük kaydıyla kod oluşturur; böylece uygulamayı çalıştırdığınızda ve bir hatayla karşılaştığınızda, GPT-4, hangi günlüklerin yazıldığını ve bu günlüklerin kodun neresinde olduğunu gördüğünde hata ayıklama işlemini çok daha kolay hale getirir.

   
   

6. Kod tabanını daha küçük dosyalara bölmek çok yardımcı olur . Bu da bariz bir sonuç ama bunu öğrenmemiz gerekiyordu. Kodun birkaç büyük dosya yerine birçok dosyaya bölünmesi durumunda GPT-4'ün özellikleri uygulaması ve hataları düzeltmesi çok daha kolaydır. Tıpkı biz insanların düşündüğü gibi, büyük kod parçalarını işlemek yerine küçük kod parçalarını işlemek çok daha kolaydır. Bunu, işlevler, sınıflar vb. gibi soyutlama düzeyleri yaratarak yaparız.

   
   

   LLM'nin daha yönetilebilir bir soyutlama oluşturmasını sağlamanın en kolay yollarından biri, ona daha modüler kod oluşturmasını ve onu daha fazla dosyaya bölmesini söylemektir. İnanılmaz derecede iyi çalışıyor ve sonuç biz geliştiriciler için de daha iyi.

   
   

7. Bir insanın kodu düzeltebilmesi için, görevde ne yazıldığının ve arkasındaki fikrin kendisine açıkça gösterilmesi gerekir . GPT Pilot'un hedefi tüm kodlama görevlerinin %90'ını yapmak, geri kalan %10'u ise insana bırakmaktır. Bu %10 genellikle LLM'nin fark etmekte zorlandığı düzeltmeleri veya küçük değişiklikleri içerir, ancak insan için bu basit bir değişiklik olabilir.

   
   

   Ancak sorun şu ki, insana neyin işe yaramadığını ve hangi koda bakması gerektiğini söylemek kolay değil. GPT Pilot 3.000 satır kod yazıyorsa, insan geliştiricinin GPT Pilot'a yardım etmek istiyorsa gerçek koda dalmadan önce kod tabanının tamamını anlaması gerekir.

   
   

   GPT Pilot'un gelecek sürümlerinde insan geliştirici, mevcut göreve hangi kodun eklendiğine ve bunun arkasındaki nedene ilişkin ayrıntılı bir açıklamaya sahip olacak. Bu şekilde GPT Pilot'a yardımcı olabileceksiniz.

   
   

8. İnsanlar tembeldir . Yüksek Lisans'ların, insanların olası tüm hatalar hakkında düşünmesine izin vermek yerine, insanlara sorular sorması daha iyidir. Geriye dönüp baktığımızda bunu çok açık bir şekilde görüyoruz ancak fark ettiğimiz şeylerden biri, insanların, kısıtlamasız geri bildirim yazabilecekleri açık uçlu bir giriş alanına sahip olmak yerine, GPT Pilot'un kendilerine sorduğu soruları yanıtlamaya çok daha istekli olmalarıydı.

   
   

9. Bir LLM'nin kalıpların dışında düşünmesini sağlamak zordur . Bu benim için en büyük öğrenmelerden biriydi. GPT-4'e, bir sorunu çözmek için halihazırda kullandığı birkaç çözümü vererek ve başka bir çözüm düşünmesini söyleyerek onu yönlendirebileceğinizi düşündüm. Ancak bu sanıldığı kadar kolay değildir.

   
   

   Sonunda yaptığımız şey, LLM'den aklına gelen tüm olası çözümleri listelemesini ve bunları belleğe kaydetmesini istemek oldu. Başka bir şey denememiz gerektiğinde alternatif çözümleri çıkardık ve ona farklı ama spesifik bir çözüm denemesini söyledik.

GPT Pilot ile Oluşturulan Uygulamalar

Şu anda GPT Pilot ile basit ama önemsiz olmayan uygulamalar oluşturabilirsiniz. Ayrıca insanların GPT Pilot ile çok etkileyici uygulamalar oluşturduğunu da gördük; örneğin, ResNet modelinde palmiye ağaçlarını sayacak şekilde ince ayar yapabilen ve ardından bir görsel yüklediğinizde içindeki ağaçları sayabilen bir uygulama. Kod, istatistikler ve demolarla birlikte oluşturduğumuz birkaç uygulamayı burada bulabilirsiniz:

İstem Laboratuvarı ( DEMO )

Bunu steroidler üzerinde OpenAI Playground olarak düşünün; bir JSON dizisinden bir konuşmayı yüklemenize veya manuel olarak girmenize, konuşmayı LLM X ile birkaç kez çalıştırmanıza, konuşmayı veritabanına kaydetmenize ve tekrar yüklemenize olanak tanır. aslında bir istem tasarladığımızda ve onun nasıl davrandığını görmek istediğimizde bu uygulamayı kullanırız.

Oyun Alanı yeterince iyi değil çünkü tek bir istemi tekrar tekrar çalıştırmak zaman alıyor. Prompt Lab ile kaç kez çalıştırılacağını seçebilir ve uygulamanın istemi tekrar tekrar çalıştırmasına izin verebilirsiniz.

Tamamlandığında sonuçları analiz edebilirsiniz. Bu, bir AI uygulaması geliştiren ve istemlerini optimize etmesi gereken kişiler için yararlı olabilir.

• ⏳ Harcanan süre: ~2 gün
• 💾 Github deposu

SQLite Veritabanı Analiz Aracı ( DEMO )

Bu aynı zamanda yerel bir SQLite veritabanını analiz etmek için dahili olarak kullandığımız bir uygulamadır. Verileri veritabanından GPT Pilot veritabanı yapısına çok özel bir formatta çeker ancak diğer yapılara uyacak şekilde kolaylıkla değiştirilebilir.

SQLite veritabanınızı okur ve yükler, satırları belirli bir alana göre böler, satırları değerler halinde açar, LLM konuşma verilerini bir forma yükler ve mesajlardan birini değiştirmenizi ve LLM isteğini GPT-4'e göndermenizi sağlar. sonuçların nasıl görüneceğini görmek için.

Bu şekilde, GPT Pilot temsilcilerinin LLM ile yaptığı görüşmeleri analiz edebilir ve istemlerin farklı olması durumunda ne olacağını kolayca keşfedebilirsiniz.

• ⏳ Harcanan süre: ~2 gün
• 💾 Github deposu

Kod Fısıldayan ( DEMO )

Code Whisper, sergilemek için örnek olarak oluşturduğumuz eğlenceli bir projedir. Buradaki fikir, bunu LLM'ye kod tabanınız hakkında sorular sormak için kullanabilmenizdir. Bağlantıyı herkese açık bir Github deposuna yapıştırırsınız.

Daha sonra depoyu klonlar, ilgili dosyaları analiz için LLM'ye gönderir, bu da her dosya için kodun ne yaptığına ilişkin bir açıklama oluşturur ve bu açıklamaları veritabanına kaydeder.

Bundan sonra uygulamaya kod tabanı hakkında sorular sorabilirsiniz ve kod tabanı size yanıtı gösterir. Bu demoda GPT-3.5 kullanıyoruz.

• ⏳ Harcanan süre: 7 saat
• 💾 Github deposu

Yıldız Tarihi ( DEMO )

Yıllardır açık kaynaklı projeler yayınlıyorum ve her zaman Github depomun https://star-history.com/ adresindeki diğer başarılı depolarla karşılaştırıldığında ne kadar hızlı büyüdüğünü görmek istedim. Sorun şu ki, Yıldız Geçmişi'nde grafiği yakınlaştıramıyorum, bu nedenle 1.000 yıldızlı yeni bir repo, 50.000 yıldızlı büyük bir repo ile karşılaştırılamaz çünkü daha büyük repo'nun başlangıçta nasıl olduğunu göremezsiniz .

Bu yüzden GPT Pilot'tan bu işlevi geliştirmesini istedim. Hayalperestler için Github depolarını sıyırır, bunları veritabanına kaydeder, bir grafik üzerinde çizer ve grafiğin yakınlaştırılıp uzaklaştırılmasını sağlar.

• ⏳ Harcanan süre: 6 saat
• 💾 Github deposu

Çözüm

Umarım GPT Pilot'ta ele aldığımız mevcut durum, sorunlar ve bulgular hakkında biraz fikir edinmişsinizdir.

Özetlemek gerekirse:

Gerçek bir yapay zeka geliştirici aracının aşağıdaki temellere dayanması gerektiğini düşünüyoruz:

• Yapay zekayı denetleyecek bir insana ihtiyaç var.

  
  

• Yapay zekanın kendi hatalarını yinelemesini sağlamalıyız.

  
  

• Yazılım geliştirme, LLM'lerin üzerindeki bir katmanda uygulanması gereken şekilde düzenlenebilir .

  
  

• Yapay zeka geliştiricisinin kod tabanını yeniden düzenleyebilmesi gerekir çünkü gerçekte kodlama süreci düz bir çizgi değildir.

Şu ana kadar şunu öğrendik:

1. İlk uygulama açıklaması düşündüğümüzden çok daha önemli

2. Kodlama düz bir çizgi değildir; temsilciler kendilerini gözden geçirebilir

3. Yüksek Lisans'lar, tek bir istemde birden fazla soruna kıyasla tek bir soruna odaklandıklarında en iyi şekilde çalışırlar

4. Ayrıntılı günlükler mucizeler yaratır

5. Kod tabanını daha küçük dosyalara bölmek çok yardımcı olur

6. Bir insanın kodu düzeltebilmesi için

7. Onlara ne yazıldığı ve bunun arkasındaki fikir açıkça gösterilmelidir.

8. İnsanlar tembeldir

9. Yüksek Lisans'ın kalıpların dışında düşünmesini sağlamak zor

   
   

Ne düşünüyorsun? Yüksek Lisans'larla etkileşimlerinizde bu davranışlardan herhangi birini fark ettiniz mi veya bunlardan herhangi biri hakkında farklı bir fikriniz var mı?

Sizden haber almak beni çok mutlu edecektir, bu yüzden aşağıya bir yorum bırakın veya bana [email protected] adresinden bir e-posta gönderin.

GPT Pilot ile yapay zekaya sahip bir uygulama oluşturmayı burada deneyebilirsiniz:

• GPT Pilot açık kaynak deposu
• GPT Pilot VS Kodu uzantısı

Bu gönderiyi beğendiyseniz GPT Pilot Github deposuna yıldız eklemeniz çok anlamlı olacaktır ve denerseniz ne düşündüğünüzü bize bildirin. Geri bildiriminiz tüm GPT Pilot Ekibi için gerçekten önemlidir.

Burada da yayınlandı