500 Milyon GPT Tokenı İşledikten Sonra Edinilen Dersler

 (kenkantzer.com)
4 puan yazan GN⁺ 2024-04-14 | 1 yorum | WhatsApp'ta paylaş
  • Truss, son 6 ayda LLM odaklı özellikler işletirken OpenAI modelleriyle 500 milyondan fazla token işledi ve B2B metin özetleme, analiz ve çıkarımda gerçekten karşılaştığı sınırları derledi
  • Prompt'lar ne kadar çok ayrıntılı talimat içerirse o kadar istikrarlı olmadı; GPT'nin zaten bildiği genel bilgilerde kısa ve daha az spesifik talimatlar bazen daha iyi sonuç verdi
  • Langchain, JSON mode, function calling ve assistants olmadan da yalnızca chat API ve tek bir JSON çıkarım fonksiyonuyla birçok özellik işletildi; temel kod sadece 40 satırlık bir fonksiyon ve hata yönetimiyle otomatik kırpmadan ibaretti
  • GPT, “yoksa boş değer döndür” gibi null hipotezi işlemlerinde ve uzun çıktılarda zayıftı; GPT-4'ün 128k giriş penceresinden ayrı olarak çıktı hâlâ 4k seviyesinde kalıyor
  • RAG ve vektör DB, Truss'un sınırlı metin çıkarım işleri için pek uygun değildi; tüm bağlamı vererek yapılan analiz, özetleme ve çıkarım güvenilir olsa da giriş boş olduğunda veya ilgili bilgi olmadığında sorunlar büyüyor

Kullanım kapsamı ve varsayımlar

  • Truss, son 6 ay içinde birkaç LLM odaklı özellik yayınladı ve kullanım miktarı tahminen 500 milyon tokenı biraz aştı
  • Kullanılan modeller OpenAI ailesinden; token kullanım dağılımı GPT-4 %85, GPT-3.5 %15
  • Ele alınan veri yalnızca metin; gpt-4-vision, Sora, Whisper gibi metin dışı özellikler buna dahil değil
  • Ürün bağlamı B2B ve başlıca işler özetleme, analiz ve çıkarım
  • 500 milyon token yaklaşık 750 bin sayfa metne karşılık geliyor

Prompt'lar daha az spesifik olduğunda daha iyi olabilir

  • GPT'nin zaten bildiği genel bilgiler için aşırı derecede kesin listeler ve talimatlar vermek sonuçları kötüleştirebildi
  • Bir pipeline, metin bloklarının ABD'deki 50 eyaletten hangisiyle ya da federal hükümetle ilgili olduğunu sınıflandırmak zorundaydı
    • İlk prompt, locality_id alanına 50 eyaletin ve federalin ID listesini JSON biçiminde verip seçim yaptırıyordu
    • Bu yaklaşım yaklaşık %98+ çalıştı, ancak hata sayısı ek inceleme gerektirecek kadar fazlaydı
  • name adlı başka bir alan ise açıkça istenmemesine rağmen doğru eyaletin tam adını istikrarlı biçimde döndürdü
    • Daha sonra name içinde çıkan dizeyi arayıp eyaleti bulma yöntemine geçilince iyi çalıştı
  • Daha iyi yaklaşım, “50 eyaleti biliyorsun; ilgili eyaletin tam adını veya Federal döndür” gibi sağduyuya bırakan bir prompt oldu
  • Ek gözlemler de vardı
    • Hatalar Maryland, Maine, Massachusetts, Michigan gibi M ile başlayan eyaletlerde daha sık görüldü
    • ID'nin bir listeden seçildiği durumda, her eyaleti ayrı satıra koyan okunaklı JSON görünümü, virgülle devam eden bir listeden daha az kafa karıştırıcıydı

API ve soyutlamalar basit kaldı

  • Langchain bu örnekte erken yapılmış bir soyutlama gibiydi ve milyonlarca token ile 3-4 farklı production özellikten sonra bile openai_service dosyasında sadece 40 satırlık tek bir fonksiyon kaldı
  • Gerçekte kullanılan API yalnızca chat idi
    • Her zaman JSON çıkarıldı
    • JSON mode, function calling ve assistants gerekli değildi
    • System prompt da kullanılmadı
    • gpt-4-turbo çıktığında kod tabanında sadece tek bir string değiştirildi
  • Fonksiyonun büyük kısmı OpenAI API'nin 500 hataları veya socket kapanması gibi durumlar için hata yönetiminden sorumluydu
    • Bu tür hatalar zamanla iyileşti ve OpenAI üzerindeki yük düşünülünce şaşırtıcı değildi
  • Bağlam uzunluğu sınırı, kendi otomatik kırpma mekanizmasıyla ele alındı
    • Dize uzunluğu model_context_size * 3 değerinden büyükse kırpıldı
    • Nokta veya rakam sayısı çok olduğunda token oranı 3 karaktere 1 tokendan daha düşük olabildiği için hata oluşabiliyordu
    • context_length_exceeded gelirse model_context_size * 3 / 1.3 ölçütüyle yeniden kırpılıp tekrar deneniyordu

Streaming UX'in değeri hafife alınamaz

  • Streaming API ile gecikmeyi azaltıp kullanıcıya değişken hızda giren karakterler göstermek ilk başta oyuncak gibi görünüyordu
  • Gerçek kullanıcılar değişken hızlı “yazıyor” göstergesini çok olumlu karşıladı
  • Bu deneyim, yapay zekada fare/imleç UX'ine denk gelen bir an gibi hissettirdi

Boş sonuçlar ve uzun çıktılar zayıf nokta

  • “Bulamazsan boş çıktı döndür” ifadesi, en çok hataya yol açan prompt kalıplarından biriydi
    • Buradaki amaç gerçekten hiçbir şey döndürmemek değil, {value: ""} gibi boş değer ifadesi döndürmekti
    • Sorun çıktı sınırı değil, daha çok null hipotezini ayırt etme güçlüğüydü
  • GPT, boş değer döndürmesi gerektiğinde halüsinasyonu seçebiliyor; tersine, güveni düştüğünde boş değeri gereğinden sık de döndürebiliyordu
  • Metin bloğunun boş olabildiği bir bug varken halüsinasyon ciddi biçimde arttı
    • Örnek olarak Sunshine Bakery, Golden Grain Bakery, Bliss Bakery gibi sahte fırın adları üretildi
    • Çözüm, metin yoksa prompt'u hiç göndermemek oldu
  • GPT-4 giriş tarafında 128k tokenlık bir pencereye sahip olabilse de çıktı penceresi hâlâ 4k seviyesinde
    • “context window” ifadesi giriş ve çıkışı birbirine karıştırmaya müsait
  • JSON nesne listesi döndürtülürken, nesneler basit olsa bile 10'u aşmak zordu
    • 15 nesne istendiğinde başarının yalnızca yaklaşık %15 olduğu tahmin edildi
    • 10 civarında durduğunda bile çıktı sadece 700-800 token oluyordu
  • Her seferinde birer tane isteyip önceki sonuçları yeniden girdiye vererek çıktı sınırı aşılabilir, ancak bu durumda GPT ile kulaktan kulağa oyunu oynanmış oluyor ve Langchain benzeri araçlarla uğraşmak gerekiyor

RAG ve vektör DB bu kullanım senaryosuna pek uygun değil

  • Vektör DB ve RAG/embedding, Truss örneğinde çoğu zaman işe yaramadı
  • Vektör DB ve RAG'nin daha çok aramaya, hem de Google/Bing gibi gerçek aramaya uygun olduğu düşünülüyor
  • Temel sorun ilgililik ölçütü
    • İlgililik için net bir cutoff yok
    • Cohere'in rerank çözümü veya özel heuristics kullanılabilir, ancak bunlar kararlı değil
    • Alakasız sonuçların aramayı kirletmesi ya da fazla muhafazakâr davranıp önemli sonuçların kaçırılması riski var
  • Vektörleri genel veriden ayrı, uzmanlaşmış ve kapalı bir DB'de tutmak da kayıp yaratıyor
    • Google/Bing ölçeğinde olunmadıkça bağlam kaybının getirdiği ödün buna değmeyebilir
  • İş uygulamalarındaki aramada kullanıcılar çoğu zaman alan uzmanı oluyor
    • Kullanıcının doğrudan yazmadığı anlamları tahmin edip döndüren anlamsal aramayı sevdikleri düşünülmüyor
  • Çoğu arama senaryosunda, LLM'i sıradan bir completion prompt ile kullanıp kullanıcı sorgusunu faceted search, karmaşık sorgu ya da SQL'e çevirmek daha iyi olabilir
    • Bu yaklaşım RAG değil

Yeterli bağlam olduğunda halüsinasyon ciddi ölçüde azalıyor

  • Truss'un kullanım senaryolarının çoğu “bir metin bloğu verip içinden bir şey çıkarmak” biçiminde
  • Metinde geçen şirket adları istendiğinde GPT genelde rastgele şirketler döndürmüyor
    • Ancak metinde şirket yoksa null hipotezi sorunu yeniden ortaya çıkıyor
  • Kodda da GPT, verilen kod bloğunu yeniden yazarken değişken uydurma veya ortada rastgele yazım hataları ekleme anlamında pek halüsinasyon yapmıyor
    • Ama ondan bir şey oluşturması istendiğinde standart kütüphanede olmayan fonksiyonlar uydurabiliyor
    • Bu da yine “bilmiyorum” diyememe sorununa daha yakın
  • Tüm bağlam verilip analiz, özetleme ve çıkarım yaptırılan görevlerde oldukça güvenilirdi
  • Yapı, iyi veri girildiğinde iyi GPT token çıktısı alınmasına daha yakın

Geleceğe dair değerlendirme

  • Mevcut transformer yaklaşımı, internet verisi ve milyarlarca dolarlık altyapı erişimiyle tek başına AGI'ye ulaşılamayacağı düşünülüyor
  • GPT-4 pazarlama değil, %100 faydalı bir teknoloji ve hâlâ internetin ilk dönemlerine benzer bir aşamada görülüyor
    • Herkesi işten çıkaracak bir teknoloji değil
    • Daha önce yalnızca Google'ın erişebildiği ML/AI alanına giriş eşiğini düşürmede büyük etkisi var
  • Claude, Gemini gibi modeller için sıkı bir A/B testi yapılmadı
    • Günlük kodlama sırasında denendiğinde, niyeti sezme konusundaki ince ayrıntılarda GPT-4'e o kadar yakın olmadıkları hissedildi
  • LLM/AI akışındaki her şeyi takip etmek gerekmediği düşünülüyor
    • The Bitter Lesson açısından genel model performansındaki artışlar özelleşmiş iyileştirmelerden daha önemliyse, sadece GPT-5'in çıkıp çıkmadığını takip etmek yeterli olabilir
    • Sora gibi ayrı alanlar dışında OpenAI'nin ara sürümleri çoğunlukla gürültü olarak görülüyor
  • GPT-5 her şeyi değiştirmekten çok kademeli bir iyileşme olabilir
    • GPT-3'ten GPT-3.5'e geçerken eğitim yoğunluğu 2 kat artırılırsa performansın 2,2 kat artacağı gibi süperlineer bir gelişme beklenmişti
    • Gerçekte ise iyileşme daha çok logaritmik görünüyor ve küçük ilerlemeler için token hızıyla token başı maliyetin geometrik biçimde arttığı düşünülüyor
  • GPT-4, mevcut görev seti için optimum nokta olabilir
    • GPT-3.5 yerine GPT-4 için 20 kat maliyet ödemeye razı olunsa da GPT-4'ten GPT-5'e geçmek için token başına 20 kat ödeme yapılmayacağı düşünülüyor
    • GPT-5 bunu bozabilir de; ya da iPhone 4'ten iPhone 5'e geçiş kadar sınırlı bir sıçrama olabilir

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-14
Hacker News yorumları

  • Sorumlu olduğum ekip her ay 5 milyar+ token işliyor ve bu sayı artmaya devam ediyor; öğrendiğimiz birkaç şey var.
    Birincisi, çok erken yapılan çok fazla soyutlama var. Langchain gibi araçlar bir gün işe yarayabilir, ama sonuçta prompt yalnızca bir API çağrısıdır; LLM çağrılarını özel bir şey gibi ele almak yerine kararsız bir API çağrısı gibi standart kodla ele almak daha kolay.
    İkincisi, halüsinasyon kesinlikle büyük bir sorun. Özetleme testlerde oldukça sağlam, ama akıl yürütme gerçekten zor; kullanıcı girdisini alıp bir sonraki eyleme LLM’in karar vermesini sağlayan eylem modellerinde özellikle bağlamı anlama ve “emin değilim” dedirtme kısmı zor. Yine de bunun yapılabiliyor olması başlı başına oyunun kurallarını değiştiriyor.
    Üçüncüsü, yazara kıyasla biraz daha “oyunun kurallarını değiştiriyor” tarafındayım ama dünyanın sonunun geldiğini düşünmüyorum. Bazı meslekler ciddi etkilenecek ve botların platformlarda kamuoyunu manipüle ettiği birkaç zorlu yıl gelebilir. Genel olarak internet gibi bir kırılmadan çok bir yetenek yükseltici gibi görünüyor.
    Kişisel olarak 2000’lerdeki DevOps değişimine benziyor. Artık dağıtıma yardım eden büyük, özel bir ekibe ihtiyaç yok; az sayıda uzman işe alınıyor ve çoğu şey için hazır çözümler satın alınıyor. Benzer şekilde bazı makine öğrenimi işleri de benim gibi web geliştiricilerinin kolayca uygulayabileceği hale geldi.

    • LLM’lerin modern geliştirme akışında nasıl konumlandırılması gerektiğini anlatırken bu benzetme yararlı. Çünkü bunun her derde deva değil, bir ödünleşim olduğunu gösteriyor.
      DevOps’un evriminde de ödünleşimler vardı. Örneğin “sadece AWS RDS kullan” yaklaşımının doğrudan sonucu olarak veritabanı yönetimi gibi temel yetkinlikler kayboldu ve bulut faturaları da patladı. Özellikle veri ölçeği veya bölgesel karmaşıklığı büyük olmayan startup’ların operasyon maliyetleri de arttı; bu gidişatın GitLab’in büyük kesintisine benzer kazalara da yol açtığını düşünüyorum.
    • “Emin değilim” dedirtmek, dil modelinin kendi işlevine daha yakın bir mesele. Çıktıya ulaşıldığında, hesaplamanın doğasında bulunan belirsizlik tahminin içinde kaybolur.
      Yazı tura sonucu tahmin etmeniz istenip “yazı” diye cevap verdiğinizde, cevaplamadan önce Pr[yazı] = .5 gibi bir belirsizlikten söz edebilirsiniz; ancak fiili tahmin ve para atışının sonucunda o belirsizliğin kaybolmasına benzer. LLM’de de token’ın nihai tahmininde hesaplama sırasındaki belirsizlik kaybolduğu için, tahminin kendisi belirsizlik ifadesi değilse “anlamadım” çıktısı neredeyse hiç gelmez. Ancak bunun nedeni en başta anlamayıp tahmin etmesidir.
    • DevOps benzetmesini daha önce hiç düşünmemiştim; bir şeyler yerine oturdu ve bu fikirden yola çıkarak az önce bir yazı yazdım: https://kenkantzer.com/gpt-is-the-heroku-of-ai
      Temelde GPT’yi yapay zeka operasyonlarında PaaS/Heroku/Render benzeri bir eşdeğer olarak kullandığımızı düşünüyorum.
    • “İnternet gibi bir kırılmadan çok yetenek yükseltici” ifadesine katılıyorum. Müşteriler de büyük modellerin maliyetine karşı çıktılarda fiyat şoku yaşıyor. Zamanla maliyetler düşecektir.
    • Özetlemenin sağlam ama akıl yürütmenin zor olduğu sözüne katılıyorum. Benzetme isteme yöntemi ilginç ve şaşırtıcı derecede yararlıydı.

  • “Biz her zaman JSON çıkarıyoruz. JSON moduna gerek yok” kısmını merak ettim. Benim durumumda oldukça iyi çalıştı.
    “Ders 4: GPT sıfır hipotezi kurmakta gerçekten kötü” sözüne ise gerçekten katılıyorum. Daha dün metin düzeltme kuralları prompt’unu test ederken sona “Herhangi bir kural metne uygulanmıyorsa, orijinal metni değiştirmeden döndür” yazmıştım.
    Kuralların hiçbirinin uygulanmadığı metne ChatGPT’nin ne cevap verdiğini biliyor musunuz? Aynen “The original text without any changes” dizesiydi.

    • Huysuz bir cinin dileğin lafzını kelimesi kelimesine yorumlayıp lanetli dilekleri gerçekleştirdiği hikâyeler vardır; şu anda elimizde olan şey bu. Uzun süredir görüntü üretim modellerine prompt yazanlar bunu bir ölçüde sezdi, ama LLM’lerle gelenler için epey şaşırtıcı olabilir.
      Bir keresinde tarot kartları için güzel bir bahçede şarap içen üç kadının görüntüsünü üretirken prompt’un sonuna “lush vegetation” eklemiştim; lush kelimesinin çift anlamı yüzünden sahne zarif bir atmosferden kırmızı burunlu, parti düşkünü üniversiteli kız havasına dönmüştü.
    • Bunu “bizim yöntemimiz iyi çalışıyor, bu yüzden JSON modunu kullanmamıza gerek yok” anlamında okudum. Bizim şirkette de durum aynı. 1 yıldır prodüksiyonda ve değiştirmeye gerek kalmadı. Prompt’umuz GPT-3.5’in her zaman JSON üretmesini sağlama konusunda oldukça etkili.
    • Pasta süsleme fiyaskosu sitelerine bakarsanız, insanların da bu tür hataları sürekli yaptığını görürsünüz.

  • Daha iyi prompt yazarsanız daha ucuz modeller kullanabilirsiniz.
    “Hiçbir şey bulamazsan hiçbir şey döndürme” LLM’e bir kaçış yolu veren seviye 0 yaklaşımıdır. Daha yumuşak bir çıkış yolu vermek daha iyi. Örneğin “Kesin bir ifade kurmak için yeterli bilgi yoksa, bunu yaptığını açıkça belirtip hipotezin dayanağını ve mantıksal temelini yazdığın sürece bir hipotez kurabilirsin” gibi yazıp, en sonda kendi cevabını değerlendirmesini sağlayabilirsiniz.

    • Prompt’lar soyut biçimde geliştirilmemeli. Prompt’un amacı, modelin iç temsillerini etkinleştirerek görevi en iyi şekilde yapmasını sağlamaktır.
      Otomatik bir yöntem yoksa, çeşitli girdiler karşısında modelin tepkisini yinelemeli olarak test ederek isteği nasıl yorumladığını, nerede başarısız olduğunu anlamalı ve bu boşlukları kapatmalısınız. Hatta modelin nothing kelimesinin ne anlama geldiğini bilip bilmediğini bile doğrulamalısınız.

  • LLM alanındaki ilk 3 hizmetin hepsine aboneyim ve sık sık aynı prompt’u deniyorum; GPT-4 tarafı çok tek taraflı biçimde avantajlı. GPT-4’ün çıkmasının üzerinden 1 yıl geçtiğini ve bu arada birkaç güncelleme aldığını hesaba katsak bile şaşırtıcı.
    En azından benim kullanım desenimde halüsinasyonlar da nadir. Buna karşılık Claude, kod yazarken var olmayan ama makul görünen API’leri oldukça kolay uyduruyor. GPT-4, doğru olduğunu bildiğinde daha inatçı ve daha az “evet efendimci”. Bu tür farklar metriklerde pek yakalanmıyor; kişisel olarak kullanınca görülüyor.

    • Benim durumumda Claude 3 Opus, GPT-4’ten daha iyiydi. Özellikle açıklamaları daha iyi yapıyor ve daha önemlisi daha kapsamlı ele alıyor.
      Kodlama işlerinde de ona kod yazdırmaktansa bir konu ya da kod hakkında açıklama istiyorum; çok daha nüanslı yanıtlar verme eğiliminde. Uzun bir metin verip sohbet edince Claude Opus’un içeriği daha derinden anladığı hissi oluşuyor; GPT-4 verilen metni özetleme tarafında kalırken Claude daha iyi genişletip çıkarım yapıyor.
    • Claude Opus ile mi karşılaştırdığını, yoksa daha alt varyantlarla mı karşılaştırdığını merak ediyorum. Opus İngilizce metin üretiminde gerçekten hoşuma gidiyor.
    • GPT-4, biçimi kötü, bilgisi eksik veya yapısı dağınık prompt’larla daha iyi başa çıkıyor. Büyük prompt’u akıllıca yapılandırmazsanız Claude ne istediğiniz konusunda kafası karışabiliyor.
      Buna karşın iyi kurgulanmış prompt’larda Claude Opus, GPT-4’ten daha iyi çıktılar üretme eğiliminde. Claude daha esnek ve uzun yanıtlar verirken, ChatGPT/GPT-4 her zaman kendine özgü kısa ve “tipik” yanıtlar gibi duyuluyor.
    • Benim deneyimim bunun tersiydi. Birden fazla hizmete aboneyim ve aynı soruları kopyalayıp yapıştırıyorum; yazılım geliştirmeyle ilgili sorularda Claude Opus çok daha önde, artık GPT-4 kullanmama gerek kalmayabilir diye düşünüyorum.
      İstediğim kod örneklerinde GPT-4’ün ürettiği kod çoğu zaman derlenmiyordu bile; Claude’da bu neredeyse hiç olmadı.
    • Ben de üç hizmetin hepsine aboneyim ve aynı şekilde karşılaştırıyorum. Özellikle yeni bir sürüm çıktığında.
      Son zamanlarda kullandığım turnusol testi şu: “Austin’e 200 mil mesafe içinde sıra dışı 10 bar söyle.” Bu hepsi için inanılmaz zor; GPT-4 fena olmayan şekilde yaklaştı, Claude ise sadece uydurdu, Gemini ise tamamen dağıldı.

  • GPT çok harika, ama yazıdaki iki paragrafın yorumuna kesinlikle katılmıyorum.
    “GPT, 50 eyaleti açıkça biliyorsun; bu buna karşılık gelen eyaletin tam adını ver ya da ABD hükümetine karşılık geliyorsa Federal diye yanıtla” gibi bir yaklaşımın daha iyi olacağı şeklinde özetlenebilir.
    Ancak daha muğlak söylendiğinde GPT’nin kalitesinin ve genellemesinin iyileşmesini yüksek seviyeli delegasyon/düşünmenin tipik bir işareti olarak yorumlamak bana aşırı geliyor. Doğal dil, GPT için en olası çıktıdır. Çünkü eğitim aldığı metinlere benzer. Bu durumda geliştirici sadece GPT’nin iyi olduğu tarafa daha çok yaslanmış; ona daha fazla iş yaptırmış değil.
    GPT’yi başarısız kılan pek çok basit iş var. Harf değiştirme, kasıtlı yazım hataları gibi işler GPT için çok zordur. ID eşleme de aynıdır; özellikle eğitim sırasında gördüğü eşlemelerden çok farklıysa daha da böyledir. Örneğin ISO olmayan ülke kodları gibi benzer üç harfli kodlar buna girer.
    İlginç olan, GPT’nin eşlemeyi “anlıyor” olmasıdır. Bence asıl yüksek boyutlu örüntü eşlemenin gerçek ipucu da bu.

    • Ya da sadece eşlemeyi ezberliyor olabilir. Birebir yeniden üretiyor anlamında değil; daha önce gördüğü eşlemelere benzer bir vektöre sahip olduğu anlamında.

  • ‘null’ sorunu için ipucu: LLM’ler token üretmek üzere tasarlanmıştır; token üretmemek üzere değil.
    Bu yüzden “hiçbir şey döndürme” demek yerine sonuç olmadığında “XYZ’nin varsayılan değerini döndür” deyip, eyalet adı arar gibi sonuçta o varsayılan değeri, örneğin XYZ’yi metin olarak arayabilirsiniz.
    Ayrıca sistem prompt’u çok işe yarayabilir. Temelde LLM’ye X rolünü oynatma fırsatıdır. Sistem prompt’unu doğrudan geçmeye izin verilse iyi olurdu, ama yine de hiç olmamasından iyidir.

  • GPT’nin 10’dan fazla JSON nesnesi listesini düzgün döndürememesi bir prompt sorunu. Ben doğru sırayla 200’e kadar öğeyi istikrarlı şekilde döndürmesini sağladım.
    Püf noktası liste hiç kullanmamak ve çıktıda "item1": {...} gibi JSON anahtarları kullanmak. Belirli bir girdi için 0~n adet çıktı olduğunda değer olarak liste kullanılabilir.

    • Kullanıcının, eksik listeyle yanıt vermeyi kaba ve aşağılayıcı sayan bir kültürden geldiğini söylüyorsunuz.
    • Biraz daha ayrıntı verebilirseniz iyi olur. Şu anda bu sorun yüzünden kafayı yiyorum.
      GPT-4’e tanımlı bir yapıya sahip mevcut öğe listesi verip şema dönüşümü gibi bir şekilde JSON’a çevirmesini isterseniz bunu bütün gün iyi yapar. Ama herhangi bir tür çıkarım gerektiğinde ve fiilen kendi listesini oluşturması gerektiğinde çok sınırlı bir alt küme veriyor.
      Diğer LLM’lerde de benzer sorun var. Nasıl yaklaştığınızı çok merak ediyorum.

  • “Bir metin bloğundan şirket adlarını çıkar” gibi işler iki adıma bölünebilir.
    Önce “Bu metin bloğunda bir şirketten bahsediliyor mu?” diye sorun; hayırsa null sonucunu almış olursunuz. Evetse “Bu metin bloğundaki şirket adlarını listele” dersiniz.

  • Kişisel yazma uygulamamda OpenAI modellerini kullanıyorum ve bu yazı gerçekten çok isabetli. “Prompt ne kadar azsa o kadar iyi” şeklindeki Lesson 1 ile ilgili öğrendiğim bir şey var.
    Notlar için akıllı arama özelliği geliştirirken ChatGPT’nin yapılandırılmış JSON verisi döndürmesini sağlamaya çalıştım. Örneğin “Son 2 yıl içinde Haskell’den bahseden ve taslak olarak işaretlenmiş tüm notlarımı ver” diye sorup, ChatGPT’nin ne döndüreceğine kendisinin karar vermesini istedim. Bu ancak bazen çalıştı.
    Bunun yerine verileri bir SQLite veritabanına koyup ChatGPT’ye şemayı gönderdim ve istediğim sonucu döndüren sorguyu yazmasını istedim; çok daha iyi çalıştı.

    • Bu iş için LLM’den çok veritabanı ve iyi arama filtreleri daha uygun görünüyor.
    • response_format=json_object kullanmayı denediniz mi merak ediyorum.
      Yapılandırılmış yanıt almak için fonksiyon çağrısı daha uygundu, ama sadece JSON gövdesi almaktan daha fazla kısıtı var.

  • Çok kesin talimat verince doğruluğun düşmesine ilişkin örnek, bu sistemlerin nasıl çalıştığına dair kaba anlayışıma göre mantıklı.
    Eyalet listesinin tamamını koyarsanız tüm eyaletlere ait vektörleri bir ölçüde etkinleştirmiş olursunuz. Sadece “state” deyip ilettiğiniz metinde açık bir eyalet varsa, aradığınız hedefle ilgili daha az vektör etkinleşir. Bu yüzden softmax uygulandığında doğru eyaletin seçilme olasılığı artar.
    Aynı bağlamda /n ile virgül karşılaştırması da muhtemelen tokenizasyon farkından kaynaklanıyordur.