1 Yıl Boyunca LLM ile Ürün Geliştirirken Öğrendiklerimiz

xguru · 2024-06-10T11:16:01+09:00

Büyük dil modelleri (LLM) kullanarak geliştirme yapmak için heyecan verici bir dönemdeyiz Son 1 yılda LLM'ler gerçek uygulamalarda "yeterince iyi" düzeye geldi ve her yıl daha iyi ve daha ucuz hale geliyor Sosyal medyadaki demolarla birlikte, 2025'e kadar yapay zekaya yaklaşık 200 milyar dolar yatırım yapılacağı tahmin ediliyor Sağlayıcıların API'leri sayesinde LLM'lere erişim kolaylaştı; böylece yalnızca ML mühendisleri ve bilim insanları değil, herkes ürünlerine zekâ katmanı inşa edebilir hale geldi Yapay zekâ ile bir şeyler inşa etmenin giriş bariyeri düştü, ancak demo seviyesinin ötesinde etkili ürünler ve sistemler yapmak hâlâ zor Biz de son 1 yıldır ürün geliştiriyoruz ve bu süreçte birçok zorluk keşfettik Kendi hatalarımızdan kaçınmanıza ve daha hızlı iterasyon yapmanıza yardımcı olmak için öğrendiklerimizi paylaşmak istiyoruz Bu yazı üç bölümden oluşuyor: Tactical (Taktiksel): prompt yazımı, RAG, workflow engineering, değerlendirme ve izleme için bazı pratikler LLM'lerle ürün geliştiren uygulayıcılar veya hafta sonu projeleri yapanlar için yazıldı Operational (Operasyonel): ürün lansmanının organizasyonel ve günlük meseleleri ile etkili ekip kurma yöntemleri Sürdürülebilir ve güvenilir biçimde dağıtım yapmak isteyen ürün/teknoloji liderlerine yönelik Strategic (Stratejik): "PMF öncesi GPU yok", "modele değil sisteme odaklan" gibi görüşleri içeren uzun vadeli, büyük resim perspektifi ve iterasyon yaklaşımı Kurucular ve yöneticiler düşünülerek yazıldı Bu rehber, LLM kullanarak başarılı ürünler geliştirmek için pratik bir kılavuz olmayı amaçlıyor Kendi deneyimlerimizden doğdu ve sektör genelinden örnekler sunuyor [Taktik: LLM kullanımının özü] Bu bölümde, yeni ortaya çıkan LLM yığınının temel bileşenlerine ilişkin en iyi uygulamaları paylaşıyoruz Kalite ve güvenilirliği artırmaya yönelik prompt ipuçları, çıktıları değerlendirme stratejileri ve grounding'i iyileştirmek için retrieval-augmented generation fikirleri buna dahil Ayrıca human-in-the-loop workflow'larının nasıl tasarlanacağını da ele alacağız Taktik 1. Prompt yazımı Yeni bir uygulama geliştirirken prompt ile başlamanızı öneriyoruz Prompting'in önemini küçümsemek de abartmak da kolaydır Doğru prompting teknikleri düzgün kullanıldığında çok ileri gidilebildiği için genellikle küçümsenir Öte yandan, prompt tabanlı uygulamaların da düzgün çalışması için prompt'un etrafında ciddi mühendislik gerektiğinden, bazen gereğinden fazla önem atfedilir Temel prompting tekniklerinden en yüksek verimi almaya odaklanın Farklı modeller ve görevlerde performans artışına sürekli yardımcı olan bazı prompting teknikleri vardır Bunlar arasında N-shot prompt + in-context learning, Chain-of-Thought ve ilgili kaynakların sağlanması yer alır N-shot prompt ve in-context learning N-shot prompt ile in-context learning'in temel fikri, LLM'e görevi birkaç örnekle göstermek ve çıktıyı beklentilere hizalamaktır N çok düşük olursa model bu belirli örneklere aşırı sabitlenebilir ve genelleme yeteneği düşebilir Deneyimsel olarak N ≥ 5 hedefleyin ve gerekirse onlarca örnek kullanmaktan çekinmeyin Örnekler, beklenen girdi dağılımını temsil etmelidir Tüm girdi-çıktı çiftlerini vermeniz gerekmez; birçok durumda istenen çıktının örnekleri yeterlidir Araç kullanımını destekleyen bir LLM kullanıyorsanız, N-shot örneklerde de ajanın kullanmasını istediğiniz araçları kullanın Chain-of-Thought (CoT) prompting CoT prompting'de LLM, nihai cevabı vermeden önce düşünce sürecini açıklamaya teşvik edilir Bunu, LLM'in her şeyi bellekte yapmak zorunda kalmaması için ona bir taslak alanı sağlamak gibi düşünebilirsiniz İlk yaklaşım, yönergelerin bir parçası olarak basitçe "adım adım düşünelim" ifadesini eklemekti; ancak CoT'yi daha spesifik hale getirmenin faydalı olduğunu gördük 1-2 cümlelik ek özgüllük, çoğu zaman halüsinasyon oranını anlamlı biçimde azaltır Son dönemde bu tekniğin sanıldığı kadar güçlü olup olmadığı da sorgulanıyor Ayrıca CoT kullanıldığında muhakeme sırasında tam olarak ne olduğuna dair ciddi bir tartışma var Buna rağmen, mümkün olduğunda denenmeye değer bir tekniktir İlgili kaynakları sağlama İlgili kaynaklar sağlamak, modelin bilgi tabanını genişleten, halüsinasyonu azaltan ve kullanıcı güvenini artıran güçlü bir mekanizmadır Bu çoğu zaman retrieval-augmented generation (RAG) ile yapılır Modele, yanıtında doğrudan kullanabileceği metin parçaları vermek temel bir tekniktir İlgili kaynaklar sağlarken bunları yalnızca eklemek yeterli değildir Modele, kaynak kullanımına öncelik vermesini, bunlara doğrudan atıfta bulunmasını ve bazen kaynakların yetersiz kaldığını belirtmesini söylemeyi unutmayın Bunlar, ajan yanıtlarını kaynak korpusuna "ground" etmeye yardımcı olur Girdi ve çıktıyı yapılandırın Yapılandırılmış girdiler ve çıktılar, modelin girdiyi daha iyi anlamasına ve alt sistemlerle güvenilir biçimde entegre olabilecek çıktılar döndürmesine yardımcı olur Girdiye bir serileştirme biçimi eklemek, bağlamdaki token'lar arası ilişkileri, belirli token'lara dair ek metaveriyi (ör. tür) veya isteği modelin eğitim verisindeki benzer örneklerle ilişkilendirmeyi kolaylaştırabilir Örneğin internette SQL yazımıyla ilgili birçok soru, SQL şemasını belirterek başlar Bu nedenle Text-to-SQL için etkili prompting, yapılandırılmış şema tanımlarını içermelidir Yapılandırılmış çıktı benzer bir amaca hizmet eder, ancak sistemin alt bileşenleriyle entegrasyonu basitleştirir Instructor ve Outlines, yapılandırılmış çıktı için iyi çalışır (Bir LLM API SDK'sı kullanıyorsanız Instructor'ı, kendi host ettiğiniz modellerde Huggingface kullanıyorsanız Outlines'ı tercih edin) Yapılandırılmış girdiler, görevi açık biçimde ifade ettiğinden ve eğitim verisinin formatına benzediğinden daha iyi çıktı alma olasılığını artırır Yapılandırılmış girdi kullanırken, her LLM ailesinin tercih ettiği bir yaklaşım olduğunu unutmamak gerekir Claude, tercih ederken GPT, Markdown ve JSON'u tercih eder XML kullanırsanız, Claude'un yanıtını önceden doldurmak için etiketi de verebilirsiniz Küçük ve tek işi iyi yapan prompt'lar oluşturun Yazılımda yaygın bir anti-pattern/kod kokusu, her şeyi yapan tek bir sınıf ya da fonksiyon olan "God Object"tir Aynısı prompt'lar için de geçerlidir Prompt'lar genellikle basit başlar Birkaç cümlelik talimat ve birkaç örnekle başlayabilirsiniz Ancak performansı artırmaya ve daha fazla edge case işlemeye çalıştıkça karmaşıklık büyür Daha fazla talimat, çok adımlı akıl yürütme, onlarca örnek vb. eklenir Sonunda başlangıçta basit olan prompt, 2.000 token'lık bir Frankenstein'a dönüşür Üstelik daha genel ve sezgisel girdilerdeki performans bile kötüleşebilir GoDaddy bunu, LLM ile ürün geliştirirken çıkardığı dersler arasında 1 numaraya koyuyor Sistemleri ve kodu basit tutmaya çalıştığınız gibi prompt'lar da öyle olmalıdır Toplantı dökümü özetleyicisi için tek ve her şeyi yapan bir prompt kullanmak yerine, bunu şu adımlara bölebilirsiniz Ana kararları, aksiyon maddelerini ve sorumlu kişileri yapılandırılmış biçimde çıkarma Çıkarılan ayrıntıları özgün dökümle karşılaştırarak tutarlılık kontrolü yapma Yapılandırılmış ayrıntılardan kısa bir özet üretme Sonuç olarak tek bir prompt'u, birden çok basit, odaklı ve anlaşılır prompt'a bölmüş olursunuz Bu şekilde artık her prompt üzerinde ayrı ayrı iterasyon yapabilir ve değerlendirme gerçekleştirebilirsiniz Bağlam token'ları oluşturma Ajana gerçekten gönderilmesi gereken bağlam miktarına dair varsayımlar yeniden düşünülmeli ve sorgulanmalı Michelangelo gibi bir bağlam heykeli inşa etmek yerine, gereksiz malzemeyi yontup heykeli ortaya çıkarmak gerekir RAG, potansiyel olarak ilgili tüm mermer bloklarını toplamak için yaygın olarak kullanılan bir yöntemdir; peki gereken şeyi çıkarmak için ne yapıyorsunuz? Modele gönderilen nihai prompt'u alıp tüm bağlam bileşimi, meta prompting ve RAG sonuçlarıyla birlikte boş bir sayfaya yerleştirip okumanın, bağlamı yeniden düşünmeye yardımcı olduğu görülmüştür Bu yöntemle tekrarlar, kendi içinde çelişen ifadeler ve kötü biçimlendirilmiş kısımlar tespit edilebilir Bir diğer temel optimizasyon da bağlamın yapısıdır Bag-of-docs temsili insanlara yardımcı olmaz; bu yüzden ajan için de iyi olduğunu varsaymamalısınız Bağlamın her parçası arasındaki ilişkiyi vurgulayan ve çıkarımı mümkün olduğunca basit hale getiren bir bağlam yapısının nasıl kurulacağını dikkatle düşünmek gerekir Taktik 2. Bilgi erişimi / RAG Prompting'in yanı sıra, bir LLM'i yönlendirmenin etkili bir diğer yolu da prompt'un bir parçası olarak bilgi sağlamaktır Bu, LLM'i sağlanan bağlama ground eder ve bu da bağlam içi öğrenmede kullanılır Buna Retrieval-Augmented Generation (RAG) denir Uygulayıcılar, RAG'nin bilgi sağlama ve çıktıyı iyileştirme konusunda etkili olduğunu, ayrıca fine-tuning'e kıyasla çok daha az emek ve maliyet gerektirdiğini görmüştür RAG ancak getirilen belgelerin ilgililiği, bilgi yoğunluğu ve ayrıntı seviyesi kadar iyidir RAG çıktısının kalitesi, getirilen belgelerin kalitesine bağlıdır ve değerlendirilebilecek birkaç unsur vardır İlk ve en açık ölçüt "ilgililik"tir Bu genellikle Mean Reciprocal Rank (MRR) veya Normalized Discounted Cumulative Gain (NDCG) gibi sıralama metrikleriyle nicelleştirilir MRR, sistemin sıralı listede ilk ilgili sonucu ne kadar iyi konumlandırdığını değerlendirirken, NDCG tüm sonuçların ilgililiğini ve konumunu dikkate alır Bunlar, ilgili belgeleri daha yukarıya ve ilgisiz belgeleri daha aşağıya sıralayan sistemlerin performansını ölçer Örneğin film incelemelerinin özetini üretmek için kullanıcı özetleri getiriliyorsa, belirli bir filme ait incelemeleri daha yukarıda sıralamak ve diğer filmlere ait incelemeleri dışarıda bırakmak istenir Geleneksel öneri sistemlerinde olduğu gibi, getirilen öğelerin sıralaması LLM'in aşağı akış görevini nasıl yerine getirdiğini önemli ölçüde etkiler Etkiyi ölçmek için getirilen öğeleri karıştırılmış haldeyken RAG tabanlı görevi çalıştırın ve RAG çıktısının nasıl performans gösterdiğine bakın İkinci unsur "bilgi yoğunluğu"dur İki belge eşit derecede ilgiliyse, daha kısa ve daha az ilgisiz ayrıntı içeren belge tercih edilmelidir Film örneğine dönersek, film senaryosu ile tüm kullanıcı incelemeleri geniş anlamda ilgili sayılabilir Buna rağmen yüksek puanlı incelemeler ve editoryal incelemeler muhtemelen daha yüksek bilgi yoğunluğuna sahiptir Son olarak, belgede sunulan "ayrıntı düzeyi" dikkate alınmalıdır Doğal dilden SQL sorguları üretmek için bir RAG sistemi kurduğunuzu hayal edin Sütun adlarını içeren tablo şemasını bağlam olarak vermek tek başına yeterli olabilir Peki ya sütun açıklamaları ve bazı temsili değerler de eklenirse? Ek ayrıntılar, LLM'in tablonun anlamını daha iyi kavramasına ve daha doğru SQL üretmesine yardımcı olabilir Anahtar kelime aramayı unutmayın; bunu baseline ve hibrit arama için kullanın Embedding tabanlı RAG demoları yaygınlaştığı için, bilgi erişimi alanındaki onlarca yıllık araştırma ve çözümleri unutmak ya da göz ardı etmek kolaydır Yine de embedding'ler kuşkusuz güçlü araçlardır, ancak her derde deva değildir Anahtar kelime tabanlı aramanın avantajları Birincisi, embedding'ler yüksek düzeyde anlamsal benzerliği yakalamada mükemmeldir; ancak kullanıcı bir ad (ör. Ilya), bir kısaltma (ör. RAG) veya bir kimlik (ör. claude-3-sonnet) aradığında olduğu gibi daha spesifik ve anahtar kelime tabanlı sorgularda zorlanabilir BM25 gibi anahtar kelime tabanlı arama sistemleri bunun için açıkça tasarlanmıştır Kullanıcılar anahtar kelime tabanlı aramayı uzun zamandır kullandığı için bunu doğal karşılar; aradıkları belge dönmezse hayal kırıklığı yaşayabilirler İkincisi, bir belgenin neden getirildiğini anlamak anahtar kelime aramada daha sezgiseldir Çünkü sorguyla eşleşen anahtar kelimeler görülebilir Buna karşılık embedding tabanlı arama daha az yorumlanabilirdir Üçüncüsü, Lucene veya OpenSearch gibi onlarca yıl boyunca optimize edilmiş ve sahada kanıtlanmış sistemler sayesinde anahtar kelime arama genellikle hesaplama açısından daha verimlidir Çoğu durumda hibrit yaklaşım en etkilisidir Bariz eşleşmeler için anahtar kelime eşleştirme, eş anlamlılar, üst kavramlar, yazım hataları ve multimodal durumlar (ör. görsel ve metin) için embedding kullanın Shortwave, sorgu yeniden yazımı, anahtar kelime + embedding araması, sıralama vb. dahil olmak üzere kendi RAG pipeline'larını nasıl kurduklarını paylaştı Yeni bilgi için fine-tuning yerine RAG'yi tercih edin Hem RAG hem de fine-tuning, yeni bilgiyi LLM'e entegre etmek ve belirli görevlerde performansı artırmak için kullanılabilir Peki önce hangisini denemek gerekir? RAG'nin avantajları Son araştırmalara göre RAG daha üstün olabilir Bir çalışmada RAG ile gözetimsiz fine-tuning (sürekli ön eğitim olarak da bilinir), MMLU ve güncel olaylara dair alt kümeler üzerinde değerlendirilerek karşılaştırılmıştır RAG, hem eğitim sırasında karşılaşılan bilgi hem de tamamen yeni bilgi için fine-tuning'den sürekli olarak daha iyi performans göstermiştir Başka bir makalede tarım veri kümesi üzerinde RAG ile gözetimli fine-tuning karşılaştırılmıştır Benzer şekilde, RAG'nin performans artışı fine-tuning'den daha büyük olmuştur; bu fark özellikle GPT-4'te belirgindir (makaledeki tablo 20'ye bakın) Performans artışının yanı sıra, RAG'nin çeşitli pratik avantajları da vardır Birincisi, sürekli ön eğitim veya fine-tuning'e kıyasla arama indeksini güncel tutmak daha kolay ve daha ucuzdur İkincisi, arama indeksinde zararlı ya da önyargılı içerik barındıran sorunlu belgeler varsa, bu belgeler kolayca silinebilir veya düzeltilebilir Ayrıca RAG'deki R, belgelerin nasıl getirileceği konusunda daha ayrıntılı kontrol sağlar Örneğin birden fazla kuruluş için RAG sistemi barındırıyorsanız, her kuruluşun yalnızca kendi indeksindeki belgeleri getirebilmesi için arama indeksini bölümlere ayırabilirsiniz Bu da bir kuruluşun bilgilerinin yanlışlıkla başka bir kuruluşa ifşa edilmesini önlemeye yardımcı olur Uzun bağlamlı modeller RAG'yi işe yaramaz hale getirmeyecek Gemini 1.5’in 10 milyon tokene kadar bağlam penceresi sunmasıyla birlikte bazıları RAG’in geleceğini sorgulamaya başladı 10 milyon tokenlik bir bağlam penceresi, mevcut RAG çerçevelerinin çoğunu gereksiz hale getiriyor Veriyi bağlama koyup her zamanki gibi modelle konuşmanız yeterli Mühendislik çabasının büyük kısmını RAG’e yatıran startup’lar, ajanlar ve langchain projeleri için bunun ne anlama geleceğini düşünün Tek cümlelik özet: 10 milyonluk bağlam RAG’i öldürür RAG’in kalıcı gerekliliği Uzun bağlamın, çoklu belge analizi veya PDF’lerle sohbet gibi kullanım senaryolarında oyun değiştirici olacağı doğru olsa da, RAG’in sonuna dair söylentiler büyük ölçüde abartılı Birincisi, 10 milyon tokenlik bir bağlam penceresi olsa bile modele hangi bilginin verileceğini seçmenin bir yoluna hâlâ ihtiyaç var İkincisi, dar kapsamlı needle-in-a-haystack değerlendirmelerinin ötesinde, modelin bu kadar büyük bir bağlam üzerinde etkili biçimde akıl yürütebildiğini gösteren ikna edici veriler henüz görmedim Bu nedenle, iyi bir retrieval (ve sıralama) olmadan modeli dikkat dağıtan bilgilerle boğma, hatta bağlam penceresini tamamen alakasız bilgilerle doldurma riski vardır Son olarak maliyet sorunu var Transformer çıkarım maliyeti, bağlam uzunluğuna göre karesel olarak artar (veya hem alan hem zaman açısından doğrusal) Bir modelin bir kuruluşun tüm Google Drive içeriğini okuyabiliyor olması, her soruyu yanıtlamadan önce bunu yapmasının iyi bir fikir olduğu anlamına gelmez RAM kullanım biçimine dair şu benzetmeyi düşünün Onlarca terabayt RAM’e sahip hesaplama örnekleri mevcut, ama buna rağmen hâlâ diskten okuma ve diske yazma yapıyoruz Bu yüzden RAG’i henüz çöpe atmayın Bu örüntü, bağlam pencereleri büyüdükçe de faydalı olmaya devam edecek Taktik 3. İş akışı ayarlama ve optimizasyon LLM’e prompt vermek sadece başlangıçtır LLM’den en yüksek verimi almak için tek bir promptun ötesine geçip iş akışlarını benimsemek gerekir Örneğin, karmaşık tek bir görevi birden fazla daha basit göreve nasıl bölebiliriz? İnce ayar veya cache ne zaman performansı artırmaya ve gecikme/maliyeti düşürmeye yardımcı olur? Bu bölümde, LLM iş akışlarını optimize edip kurmanıza yardımcı olmak için kanıtlanmış stratejiler ve gerçek örnekler paylaşılıyor Adım adım, çok turlu "Flow" büyük performans artışları sağlayabilir Tek bir büyük promptu birden fazla küçük prompa bölerek daha iyi sonuçlar alınabileceğini zaten biliyoruz AlphaCodium bunun bir örneği Tek prompttan çok aşamalı iş akışına geçerek CodeContests’te GPT-4 doğruluğunu (pass@5) %19’dan %44’e çıkardı İş akışı şunları içerir Problem üzerine düşünme Açık testler üzerinde akıl yürütme Olası çözümler üretme Olası çözümleri sıralama Sentetik test üretme Çözümleri açık ve sentetik testler üzerinde yineleme Net hedeflere sahip küçük görevler, en iyi ajan veya akış promptlarını oluşturur Her ajan promptunun yapılandırılmış çıktı istemesi gerekmez, ancak yapılandırılmış çıktı, ajanın çevresiyle etkileşimini yöneten sistemle arayüz açısından çok faydalıdır Denemeye değer şeyler Mümkün olduğunca sıkı tanımlanmış, açık planlama adımları Önceden tanımlanmış planlar arasından seçim yapmayı düşünün Orijinal kullanıcı promptunu ajan promptu olarak yeniden yazmak Bu süreçte bilgi kaybı yaşanabileceği için dikkatli olun Doğrusal zincirler, DAG’ler ve durum makineleri olarak ajan davranışı Farklı bağımlılıklar ve mantıksal ilişkiler, farklı ölçekler için daha uygun ya da daha az uygun olabilir Farklı görev mimarilerinde performans optimizasyonu sağlayabilir miyiz? Plan doğrulama Plan, nihai çıktının iyi çalışmasını sağlamak için diğer ajanların yanıtlarının nasıl değerlendirileceğine dair talimatlar içerebilir Sabit upstream durumla prompt mühendisliği Ajan promptunun daha önce ortaya çıkabilecek farklı varyasyonlara karşı değerlendirildiğinden emin olun Şimdilik deterministik iş akışlarına öncelik verin Yapay zeka ajanları, kullanıcı isteklerine ve çevreye dinamik biçimde tepki verebilir, ancak deterministik olmayan yapıları dağıtımı zorlaştırır Ajanın yürüttüğü her adımın başarısız olma ihtimali vardır ve hatadan kurtulma olasılığı düşüktür Bu nedenle bir ajanın çok adımlı bir görevi başarıyla tamamlama olasılığı, adım sayısı arttıkça geometrik olarak azalır Sonuç olarak ajan geliştiren ekipler, güvenilir ajanları üretime almada zorlanır Umut vadeden bir yaklaşım, deterministik bir plan üreten ve bunu yapılandırılmış, tekrar üretilebilir bir biçimde yürüten bir ajan sistemine sahip olmaktır İlk aşamada, üst düzey bir hedef veya prompt verildiğinde ajan bir plan üretir Ardından plan deterministik olarak yürütülür Bu, her adımı daha öngörülebilir ve güvenilir hale getirebilir Avantajlar Üretilen planlar, ajanı promptlamak veya ince ayar yapmak için few-shot örnekleri olarak kullanılabilir Deterministik yürütme sistemi daha güvenilir kılar; test ve debug daha kolay olur. Ayrıca başarısızlıklar planın belirli bir adımına kadar izlenebilir Üretilen planlar yönlü çevrimsiz grafikler (DAG) olarak ifade edilebilir ve statik promptlara kıyasla anlaşılması ve yeni durumlara uyarlanması daha kolaydır En başarılı ajan geliştiricileri, muhtemelen junior mühendisleri yönetme konusunda güçlü deneyime sahip kişiler olabilir Çünkü plan üretim süreci, junior birini yönlendirme ve yönetme biçimine benzer Junior’lara belirsiz ve açık uçlu yönlendirmeler yerine net hedefler ve somut planlar verdiğiniz gibi, ajanlara da aynısını yapmalısınız Sonuçta güvenilir ve gerçekten çalışan ajanların anahtarı muhtemelen şurada yatıyor Daha yapılandırılmış ve deterministik bir yaklaşım benimsemekte, ve promptları iyileştirmekle modeli ince ayar yapmak için veri toplamaktadır Bunlar olmadan, bazen çok iyi çalışan ama ortalamada kullanıcıyı hayal kırıklığına uğratan ve elde tutmayı düşüren ajanlar inşa edersiniz Sıcaklık parametresinin ötesinde çeşitli çıktılar elde etmek LLM çıktısında çeşitliliğe ihtiyaç duyan görevler olduğunu varsayalım Kullanıcının daha önce satın aldığı ürünler listesini dikkate alarak katalogdan satın alınabilecek ürünler öneren bir LLM pipeline’ı yazıyor olabilirsiniz Promptu birden çok kez çalıştırdığınızda öneri sonuçlarının birbirine fazla benzediğini fark edebilirsiniz Bu nedenle LLM isteğinin Temperature (sıcaklık) parametresini artırabilirsiniz Sıcaklık parametresini yükseltmek, LLM yanıtlarını daha çeşitli hale getirir Örnekleme sırasında bir sonraki tokenın olasılık dağılımı daha düzleşir ve normalde seçilme ihtimali düşük tokenlar daha sık seçilir Ancak sıcaklığı artırdığınızda çıktı çeşitliliğiyle ilgili bazı başarısızlık modları ortaya çıkabilir Örneğin katalogdaki bazı ürünler uygun olabilir ama LLM tarafından çıktıda yer almayabilir LLM, eğitim sırasında öğrendiklerine dayanarak promptu takip etmeye daha yatkınsa, aynı az sayıdaki ürün çıktıda aşırı temsil edilebilir Sıcaklık çok yükselirse var olmayan ürünlere (veya anlamsız içeriklere) atıf yapan çıktılar üretilebilir Sıcaklığı artırmak, LLM’nin beklediğiniz olasılık dağılımından (ör. eşit rastgele) çıktı örnekleyeceğini garanti etmez Buna rağmen çıktı çeşitliliğini artırmak için başka hileler de vardır En basit yöntem, prompt içindeki öğeleri ayarlamaktır Örneğin prompt şablonu geçmiş satın alımlar gibi bir öğe listesi içeriyorsa, bu öğeleri prompa her ekleyişinizde sıralarını karıştırmak önemli fark yaratabilir Ayrıca son çıktılardan oluşan kısa bir liste tutmak da tekrarları önlemeye yardımcı olur Ürün önerisi örneğinde, LLM’ye bu son listedeki öğeleri önermemesi talimatını verebilir veya son önerilere benzeyen çıktıları reddedip yeniden örnekleme yaparak yanıtları daha da çeşitlendirebilirsiniz Bir diğer etkili strateji, promptta kullanılan ifadeleri çeşitlendirmektir Örneğin "kullanıcının düzenli olarak kullanmayı seveceği öğeleri seç" ya da "kullanıcının arkadaşına tavsiye etme olasılığı yüksek ürünleri seç" gibi ifadeleri dahil etmek, odağı kaydırarak önerilen ürünlerin çeşitliliğini etkileyebilir Cache kullanımı hak ettiği değeri görmüyor Önbellekleme, aynı girdi için yanıtı yeniden hesaplama gereğini ortadan kaldırarak maliyeti düşürür ve üretim gecikmesini kaldırır Ayrıca yanıt daha önce guardrail kontrollerinden geçtiyse, bu doğrulanmış yanıtları sunarak zararlı veya uygunsuz içerik verme riskini azaltabilir Önbellekleme için basit bir yaklaşım, yeni bir makaleyi ya da ürün incelemesini özetleme durumunda olduğu gibi, işlenen öğe için benzersiz bir kimlik kullanmaktır Bir istek geldiğinde, özeti önbellekte zaten var mı diye kontrol edebilirsiniz Varsa hemen döndürülebilir; yoksa oluşturulur, guardrail kontrolünden geçirilir ve sunulduktan sonra gelecekteki istekler için önbelleğe kaydedilir Daha açık uçlu sorgular için, arama alanındaki tekniklerden yararlanarak açık uçlu girdilerde de önbellekleme kullanılabilir Otomatik tamamlama ve yazım düzeltme gibi özellikler, kullanıcı girdisini normalize ederek önbellek isabet oranını artırmaya yardımcı olur finetune (ince ayar) ne zaman gerekir En akıllıca tasarlanmış prompt'ların bile yetersiz kaldığı bazı görevler olabilir Örneğin, kayda değer prompt mühendisliğinden sonra bile sistem hâlâ güvenilir ve yüksek kaliteli çıktı üretmekten uzak kalabilir Bu durumda modeli belirli bir görev için ince ayar yapmak gerekebilir Başarılı ince ayar örnekleri Honeycomb'un Natural Language Query Assistant'ı Başlangıçta "programlama kılavuzu", bağlam içi öğrenme için n-shot örnekleriyle birlikte prompt içinde verildi Bu işe yarasa da, model ince ayarlandığında alan özelindeki dilin sözdizimi ve kuralları konusunda daha iyi çıktılar alınabilir Rechat'in Lucy'si LLM'in, frontend'in doğru şekilde render edebilmesi için yapılandırılmış ve yapılandırılmamış verileri birleştiren çok belirli bir biçimde yanıt üretmesi gerekir Bunun tutarlı şekilde çalışması için ince ayar kritik önemdedir İnce ayar etkili olabilir, ancak önemli bir maliyeti vardır İnce ayar verisini etiketlemeniz, modeli ince ayarlayıp değerlendirmeniz ve sonunda kendi başınıza barındırmanız gerekir Bu nedenle, daha yüksek başlangıç maliyetinin buna değip değmeyeceğini değerlendirmek gerekir Prompting ile %90 seviyesine ulaşabiliyorsanız, ince ayara yatırım yapmak anlamlı olmayabilir Ancak ince ayar yapmaya karar verirseniz, insanlar tarafından etiketlenmiş veri toplama maliyetini azaltmak için sentetik veri üzerinde üretim ve ince ayar yapabilir ya da açık kaynak verilerle başlangıç seti oluşturabilirsiniz Taktik 4. Değerlendirme ve izleme LLM değerlendirmesi bir mayın tarlası olabilir LLM'in girdileri ve çıktıları serbest biçimli metindir ve tanımladığınız görevler de çeşitlidir Buna rağmen, sıkı ve dikkatli değerlendirme kritik önemdedir OpenAI'nin teknik liderlerinin değerlendirmelere katılması ve tek tek değerlendirmeler için geri bildirim vermesi tesadüf değildir LLM uygulamalarını değerlendirmek çeşitli tanımlar ve indirgemeler gerektirir Bu, basitçe unit test olabilir, daha çok gözlemlenebilirliğe benzeyebilir ya da sadece veri bilimi olabilir Biz bu bakış açılarının hepsinin faydalı olduğunu gördük Bu bölümde, değerlendirme ve izleme hattını kurarken önemli olan noktalara dair öğrendiğimiz dersleri paylaşıyoruz Gerçek girdi/çıktı örneklerinden assertion tabanlı birkaç unit test oluşturun Prodüksiyondaki girdi ve çıktı örneklerinden oluşan unit testler (yani assertion'lar) oluşturun ve en az 3 farklı ölçüte göre çıktıya dair beklentiler belirleyin 3 ölçüt keyfi görünebilir, ancak başlamak için pratik bir sayıdır Daha azı, görevin yeterince iyi tanımlanmadığı ya da genel amaçlı bir chatbot örneğinde olduğu gibi fazla açık uçlu olduğu anlamına gelebilir Bu unit testler veya assertion'lar, prompt düzenleme, RAG ile yeni bağlam ekleme ya da diğer değişiklikler gibi pipeline üzerindeki güncellemelerle tetiklenmelidir Her yanıtta bulunması ya da bulunmaması gereken ifade ve fikirleri belirleyen assertion'larla başlamayı düşünün Ayrıca kelime, öğe veya cümle sayısının belirli bir aralıkta olup olmadığını kontrol eden testler de düşünülebilir Farklı üretim türleri için assertion'lar da farklı görünebilir Örneğin kod üretimini değerlendirmek için güçlü bir yöntem olan yürütme değerlendirmesinde, üretilen kod çalıştırılır ve çalışma zamanı durumunun kullanıcının isteğini yeterince karşılayıp karşılamadığı kontrol edilir Örneğin kullanıcı foo adında yeni bir fonksiyon isterse, ajan tarafından üretilen kod çalıştırıldıktan sonra foo çağrılabilmelidir Yürütme değerlendirmesindeki zorluklardan biri, ajan kodunun çoğu zaman çalışma zamanını hedef koda göre biraz farklı bir durumda bırakmasıdır Assertion'ları, geçerli her yanıtın karşılayabileceği en zayıf varsayımlara göre "gevşetmek" etkili olabilir Ürünü müşterinin amaçladığı şekilde kendiniz kullanmak (yani "dogfooding"), gerçek verideki hata modları hakkında içgörü sağlayabilir Bu yaklaşım yalnızca potansiyel zayıflıkları belirlemeye yardımcı olmakla kalmaz, aynı zamanda değerlendirmeye dönüştürülebilecek faydalı prodüksiyon örnekleri de sağlar LLM-as-Judge (bir ölçüde) işe yarayabilir, ancak her derde deva değildir LLM-as-Judge, güçlü bir LLM kullanarak başka bir LLM'in çıktısını değerlendirme yöntemidir ve bazı kişiler buna şüpheyle yaklaşır Buna rağmen iyi uygulandığında, LLM-as-Judge insan yargısıyla anlamlı bir korelasyon yakalayabilir ve en azından yeni prompt'ların ya da tekniklerin nasıl performans gösterebileceğine dair ön bilgi oluşturmaya yardımcı olabilir Özellikle ikili karşılaştırmalarda (ör. kontrol grubu vs deney grubu), LLM-as-Judge genellikle yönü doğru belirler, ancak kazanma/kaybetme farkının büyüklüğü gürültülü olabilir LLM-as-Judge'dan en iyi şekilde yararlanmak için öneriler İkili karşılaştırma kullanın LLM'den tek bir çıktıyı Likert ölçeğinde puanlamasını istemek yerine, iki seçeneği gösterip daha iyi olanı seçmesini isteyin Bu, daha istikrarlı sonuçlara yol açma eğilimindedir Konum yanlılığını kontrol edin Sunulan seçeneklerin sırası, LLM'in kararını etkileyebilir Bunu azaltmak için her ikili karşılaştırmayı iki kez çalıştırın ve her seferinde çiftin sırasını değiştirin Sıra değiştirildikten sonra galibiyet doğru seçeneğe yazılmalıdır Beraberliğe izin verin Bazı durumlarda iki seçenek de eşit derecede iyi olabilir Bu nedenle LLM'in rastgele bir kazanan seçmek zorunda kalmaması için beraberlik ilan etmesine izin verin Chain-of-Thought kullanın Son tercihi vermeden önce LLM'den kararını açıklamasını istemek, değerlendirmenin güvenilirliğini artırabilir Ek bir avantaj olarak bu, daha zayıf ama daha hızlı bir LLM kullanırken bile benzer sonuçlar elde etmeyi sağlayabilir Pipeline'ın bu kısmı çoğu zaman batch modunda çalıştığı için CoT'nin getirdiği ek gecikme sorun olmaz Yanıt uzunluğunu kontrol edin LLM'ler daha uzun yanıtlara kayma eğilimindedir Bunu azaltmak için yanıt çiftlerinin uzunluklarının benzer olduğundan emin olun LLM-as-Judge'ın özellikle güçlü bir kullanım alanı, yeni prompt stratejilerini regresyon açısından kontrol etmektir Eğer bir prodüksiyon çıktıları koleksiyonunu takip ettiyseniz, bazen bu prodüksiyon örneklerini yeni prompt stratejisiyle yeniden çalıştırabilir ve LLM-as-Judge kullanarak yeni stratejinin nerelerde zorlanabileceğini hızlıca değerlendirebilirsiniz LLM-as-Judge için basit ama etkili bir yaklaşım örneği LLM yanıtını, hakemin eleştirisini (yani CoT'yi) ve nihai sonucu kaydedin Ardından bunları paydaşlarla birlikte gözden geçirerek iyileştirme alanlarını belirleyin 3 yineleme sonunda insan ile LLM arasındaki uyum %68'den %94'e çıktı Ancak LLM-as-Judge her derde deva değildir En güçlü modeller bile bazı ince dilsel yönleri güvenilir biçimde değerlendiremez Ayrıca geleneksel sınıflandırıcıların ve ödül modellerinin, LLM-as-Judge'a kıyasla daha düşük maliyet ve gecikmeyle daha yüksek doğruluk sağlayabildiğini gördük Kod üretimi söz konusu olduğunda LLM-as-Judge, yürütme değerlendirmesi gibi daha doğrudan değerlendirme stratejilerine göre daha zayıf kalabilir Üretim sonuçlarını değerlendirmek için "stajyer testi" Üretim sonuçlarını değerlendirirken aşağıdaki gibi bir "stajyer testi" kullanmak faydalı olabilir Bağlamı da ekleyerek dil modeline verilen tam girdiyi ilgili alanda ortalama bir üniversite öğrencisine görev olarak verseniz, başarılı olabilirler mi? Ne kadar sürer? Yanıt hayırsa Bunun nedeni LLM'in ihtiyaç duyduğu bilgiye sahip olmamasıysa, bağlamı zenginleştirmenin yollarını düşünün Bağlamı iyileştirmek de sorunu çözmüyorsa, bu görev günümüz LLM'leri için fazla zor olabilir Yanıt evetse ama zaman alıyorsa Görevin karmaşıklığını azaltmayı deneyebilirsiniz Parçalara ayrılabilir mi? Görevin hangi yönleri daha fazla şablonlaştırılabilir? Yanıt evetse ve hızlıca yapılabiliyorsa Veriyi derinlemesine incelerken Model neyi yanlış yapıyor? Başarısızlık örüntüleri bulunabilir mi? Modelden yanıt vermeden önce veya sonra kendi kendine açıklama yapmasını istemeyi deneyin Belirli bir değerlendirmeye aşırı odaklanmak genel performansı düşürebilir "Bir ölçüm metriği hedef haline geldiğinde artık iyi bir ölçüm metriği olmaktan çıkar." - Goodhart yasası Buna örnek olarak Needle-in-a-Haystack (NIAH) değerlendirmesi verilebilir İlk haliyle bu değerlendirme, bağlam boyutu büyüdükçe modelin hatırlama performansını nicel olarak ölçmeye ve iğnenin konumunun bu hatırlamayı nasıl etkilediğini görmeye yardımcı olur Ancak buna gereğinden fazla vurgu yapıldı ve Gemini 1.5 raporunda Figure 1 olarak sunuldu Bu değerlendirme, Paul Graham'ın denemelerinin tekrarlandığı uzun bir belgeye belirli bir ifadeyi ("The special magic {city} number is: {number}") ekleyip ardından modele sihirli sayıyı hatırlatmayı istemeyi içerir Bazı modeller neredeyse kusursuz hatırlama elde etse de, NIAH'ın gerçek uygulamaların gerektirdiği akıl yürütme ve hatırlama becerilerini gerçekten yansıtıp yansıtmadığı sorgulanabilir Daha pratik senaryoları düşünün Elinizde 1 saatlik bir toplantı dökümü varsa, LLM ana kararları ve sonraki adımları özetleyip her maddeyi doğru sorumlu kişiye atfedebilir mi? Bu görev yalnızca basit ezberlemeyi değil, karmaşık tartışmaları kavrama, ilgili bilgiyi belirleme ve özeti sentezleme becerisini de içerdiği için daha gerçekçidir Pratik bir NIAH değerlendirmesi örneği Doktor-hasta görüntülü görüşmesi dökümünü kullanarak LLM'e hastanın ilaçları hakkında sorular sormak Espressoya batırılmış hurma, limon, keçi peyniri gibi pizza malzemeleri için gereken rastgele içeriklere dair ifadeler eklenmesi gibi daha zorlayıcı NIAH örnekleri de dahil İlaç görevinde hatırlama yaklaşık %80, pizza görevinde ise %30 oldu NIAH değerlendirmesine aşırı vurgu yapmak, çıkarım ve özetleme görevlerindeki performansı düşürebilir Çünkü bu tür LLM'ler her cümleye dikkat etmeleri için ince ayarlanır; bu da ilgisiz ayrıntıları ve dikkat dağıtıcı unsurları önemliymiş gibi ele almalarına yol açabilir Sonuçta bunlar nihai çıktıya dahil olabilir (dahil edilmemeleri gerekirken bile!) Bu durum diğer değerlendirmeler ve kullanım senaryoları için de geçerli olabilir Örneğin özetleme Olgusal tutarlılığa vurgu yapmak, daha az spesifik ve dolayısıyla gerçekle uyuşmama ihtimali daha düşük ama aynı zamanda daha az ilgili özetler üretebilir Tersine, yazım tarzı ve ifade gücüne vurgu yapmak, olgusal tutarsızlıklara yol açabilecek daha gösterişli, pazarlama dili benzeri bir anlatım üretebilir Etiketlemeyi ikili görevler veya ikili (pairwise) karşılaştırmalarla sadeleştirin Model çıktısına açık uçlu geri bildirim vermek veya Likert ölçeğiyle değerlendirmek bilişsel olarak zordur Bunun sonucunda toplanan veri, insan değerlendiriciler arasındaki değişkenlik nedeniyle daha gürültülü olur ve bu yüzden daha az faydalı hale gelir Daha etkili yaklaşım, görevi basitleştirmek ve etiketleyicinin bilişsel yükünü azaltmaktır İyi çalışan iki yöntem ikili sınıflandırma ve ikili karşılaştırmadır İkili sınıflandırmada etiketleyiciden model çıktısı hakkında basit bir evet/hayır kararı vermesi istenir Üretilen özetin kaynak belgeyle olgusal olarak tutarlı olup olmadığı, önerilen yanıtın ilgili olup olmadığı ya da zararlı içerik barındırıp barındırmadığı sorulabilir Likert ölçeğine kıyasla ikili kararlar daha doğru, değerlendiriciler arası daha tutarlı ve daha yüksek verimlidir Doordash'in bir dizi evet/hayır sorusuyla menü öğelerini etiketlemek için bir etiketleme kuyruğu kurma biçimi buna örnektir İkili karşılaştırmada (Pairwise Comparison) etiketleyiciye model yanıtlarından oluşan bir çift verilir ve hangisinin daha iyi olduğu sorulur İnsanların A ya da B'yi ayrı ayrı puanlamasındansa "A, B'den daha iyidir" demesi daha kolay olduğundan, bu yaklaşım daha hızlı ve daha güvenilir etiketleme sağlar (Likert ölçeğine göre) Llama2 meetup'ında, Llama2 makalesinin yazarlarından Thomas Scialom, ikili karşılaştırmanın yazılı yanıtlar gibi denetimli ince ayar verisi toplamaktan daha hızlı ve daha ucuz olduğunu doğruladı İlkinin birim maliyeti 3,5 $, ikincisinin ise birim maliyeti 25 $ Referans gerektirmeyen değerlendirme ve guardrail'ler birbirinin yerine kullanılabilir Guardrail'ler uygunsuz veya zararlı içeriği yakalamaya yardımcı olurken, değerlendirmeler model çıktısının kalitesini ve doğruluğunu ölçmeye yardımcı olur Referans gerektirmeyen değerlendirmeler söz konusu olduğunda bunlar aynı madalyonun iki yüzü gibi görülebilir Referans gerektirmeyen değerlendirme, insan tarafından yazılmış bir yanıt gibi "golden" bir referansa dayanmadan yalnızca giriş prompt'u ve modelin yanıtını kullanarak çıktı kalitesini değerlendirebilen bir değerlendirmedir Referans gerektirmeyen değerlendirmeye örnek: özet değerlendirmesi Özetin olgusal tutarlılığını ve ilgililiğini değerlendirmek için yalnızca giriş belgesini dikkate almak yeterlidir Özet bu metriklerde düşük puan alıyorsa, kullanıcıya gösterilmemesi seçilebilir; böylece değerlendirme fiilen bir guardrail olarak kullanılmış olur Referans gerektirmeyen "çeviri" değerlendirmesi: İnsan tarafından yapılmış bir çeviri referansı olmadan da çeviri kalitesi değerlendirilebilir; bu da yine bir guardrail olarak kullanılabilir LLM'ler, yapmamaları gereken durumlarda da çıktı döndürür LLM'lerle çalışırken başlıca zorluklardan biri, LLM'in yapmaması gereken durumlarda bile sık sık çıktı üretmesidir Bu, zararsız ama anlamsız yanıtlardan zararlı veya riskli içerik gibi daha ciddi kusurlara kadar gidebilir Örneğin bir belgeden belirli özellikleri veya meta verileri çıkarması istendiğinde, ilgili değer gerçekte mevcut olmasa bile LLM kendinden emin şekilde bir değer döndürebilir Ya da bağlamda İngilizce dışı bir belge verildiği için model İngilizce dışı bir dilde yanıt verebilir LLM'e "uygulanamaz" veya "bilmiyorum" yanıtı döndürmesini söyleyen prompt'lar verilebilir, ancak bu kusursuz değildir Log olasılıkları kullanılabiliyor olsa bile, bunlar çıktı kalitesinin zayıf bir göstergesidir Log olasılıkları, token'ların çıktıda görünme olasılığını gösterir; ancak üretilen metnin doğruluğunu yansıtmaz Hatta sorgulara yanıt vermek ve tutarlı yanıtlar üretmek üzere eğitilmiş instruction-tuned modellerde log olasılıkları iyi kalibre edilmemiş olabilir Bu nedenle yüksek log olasılığı, çıktının akıcı ve tutarlı olduğunu gösterebilir; ancak doğru veya ilgili olduğu anlamına gelmez Dikkatli prompt mühendisliği bir ölçüde yardımcı olabilir, ancak bunu istenmeyen çıktıları tespit edip filtreleyen/yeniden üreten güçlü guardrail'lerle tamamlamak gerekir Örneğin OpenAI, nefret söylemi, kendine zarar verme veya cinsel içerik gibi güvensiz yanıtları tespit edebilen bir içerik moderasyon API'si sunar Benzer şekilde kişisel olarak tanımlanabilir bilgileri (PII) tespit etmek için çok sayıda paket vardır Guardrail'lerin bir avantajı, kullanım senaryosundan büyük ölçüde bağımsız olmaları ve bu nedenle belirli bir dildeki tüm çıktılara geniş ölçekte uygulanabilmeleridir Ayrıca hassas retrieval sayesinde ilgili belge yoksa sistem kararlı biçimde "bilmiyorum" yanıtı verebilir LLM'ler, çıktı beklenen durumlarda çıktı üretemeyebilir de Bu, API sağlayıcısının yüksek gecikmesi gibi basit sorunlardan içerik moderasyon filtreleri nedeniyle çıktının engellenmesi gibi daha karmaşık sorunlara kadar çeşitli nedenlerle olabilir Bu nedenle, hata ayıklama ve izleme için girdileri ve (gerekirse çıktı eksikliğini de) tutarlı biçimde kaydetmek önemlidir Halüsinasyon (Hallucination) kalıcı bir sorundur İçerik güvenliği ya da PII kusurları çok fazla dikkat gördüğü için nadiren ortaya çıkarken, olgusal tutarsızlıklar inatçı biçimde sürer ve tespit edilmesi daha zordur Daha yaygın görülür; taban görülme oranı %5-10’dur ve LLM sağlayıcılarından öğrendiğimize göre özetleme gibi basit görevlerde bile bunu %2’nin altına indirmek zor olabilir Bunu çözmek için prompt engineering (üretim öncesi) ile olgusal tutarsızlık guardrail’lerini (üretim sonrası) birleştirebilirsiniz Prompt engineering açısından, CoT gibi teknikler LLM’in nihai çıktıyı vermeden önce akıl yürütmesini açıklamasını sağlayarak halüsinasyonları azaltmaya yardımcı olur Ardından özetin olgusallığını değerlendirmek ve halüsinasyonları filtrelemek ya da yeniden üretmek için olgusal tutarsızlık guardrail’leri uygulanabilir Bazı durumlarda halüsinasyonlar deterministik olarak tespit edilebilir RAG aramasının kaynakları kullanıldığında, çıktı yapılandırılmışsa ve kaynağın ne olduğu tanımlanabiliyorsa, girdideki bağlamdan alınıp alınmadığı manuel olarak doğrulanabilmelidir [Operasyon: Günlük işleyiş (Day-to-Day) ve organizasyon sorunları ] Operasyon 1. Veri Nasıl malzemenin kalitesi yemeğin lezzetini belirliyorsa, girdi verisinin kalitesi de makine öğrenimi sisteminin performansını sınırlar Ayrıca çıktı verisi, ürünün çalışıp çalışmadığını bilmenin tek yoludur Tüm yazarlar, veri dağılımını (modlar, edge case’ler, modelin sınırları) daha iyi anlamak için her hafta birkaç saat boyunca girdileri ve çıktıları yakından inceler Geliştirme-prodüksiyon sapmasını kontrol etme Geleneksel makine öğrenimi pipeline’larında hataların yaygın nedenlerinden biri eğitim-servis sapmasıdır Bu, eğitimde kullanılan veri modelin prodüksiyonda karşılaştığı veriden farklı olduğunda ortaya çıkar Eğitim ya da fine-tuning olmadan LLM kullanılabildiği için bir eğitim seti yoktur, ancak buna benzer bir sorun olan geliştirme-prodüksiyon veri sapması ortaya çıkar Temel olarak, geliştirme sırasında sistemi test ettiğiniz verinin, sistemin prodüksiyonda karşılaşacağı veriyi yansıtması gerekir Aksi halde prodüksiyon doğruluğu düşebilir LLM geliştirme-prodüksiyon sapması iki türe ayrılabilir: yapısal sapma ve içerik temelli sapma Yapısal sapma; liste değerleri içeren bir JSON dictionary ile bir JSON list arasındaki fark, tutarsız büyük/küçük harf kullanımı ve yazım hataları ya da cümle parçaları gibi hatalar dahil olmak üzere biçim uyumsuzluğu gibi sorunları kapsar Bu tür hatalar, farklı LLM’lerin belirli veri biçimleriyle eğitilmiş olması ve prompt’ların küçük değişikliklere karşı çok hassas olabilmesi nedeniyle öngörülemez model performansına yol açabilir İçerik temelli ya da "semantik" sapma, verinin anlamı veya bağlamındaki farklılıkları ifade eder Geleneksel ML’de olduğu gibi, LLM girdi-çıktı çiftleri arasındaki sapmayı periyodik olarak ölçmek faydalıdır Girdi ve çıktı uzunluğu ya da belirli biçim gereksinimleri (ör. JSON veya XML) gibi basit metrikler, değişiklikleri takip etmenin kolay bir yoludur Daha "ileri" sapma tespiti için, kullanıcıların daha önce modele maruz kalmamış alanları keşfetmeye başladığını gösterebilecek, kullanıcıların tartıştığı konulardaki değişimler gibi semantik sapmaları tespit etmek amacıyla girdi-çıktı çiftlerinin embedding’lerini kümelemeyi değerlendirin Prompt engineering gibi değişiklikleri test ederken, holdout veri setinin güncel olduğundan ve kullanıcı etkileşimlerinin en son türlerini yansıttığından emin olun Örneğin prodüksiyon girdilerinde yazım hataları yaygınsa, holdout verisinde de bulunmalıdır Sapmayı yalnızca sayılarla ölçmenin ötesinde, çıktılar üzerinde nitel değerlendirme yapmak da yararlıdır Modelin çıktılarını düzenli olarak gözden geçirmek (argo olarak "vibe check" diye bilinen uygulama), sonuçların beklentileri karşılayıp karşılamadığını ve kullanıcı ihtiyaçlarıyla ilişkili kalmayı sürdürüp sürdürmediğini doğrular Sapma kontrolüne nondeterminism’i dahil etmek de faydalıdır Test veri setindeki her girdi için pipeline’ı birden fazla kez çalıştırıp tüm çıktıları analiz ederek, yalnızca ara sıra ortaya çıkabilen anormallikleri yakalama olasılığınız artar Her gün LLM girdi-çıktı örneklerini kontrol etmek LLM’ler dinamiktir ve sürekli evrilmektedir Etkileyici zero-shot yeteneklerine ve çoğu zaman tatmin edici çıktılara rağmen, LLM’lerin hata modları son derece öngörülemezdir Özelleştirilmiş görevlerde, LLM’in performansına dair sezgisel bir anlayış geliştirmek için veri örneklerini düzenli olarak incelemek şarttır Prodüksiyondaki girdi-çıktı çiftleri, LLM uygulamalarının "gerçek nesne, gerçek yer"idir (genchi genbutsu) ve bunun yerini başka bir şey tutamaz Son araştırmalar, geliştirici ne kadar çok veriyle etkileşime girerse "iyi" çıktı ve "kötü" çıktı algısının o kadar değiştiğini vurguluyor (yani ölçüt sapması) Geliştiriciler, LLM çıktılarını değerlendirmek için bazı ölçütleri önceden belirleyebilir, ancak bu önceden tanımlı ölçütler çoğu zaman eksiktir Örneğin geliştirme sürecinde, iyi yanıt olasılığını artırmak ve kötü yanıt olasılığını azaltmak için prompt güncellenebilir Değerlendirme, yeniden değerlendirme ve ölçüt güncellemenin bu yinelemeli süreci gereklidir; çünkü çıktıları doğrudan gözlemlemeden LLM davranışını ya da insan tercihlerini tahmin etmek zordur Bunu etkili biçimde yönetmek için LLM girdileri ve çıktıları kaydedilmelidir Bu log örneklerini her gün incelemek, yeni örüntüleri veya hata modlarını hızlıca tespit edip uyum sağlamayı mümkün kılar Yeni bir sorun keşfedildiğinde, bunun için hemen bir assertion ya da eval yazılabilir Benzer şekilde, hata modu tanımındaki tüm güncellemeler değerlendirme ölçütlerine yansıtılmalıdır Bu "vibe check"ler hatalı çıktının sinyalleridir; kod ve assertion’lar ise bunu operasyonel hale getirir Son olarak bu yaklaşımın yaygınlaştırılması gerekir Örneğin on-call rotasyonuna girdi ve çıktı inceleme ya da açıklama eklemek Operasyon 2. Modelle çalışmak LLM API’lerini kullanmak, az sayıda sağlayıcının zekâsına bağımlı olmanız anlamına gelebilir Bu iyi bir şeydir, ancak bu bağımlılık performans, gecikme, throughput ve maliyet açısından çeşitli ödünleşmeleri beraberinde getirir Ayrıca son bir yılda neredeyse her ay daha yeni ve daha iyi modeller çıktığından, eski modelleri emekliye ayırıp yeni modellere geçerken ürünü güncellemeye hazır olmalısınız Bu bölüm, tamamen kontrolünüzde olmayan, yani self-host edip yönetemeyeceğiniz teknolojileri kullanırken edinilen dersleri paylaşır Çoğu gerçek kullanım senaryosunda, LLM çıktısı downstream uygulamalar tarafından bir tür makine tarafından okunabilir biçim üzerinden tüketilecektir Örneğin gayrimenkul CRM’i ReChat, frontend’de widget render etmek için yapılandırılmış yanıtlara ihtiyaç duyar Benzer şekilde ürün stratejisi fikir üretim aracı Boba, başlık, özet, uygulanabilirlik puanı ve zaman aralığı alanlarını içeren yapılandırılmış çıktılara ihtiyaç duyar Son olarak LinkedIn, kullanılacak tekniği belirlemek ve tekniği çağırmak için parametreleri sağlamak amacıyla LLM’i YAML üretmeye kısıtlama yöntemini paylaştı Bu uygulama deseni, Postel yasasının uç bir versiyonudur Kabul ettiğiniz şeyde (serbest doğal dil) esnek, gönderdiğiniz şeyde (tiplenmiş, makine tarafından okunabilir nesneler) tutucu olmalısınız Bu nedenle bunun oldukça dayanıklı olmasını bekliyoruz Bugün Instructor ve Outlines, LLM’lerden yapılandırılmış çıktı elde etmek için fiili standarttır LLM API’leri (ör. Anthropic, OpenAI) kullanıyorsanız Instructor, self-host edilen modeller (ör. Huggingface) kullanıyorsanız Outlines kullanın Modeller arası prompt migrasyonu sancılıdır Bazen özenle hazırlanmış bir prompt bir modelde harika çalışırken başka bir modelde düzgün çalışmayabilir Bu durum yalnızca farklı model sağlayıcıları arasında geçiş yaparken değil, aynı modelin sürümleri arasında yükseltme yaparken de ortaya çıkabilir Örneğin Voiceflow, gpt-3.5-turbo-0301 sürümünden gpt-3.5-turbo-1106 sürümüne geçildiğinde niyet sınıflandırma görevlerinde performansın %10 düştüğünü fark etti (Neyse ki ellerinde değerlendirme vardı!) Benzer şekilde GoDaddy, 1106 sürümüne yükseltildiğinde gpt-3.5-turbo ile gpt-4 arasındaki performans farkının olumlu yönde daraldığını gözlemledi (Ya da bardağın dolu tarafına bakmıyorsanız, yeni yükseltmeyle gpt-4'ün liderliğinin azalmasına hayal kırıklığı olarak da bakabilirsiniz) Bu yüzden modeller arasında prompt taşımanız gerekiyorsa, bunun yalnızca API endpoint'ini değiştirmekten daha fazla zaman alacağını varsaymalısınız Aynı prompt'u bağlamanın benzer ya da daha iyi sonuçlar vereceğini varsaymayın Ayrıca güvenilir ve otomatik değerlendirmeler, geçiş öncesi ve sonrası görev performansını ölçmeye yardımcı olur ve manuel doğrulama için gereken çabayı azaltır Model sürüm yönetimi ve sabitleme Her makine öğrenimi hattında, "herhangi bir şeyi değiştirirseniz her şey değişir" Bu, özellikle bizim eğitmediğimiz ve bize haber verilmeden değişebilen büyük dil modelleri (LLM'ler) gibi bileşenlere bağımlı olduğumuzda daha da önemlidir Neyse ki birçok model sağlayıcısı, belirli bir model sürümünü (ör. gpt-4-turbo-1106) "sabitleme" seçeneği sunar Bu sayede model ağırlıklarının belirli bir sürümünü kullanıp onun değişmeden kalmasını sağlayabilirsiniz Üretimde model sürümünü sabitlemek, model davranışındaki beklenmedik değişiklikleri önleyebilir Bu, model değiştirildiğinde ortaya çıkabilecek aşırı uzun çıktılar veya diğer beklenmedik hata modları gibi sorunlar nedeniyle müşteri şikayetlerinden kaçınmaya yardımcı olabilir Ayrıca üretim ayarlarını yansıtan, ancak en yeni model sürümünü kullanan bir "gölge hat" sürdürmeyi de düşünebilirsiniz Bu, yeni sürümlerle güvenli deneyler ve testler yapmanızı sağlar Bu yeni modellerde çıktıların kararlılığını ve kalitesini doğruladıktan sonra, üretim ortamındaki model sürümünü güvenle güncelleyebilirsiniz İşi tamamlayabilecek en küçük modeli seçmek Yeni bir uygulama üzerinde çalışırken eldeki en büyük ve en güçlü modeli kullanma cazibesi vardır Ancak bir görevin teknik olarak mümkün olduğu doğrulandıktan sonra, benzer sonuçların daha küçük bir modelle elde edilip edilemeyeceğini denemek faydalıdır Küçük modellerin avantajı daha düşük gecikme ve maliyettir Daha zayıf olabilirler, ancak Chain-of-Thought, n-shot prompt'lar ve in-context learning gibi teknikler küçük modellerin kendi kapasitelerinin ötesine geçmesine yardımcı olabilir LLM API'lerinin ötesinde, belirli görevlere yönelik fine-tuning de performans artışına yardımcı olabilir Genel olarak, küçük modeller kullanan dikkatle tasarlanmış bir iş akışı, daha hızlı ve daha ucuz olurken tek bir büyük modelin çıktı kalitesine yetişebilir, hatta onu aşabilir Örneğin bu tweet, Haiku + 10-shot prompt'un zero-shot Opus ve GPT-4'ü nasıl geçtiğine dair bir anekdot paylaşıyor Uzun vadede, çıktı kalitesi, gecikme ve maliyet arasında en iyi dengeyi sağlayan küçük modellerle akış mühendisliğine dair daha fazla örnek ortaya çıkması bekleniyor Bir başka örnek olarak mütevazı sınıflandırma görevini ele alabiliriz DistilBERT (67 milyon parametre) gibi hafif modeller şaşırtıcı derecede güçlü bir başlangıç çizgisidir 400 milyon parametreli DistilBART da bir başka harika seçenektir Açık kaynak veriler üzerinde fine-tuning yapıldığında, çoğu LLM'yi %5'ten az gecikme ve maliyetle geride bırakarak halüsinasyonları 0.84 ROC-AUC ile tespit edebilir Buradaki çıkarım, küçük modelleri göz ardı etmemeniz gerektiğidir Her probleme devasa bir model uygulamak kolaydır, ancak biraz yaratıcılık ve denemeyle çoğu zaman daha verimli çözümler bulabiliriz Operasyon 3. Ürün Yeni teknoloji yeni imkanlar sunar, ancak harika ürünler inşa etmenin ilkeleri kalıcıdır Bu nedenle, ilk kez yeni bir problemi çözüyor olsanız bile ürün tasarımı konusunda tekerleği yeniden icat etmeniz gerekmez LLM uygulama geliştirmeyi sağlam ürün temelleri üzerine kurarak çok şey kazanılabilir Bu, hizmet verdiğimiz insanlara gerçek değer sunmamıza yardımcı olur Tasarımı en baştan sürece dahil etmek Tasarımcıların varlığı, ürünü nasıl inşa edebileceğimizi ve kullanıcılara nasıl sunabileceğimizi anlamamızı ve bunun üzerine derinlemesine düşünmemizi sağlar Bazen tasarımcıları sadece işleri güzel gösteren kişiler olarak klişeleştiririz Oysa onlar yalnızca kullanıcı arayüzünü değil, gerekirse mevcut kuralları ve paradigmaları bozarak kullanıcı deneyimini nasıl iyileştirebileceğimizi de yeniden düşünür Tasarımcılar, kullanıcı ihtiyaçlarını farklı biçimlerde yeniden çerçeveleme konusunda özellikle yeteneklidir Bu biçimlerin bazılarını çözmek diğerlerine göre daha kolaydır; dolayısıyla bazıları AI çözümleri için daha fazla, bazılarıysa daha az fırsat sunabilir Diğer birçok üründe olduğu gibi, AI ürünü geliştirmek de ürünü çalıştıran teknoloji etrafında değil, yapılacak iş etrafında şekillenmelidir Şu tür soruları kendinize sormaya odaklanın "Kullanıcı bu üründen hangi işi yapmasını istiyor? Bu iş bir chatbot'un iyi yapacağı türden bir iş mi? Ya otomatik tamamlama? Belki de bambaşka bir şeydir!" Mevcut tasarım kalıplarını ve bunların yapılacak işle nasıl ilişkili olduğunu değerlendirin Bunlar, tasarımcıların takımın yeteneklerine kattığı değerli varlıklardır Human-in-the-loop için UX tasarımı İyi kalitede açıklama/veri etiketi elde etmenin bir yolu, kullanıcı deneyimine (UX) Human-in-the-Loop (HITL) yaklaşımını entegre etmektir Kullanıcıların kolayca geri bildirim ve düzeltme sağlayabilmesi, hem anlık çıktıyı iyileştirir hem de modeli geliştirmek için faydalı veriler toplar Kullanıcıların ürün yükleyip sınıflandırdığı bir e-ticaret platformu hayal edelim UX’i tasarlamanın birden çok yolu vardır Kullanıcı doğru ürün kategorisini manuel olarak seçer, LLM ise periyodik olarak yeni ürünleri kontrol edip arka planda yanlış sınıflandırmaları düzeltir Kullanıcı hiç kategori seçmez, LLM ise periyodik olarak ürünleri arka planda sınıflandırır (olası hatalarla birlikte) LLM, ürün kategorisini gerçek zamanlı olarak önerir ve kullanıcı gerektiğinde bunu doğrulayıp güncelleyebilir Üç yaklaşımın tümü LLM içerir, ancak çok farklı UX sunar İlk yaklaşım başlangıç yükünü kullanıcıya bindirir ve LLM sonradan kontrol eden bir denetim katmanı görevi görür İkinci yaklaşım kullanıcıdan hiç çaba istemez, ancak şeffaflık ya da kontrol sunmaz Üçüncü yaklaşım uygun dengeyi kurar LLM’in önceden kategori önermesi, kullanıcının bilişsel yükünü azaltır ve ürünü sınıflandırmak için bizim taksonomimizi öğrenme gereğini ortadan kaldırır Aynı anda, kullanıcının öneriyi gözden geçirip düzenleyebilmesine izin vererek ürünün nasıl sınıflandırılacağına ilişkin nihai karar yetkisini güçlü biçimde kullanıcının elinde tutar Ek olarak üçüncü yaklaşım, modeli iyileştirmek için doğal bir geri bildirim döngüsü oluşturur İyi öneriler kabul edilir (pozitif etiket), kötü öneriler ise güncellenir (negatif ardından pozitif etiket) Öneri, kullanıcı doğrulaması ve veri toplama kalıbı birçok uygulamada yaygın olarak görülür Kodlama asistanı: kullanıcı öneriyi kabul edebilir (güçlü pozitif), kabul edip düzenleyebilir (pozitif) veya görmezden gelebilir (negatif) Midjourney: kullanıcı görseli upscale edip indirebilir (güçlü pozitif), görseli değiştirebilir (pozitif) ya da yeni bir görsel seti oluşturabilir (negatif) Chatbot: kullanıcı yanıta beğen (pozitif) veya beğenme (negatif) verebilir ya da yanıt gerçekten kötüyse yeniden yanıt üretmeyi seçebilir (güçlü negatif) Geri bildirim açık ya da örtük olabilir Açık geri bildirim, kullanıcının ürünün talebine yanıt olarak sağladığı bilgidir Örtük geri bildirim ise kullanıcının bilerek geri bildirim vermesi gerekmeden, kullanıcı etkileşimlerinden öğrenilen bilgidir Kodlama asistanları ve Midjourney örtük geri bildirime örnektir; beğen ve beğenme ise açık geri bildirimdir Kodlama asistanları ve Midjourney’de olduğu gibi UX’i iyi tasarlarsanız, hem ürünü hem de modeli geliştirmek için çok miktarda örtük geri bildirim toplayabilirsiniz Gereksinim hiyerarşisini acımasızca önceliklendirin Bir demoyu production’a almayı düşünürken, şu gereksinimleri göz önünde bulundurmak gerekir Güvenilirlik: %99,9 uptime, yapılandırılmış çıktı uyumu Zararsızlık: saldırgan, NSFW veya başka türlü zararlı içerik üretmemek Olgusal tutarlılık: sağlanan bağlama sadık kalmak ve gerçekleri çarpıtmamak Faydalılık: kullanıcının ihtiyaç ve talepleriyle ilgili olmak Ölçeklenebilirlik: gecikme SLA’leri, desteklenen throughput Maliyet: çünkü bütçe sınırsız değildir Diğerleri: güvenlik, gizlilik, adillik, GDPR, DMA vb. Bu gereksinimlerin hepsini aynı anda çözmeye çalışırsanız, hiçbir şeyi yayına alamazsınız Bu yüzden önceliklendirme yapmalısınız. Hem de acımasızca. Bu, ürünün çalışmamasına ya da uygulanabilir olmamasına yol açabilecek, taviz verilemez unsurların (ör. güvenilirlik, zararsızlık) ne olduğunu netleştirmek anlamına gelir MVP (Minimum Lovable Product) ürünü tanımlamak önemlidir İlk sürümün mükemmel olmayacağını kabul etmeli, yayına almalı ve yinelemelisiniz Kullanım durumuna göre risk toleransını ayarlayın Dil modeli ve uygulamalar için ne düzeyde inceleme gerektiğine karar verirken, kullanım durumunu ve hedef kitleyi dikkate almalısınız Tıbbi veya finansal tavsiye veren, müşteriye dönük bir chatbot için güvenlik ve doğruluk açısından çok yüksek bir standart gerekir Hatalar veya yanlış çıktılar gerçek zarara yol açabilir ve güven kaybı yaratabilir Buna karşılık öneri sistemleri gibi daha az kritik uygulamalarda ya da içerik sınıflandırma veya özetleme gibi iç kullanıma dönük uygulamalarda, aşırı katı gereksinimler fazla değer katmadan sadece ilerlemeyi yavaşlatır Bu, birçok şirketin dışa dönük uygulamalara kıyasla iç LLM uygulamalarında daha hızlı ilerlediğini söyleyen yakın tarihli a16z raporuyla da uyumludur Kurumlar, iç verimlilik için AI deneyleri yaparak, daha kontrollü bir ortamda riski nasıl yöneteceklerini öğrenirken değer elde etmeye başlayabilir Ardından, güven kazandıkça bunu müşteriye dönük kullanım senaryolarına genişletebilirler Operasyon 4. Takım ve roller Hiçbir iş rolünü tanımlamak kolay değildir, ancak bu yeni alanda iş tanımı yazmak diğerlerinden daha da zordur Kesişen unvanlara dair bir Venn diyagramını ya da iş tanımı önerilerini burada atlayacağım Ancak yeni bir rol olan AI engineer’ın varlığını kabul edip bu rolü tartışacağım Daha önemlisi, ekibin geri kalanında görev ve sorumlulukların nasıl dağıtılması gerektiğini tartışacağım Araçlara değil sürece odaklanın LLM gibi yeni bir paradigma ile karşılaşıldığında, yazılım mühendisleri araçlara yönelme eğilimindedir Bunun sonucunda, bu araçların çözmeye çalıştığı problemler ve süreçler gözden kaçabilir Böyle yapıldığında birçok mühendis tesadüfi karmaşıklığı üzerine alır ve bu da ekibin uzun vadeli üretkenliğini olumsuz etkiler Örneğin bu yazı, belirli bir aracın büyük dil modelleri için prompt’ları nasıl otomatik üretebildiğini açıklıyor Buradaki sav, problem çözme metodolojisini veya sürecini önce anlamadan bu araçları kullanan mühendislerin sonunda gereksiz teknik borç yükleneceğidir (bence haklı olarak) Tesadüfi karmaşıklığın yanı sıra, araçlar çoğu zaman yetersiz biçimde tanımlanmıştır Örneğin zararlılık, kısalık, ton vb. için genel değerlendiriciler içeren “LLM evaluation toolbox” sunan bir LLM değerlendirme araçları endüstrisi büyüyor Birçok ekibin, kendi alanlarına özgü hata modları üzerine eleştirel biçimde düşünmeden bu araçları benimsediğini görüyorum Buna karşılık EvalGen, alan özelinde değerlendirmeler üretme sürecini kullanıcıya öğretmeye; kullanıcıyı ölçüt tanımlama, veri etiketleme, değerlendirmeyi doğrulama gibi her adıma derinlemesine dahil etmeye odaklanır Yazılım, kullanıcıyı şu tür bir iş akışıyla yönlendirir EvalGen’in yönlendirdiği LLM değerlendirmesi oluşturma için en iyi uygulamalar Alana özgü testleri tanımlayın (prompt’lardan otomatik olarak bootstrap edilir) Kodla veya LLM-as-a-Judge ile assertion olarak tanımlanır Testlerin tanımlanan ölçütleri yakaladığını kullanıcının doğrulayabilmesi için, testleri insan yargısıyla hizalamanın önemini anlayın Sistem (prompt vb.) değiştikçe testleri yineleyin EvalGen, geliştiricilere değerlendirme oluşturma süreci için bir mental model sunar, ancak onları belirli bir araca kilitlemez AI engineer’lara bu bağlam sağlandıktan sonra, çoğu zaman daha basit araçları seçmeye ya da kendi araçlarını geliştirmeye karar verdiklerini görüyoruz Prompt yazımı ve değerlendirme dışında, LLM’in o kadar çok bileşeni vardır ki hepsini burada listelemek mümkün değildir Yine de AI engineer’ların araçları benimsemeden önce süreci anlamaya çalışması önemlidir Her zaman deney yapın ML ürünleri deneylerle yakından ilişkilidir Bu, yalnızca A/B testleri ve rastgele kontrollü deneyler değil, aynı zamanda sistemin mümkün olan en küçük bileşenlerini değiştirip çevrimdışı değerlendirmeler yapmaya yönelik sık girişimler anlamına gelir Herkesin değerlendirmelere bu kadar ilgi duymasının nedeni, bunun aslında güvenilirlik ve özgüvenle değil, deney yapmayı mümkün kılmasıyla ilgili olmasıdır! Değerlendirme ne kadar iyiyse, deneyleri o kadar hızlı yineleyebilirsiniz; dolayısıyla sistemin en iyi sürümüne de o kadar hızlı yakınsarsınız Deney yapmak çok ucuz hale geldiği için, aynı problemi çözmek adına farklı yaklaşımlar denemek artık yaygındır Veri toplama ve model eğitiminin yüksek maliyeti en aza inmiştir Prompt engineering maliyeti, insan zamanının biraz ötesine geçer Herkesin prompt engineering temellerini öğrenebilmesi için ekibi buna göre yapılandırın Bu, herkesi deney yapmaya teşvik eder ve organizasyon genelinde çeşitli fikirlere yol açar Yalnızca keşif için deney yapmayın; deneyleri kullanımdan yararlanmak için de kullanın! Yeni bir görevin çalışan bir sürümü var mı? Ekipten başka birinin buna farklı bir şekilde yaklaşmasını değerlendirin Daha hızlı olabilecek farklı bir yöntem deneyin Kaliteyi artırmak için Chain-of-Thought veya Few-Shot gibi prompt tekniklerini araştırın Araçların deney yapmayı engellememesini sağlayın Öyleyse yeniden inşa edin ya da iyileştirilebilecek bir şeyi satın alın Ürün/proje planlaması sırasında, değerlendirme oluşturmak ve birden çok deney yürütmek için ayrıca zaman ayırın Mühendislik ürününe yönelik ürün gereksinimlerini düşünün ve buna değerlendirme için net kriterler ekleyin Yol haritası hazırlarken deneyler için gereken süreyi olduğundan az tahmin etmeyin Prodüksiyon onayı almadan önce birden fazla geliştirme ve değerlendirme iterasyonu olacağını varsayın Herkese yeni AI teknolojilerini kullanma yetkisi verin Üretken yapay zekanın benimsenmesi arttıkça, yalnızca uzmanların değil tüm ekibin bu yeni teknolojiyi anlayabildiğini ve kullanabildiğini hissetmesini istersiniz LLM'lerin nasıl çalıştığına dair sezgi geliştirmek için daha iyi bir yol yoktur (ör. gecikme, hata modları, UX) LLM'ler nispeten erişilebilirdir Pipeline performansını artırmak için kod yazmayı bilmek gerekmez; herkes prompt engineering ve değerlendirme yoluyla katkı sunabilir Bunun büyük bir bölümü eğitimdir n-shot prompting ve CoT gibi tekniklerin, modeli istenen çıktı yönüne koşullandırmaya nasıl yardımcı olduğuna uzanan prompt engineering temelleriyle başlayabilirsiniz Bilgi sahibi kişiler, LLM'lerin özünde otoregresif olması gibi daha teknik yönler hakkında da eğitim verebilir Yani giriş token'ları paralel olarak işlenir, ancak çıkış token'ları sıralı olarak üretilir Bu nedenle gecikme, giriş uzunluğundan çok çıkış uzunluğunun bir fonksiyonudur Bu, UX tasarlarken ve performans beklentilerini belirlerken temel bir dikkate alma noktasıdır Deney ve keşif için uygulamalı fırsatlar da sunabilirsiniz Bir hackathon nasıl olur? Tüm ekibin birkaç gün boyunca spekülatif projeler üzerinde uğraşması pahalı görünebilir, ancak sonuçlar sizi şaşırtabilir Bir hackathon sayesinde 3 yıllık yol haritasını neredeyse 1 yılda tamamlayan bir ekip oldu Başka bir ekip ise hackathon aracılığıyla, artık LLM'ler sayesinde mümkün hale gelen bir paradigma değişimi UX'ine ulaştı; bu da artık bu yılın ve sonrasının önceliği haline geldi "AI engineering her şeydir" tuzağına düşmeyin Yeni bir unvan ortaya çıktığında, başlangıçta bu rolle ilişkili yetkinlikleri abartma eğilimi vardır Bu da çoğu zaman, bu işlerin gerçek kapsamı netleştikçe acı verici düzeltmelere yol açar Bu alana yeni girenler ve işe alım yöneticileri abartılı iddialarda bulunabilir veya aşırı beklentilere kapılabilir Son 10 yıldaki dikkat çekici örnekler şunlardır Veri bilimci: "Tüm yazılım mühendislerinden istatistiği daha iyi bilen ve tüm istatistikçilerden yazılım mühendisliğini daha iyi bilen kişi" Makine öğrenimi mühendisi (MLE): makine öğrenimine yazılım mühendisliği merkezli bir bakış Başlangıçta birçok kişi, veri odaklı projeler için yalnızca veri bilimcilerin yeterli olduğunu varsaydı Ancak veri bilimcilerin, veri ürünlerini etkili biçimde geliştirmek ve dağıtmak için yazılım ve veri mühendisleriyle birlikte çalışması gerektiği zamanla netleşti Bu yanlış anlama, AI engineer gibi yeni bir rolde yeniden ortaya çıktı ve bazı ekipler AI engineer'ın ihtiyaç duyulan tek şey olduğuna inandı Oysa pratikte, makine öğrenimi veya yapay zeka ürünü geliştirmek çok çeşitli uzman rolleri gerektirir 12'den fazla şirket ve AI ürünü hakkında danışmanlık verdik ve onların sürekli olarak "AI engineering ihtiyacınız olan tek şeydir" inancı tuzağına düştüğünü gözlemledik Sonuç olarak ürünler, ürün geliştirmek için gereken kritik yönleri gözden kaçırdıkları için, demoların ötesine ölçeklenmekte çoğu zaman zorlandı Örneğin değerlendirme ve ölçüm, ürünü bir vibe check'in ötesine taşıyıp ölçeklemek için kritiktir Etkili değerlendirme için gereken beceriler, geleneksel olarak makine öğrenimi mühendislerinde görülen bazı güçlü yönlerle örtüşür Yalnızca AI engineer'lardan oluşan bir ekibin bu becerilerden yoksun olma ihtimali yüksektir Ortak yazarlardan Hamel Husain, veri yanlılığını tespit etme ve alana özgü değerlendirmeler tasarlamayla ilgili yakın dönem çalışmalarında bu becerilerin önemini açıklıyor AI ürünü oluşturma yolculuğunda hangi rol türlerinin ne zaman gerekli olduğu Önce ürün oluşturmaya odaklanın Bu aşamada AI engineer yer alabilir, ancak bu zorunlu değildir AI engineer, ürünü (UX, plumbing vb.) prototiplemek ve hızlı yinelemeler yapmak için faydalıdır Sonraki adımda, sistemi enstrümante edin ve doğru temeli kurmak için veri toplayın Verinin türüne ve ölçeğine bağlı olarak platform ve/veya veri mühendislerine ihtiyaç duyabilirsiniz Ayrıca sorunları debug etmek için bu veriyi sorgulayıp analiz edebileceğiniz sistemler de olmalıdır Sonra AI sistemini optimize edin Bu mutlaka model eğitimi anlamına gelmez Temel aşamalar arasında metrik tasarımı, değerlendirme sistemi kurma, deney yürütme, RAG retrieval optimizasyonu, olasılıksal sistemleri debug etme gibi adımlar yer alır MLE'ler bu alanda çok yetkindir (elbette AI engineer'lar da bunu edinebilir) Önceki adımları tamamlamadıysanız MLE işe almak genellikle mantıklı değildir Bunun dışında her zaman alan uzmanlarına ihtiyaç vardır Küçük şirketlerde ideal olarak bu rolü kurucu ekip üstlenmelidir; büyük şirketlerde ise bu rolü ürün yöneticileri üstlenebilir Roller arasındaki ilerleyişi ve zamanlamayı fark etmek önemlidir Yanlış zamanda insan işe almak (ör. MLE'yi çok erken işe almak) veya yanlış sırayla inşa etmek; zaman ve para kaybıdır, ayrıca işten ayrılmalara yol açar Ayrıca 1-2. aşamalarda MLE'lerle düzenli check-in yapmak (ancak onları tam zamanlı işe almamak), şirketin doğru temeli kurmasına yardımcı olur [Strateji: LLM ile ürün geliştirirken geride kalmamanın yolları] Başarılı ürün geliştirme için, rastgele prototip üretmek veya en yeni modeli ya da trendi takip etmek yerine dikkatli planlama ve önceliklendirme gerekir AI ürünü geliştirirken, doğrudan geliştirmek mi yoksa satın almak mı gibi temel trade-off'ları gözden geçirmek gerekir İlk LLM uygulamalarını geliştirmek için bir "playbook" sunuluyor Strateji 1: PMF öncesi GPU yok Harika bir ürün olmak için, başkalarının API'sini yüzeysel biçimde paketlemekten daha fazlası olmak gerekir Ancak ters yöndeki hata daha büyük maliyetlere yol açabilir Geçen yıl, net bir ürün vizyonu veya hedef pazar olmadan model eğitimi ve özelleştirmeye çok büyük miktarda girişim sermayesi harcandı Hatta bir şirket tam 6 milyar dolarlık Series A yatırımı aldı Bu bölüm, neden hemen kendi modelinizi eğitmeye başlamanın bir hata olduğunu açıklayacak ve self-hosting'in rolünü değerlendirecek En baştan (neredeyse) yeniden eğitmek anlamlı değil Çoğu organizasyon için bir LLM’i en baştan pretraining etmek, ürün geliştirmeden uzaklaşan gerçekçi olmayan bir iştir Makine öğrenimi altyapısını geliştirmek ve sürdürmek çok fazla kaynak gerektirir Buna veri toplama, model eğitimi ve değerlendirmesi, dağıtım gibi işler dahildir Ürün-pazar uyumunu doğrulama aşamasındaysanız, bu tür çabalar kaynakları çekirdek ürün geliştirmeden uzaklaştırır Hesaplama kaynağı, veri ve teknik yetkinlik olsa bile, pretrain edilmiş bir LLM birkaç ay içinde demode hale gelebilir BloombergGPT örneği Finansal iş akışlarına özelleşmiş bir LLM olan BloombergGPT, 363B token ile pretraining edildi Yapay zeka mühendisliğinden 4 kişi, ML ürün ve araştırmadan 5 kişi olmak üzere 9 tam zamanlı çalışanın büyük emeği harcandı Buna rağmen 1 yıl içinde söz konusu görevlerde gpt-3.5-turbo ve gpt-4’ün gerisinde kaldı Bu örnekler, çoğu gerçek dünya uygulamasında LLM’i sıfırdan pretraining etmenin kaynakların en iyi kullanımı olmadığını gösteriyor Bunun yerine ekiplerin, belirli gereksinimlere göre mevcut en güçlü açık kaynak modeli fine-tune etmesi daha iyidir Elbette istisnalar vardır Replit’in kod modeli, kod üretimi ve anlamaya özelleşmiş, pretraining’in iyi bir örneğidir Pretraining sayesinde CodeLlama7b gibi daha büyük modellerden daha iyi performans gösterdi Ancak daha güçlü modeller piyasaya çıktıkça, faydasını korumak için sürekli yatırım gerekti Gerektiği doğrulanana kadar fine-tuning yapmayın Çoğu organizasyonda fine-tuning, stratejik düşünceden çok FOMO (Fear Of Missing Out, fırsatı kaçırma korkusu) tarafından yönlendirilir Organizasyonlar, “sadece basit bir wrapper” suçlamasından kaçınmak için fine-tuning’e çok erken yatırım yapar Oysa fine-tuning, ancak diğer yaklaşımların yeterli olmadığına ikna edecek kadar çok örnek toplandıktan sonra devreye alınması gereken ağır ekipman gibidir 1 yıl önce birçok ekip fine-tuning konusunda heyecanlıydı, ancak çok azı ürün-pazar uyumunu yakaladı ve çoğu kararından pişman oldu Fine-tuning yapacaksanız, temel model geliştikçe bunu tekrar tekrar yapmaya hazır olmalısınız Aşağıdaki “Model ürün değildir” ve “LLMOps kurmak” bölümlerine bakın Fine-tuning’in gerçekten doğru seçim olabileceği durumlar Mevcut modellerin eğitiminde kullanılan açık web ölçeğindeki veri setlerinin çoğunda bulunmayan verilere ihtiyaç duyuluyorsa Mevcut modellerin yeterli olmadığını gösteren bir MVP’yi zaten oluşturduysanız Ancak dikkatli olun: Harika eğitim verilerine model geliştiricileri bile kolayca erişemiyorsa, siz bunları nereden bulacaksınız? LLM tabanlı uygulamalar bilim fuarı projesi değildir Yapılan yatırım, stratejik hedeflere ve rekabetçi farklılaşmaya katkısıyla orantılı olmalıdır Çıkarım API’leriyle başlayın, ama self-hosting’den korkmayın LLM API’lerini kullanmak, girişimlerin kendi modellerini sıfırdan eğitmeden dil modelleme yeteneklerini kolayca benimsemesini ve entegre etmesini sağlar Anthropic, OpenAI ve benzeri sağlayıcılar, yalnızca birkaç satır kodla ürüne zeka katabilecek genel API’ler sunar Bu hizmetleri kullanmak, harcanan çabayı azaltır ve müşteriler için değer üretmeye odaklanmanızı sağlayarak fikirleri doğrulamayı ve ürün-pazar uyumuna daha hızlı yinelemelerle ulaşmayı mümkün kılar Ancak veritabanlarında olduğu gibi, yönetilen hizmetler ölçek ve gereksinimler arttıkça her kullanım senaryosuna uygun olmayabilir Hatta self-hosting, sağlık ve finans gibi regülasyona tabi sektörlerde ya da sözleşmesel yükümlülükler ve gizlilik gereksinimleri nedeniyle, gizli/kişisel verileri ağ dışına göndermeden modeli kullanmanın tek yolu olabilir Ayrıca self-hosting, çıkarım sağlayıcılarının dayattığı hız sınırları, modelin kullanımdan kaldırılması ve kullanım kısıtları gibi sınırlamaları aşar Self-hosting, model üzerinde tam kontrol sağlayarak farklılaşmış ve yüksek kaliteli sistemler kurmayı kolaylaştırır Son olarak self-hosting, özellikle de fine-tuning, büyük ölçekte maliyetleri düşürebilir Örneğin Buzzfeed, açık kaynak bir LLM’i fine-tune ederek maliyetleri %80 azalttığını paylaşmıştı Strateji 2: Daha iyisine doğru yinelemek Uzun vadede rekabet avantajını korumak için modelin ötesinde, ürünü farklılaştırabilecek unsurları düşünmek gerekir Uygulama hızı önemlidir, ancak tek avantaj bu olmamalıdır Model ürün değildir, ürün modeli çevreleyen sistemdir Model inşa etmeyen ekipler için yeniliğin hızlı temposu bir nimettir Çünkü bağlam boyutu, akıl yürütme yeteneği ve fiyat/performans gibi iyileştirmeleri takip ederek en yeni modellere geçip daha iyi ürünler oluşturabilirler Bu ilerlemeler öngörülebilir olacak kadar heyecan vericidir Bütün bunlar birlikte düşünüldüğünde, model muhtemelen sistemde en az kalıcı bileşendir Bunun yerine çabayı kalıcı değer sağlayabilecek kısımlara yoğunlaştırmak gerekir Evals: farklı modeller genelinde görev performansını güvenilir biçimde ölçmek için Guardrails: modelden bağımsız olarak istenmeyen çıktıları önlemek için Caching: modeli tamamen devre dışı bırakarak gecikmeyi ve maliyeti azaltmak için Data flywheel: yukarıdakilerin hepsinde yinelemeli iyileştirmeyi hızlandırmak için Bu bileşenler, ham model yeteneklerinden daha güçlü bir ürün kalitesi hendeği oluşturur Ancak bu, uygulama katmanında bir şeyler inşa etmenin risksiz olduğu anlamına gelmez OpenAI veya diğer model sağlayıcılarının uygulanabilir kurumsal yazılımlar sunabilmesi için kaçınılmaz olarak çözeceği alanlarda yatırım yapmayın Örneğin bazı ekipler, özel modellerden gelen yapılandırılmış çıktıları doğrulamak için özel araçlar geliştirmeye yatırım yaptı Burada asgari düzeyde yatırım önemlidir, ancak derin yatırım yapmak zamanı iyi kullanmak değildir OpenAI, function calling istendiğinde geçerli function calling çıktısı sağlamalıdır; çünkü bunu tüm müşteriler ister Burada “stratejik erteleme” uygulayın, mutlak gerekli olanı inşa edin ve sağlayıcının yeteneklerini genişletmesini bekleyin Küçük başlayın ve güven kazanın Herkes için her şey olmaya çalışan bir ürün yapmak, sıradanlığın reçetesidir İkna edici bir ürün oluşturmak için şirketler, kullanıcıları geri getiren yapışkan deneyimler üretme konusunda uzmanlaşmalıdır Kullanıcıların sorduğu her soruyu yanıtlamayı hedefleyen genel bir RAG sistemini düşünün Uzmanlaşma eksikliği, sistemin güncel bilgiye öncelik verememesi, alana özgü formatları ayrıştıramaması veya belirli görevlerin nüanslarını anlayamaması anlamına gelir Sonuç olarak kullanıcılar yüzeysel ve güvenilmez bir deneyim yaşar; ihtiyaçları karşılanmaz ve ürünü terk ederler Bunu çözmek için belirli alanlara ve kullanım senaryolarına odaklanmak gerekir Genişlik yerine derinlik katarak kapsam daraltılmalıdır Böylece kullanıcıda karşılık bulan, alana özgü araçlar geliştirilebilir Uzmanlaşma sayesinde sistemin yetenekleri ve sınırları dürüstçe anlatılabilir Sistemin ne yapabildiği ve ne yapamadığı konusunda şeffaf olmak, öz farkındalık gösterir; kullanıcıların en çok nerede değer katabileceklerini anlamalarına yardımcı olur ve sonuçta çıktılara duyulan güveni artırır LLMOps kurun, ama doğru gerekçeyle: hızlı yineleme DevOps temelde yeniden üretilebilir iş akışları, sola kaydırma ya da iki pizzalık ekiplere yetki vermek değildir. Hele hele YAML dosyaları yazmak hiç değildir DevOps, hata yerine iyileştirmelerin birikmesini sağlamak için iş ile sonuçları arasındaki geri bildirim döngüsünü kısaltmaktır Kökleri, yalın girişim hareketi üzerinden yalın üretim ve Toyota Production System'a kadar uzanır; single-minute die exchange ve kaizen'i vurgular MLOps, DevOps'un biçimini ML'e uyguladı Yeniden üretilebilir deneyler ve model geliştiricilerin dağıtım yapabilmesini sağlayan hepsi bir arada araç paketleri vardır. Bir sürü YAML dosyası da vardır Ancak sektör olarak MLOps, DevOps'un işlevini benimsemedi. Model ile üretimdeki çıkarım ve etkileşimler arasındaki geri bildirim açığını azaltmadı Neyse ki LLMOps alanı, prompt yönetimi gibi tali sorunlardan uzaklaşıp iterasyonu engelleyen zor sorunlara, yani üretim izleme ve değerlendirmeyle bağlantılı sürekli iyileştirmeye doğru yön değiştirdi Zaten sohbet ve kodlama modelleri için tarafsız ve crowdsourced değerlendirme sağlayan konuşmalı arenalar var. Bu, kolektif ve yinelemeli iyileştirmenin dış döngüsüdür LangSmith, Log10, LangFuse, W&B Weave, HoneyHive gibi araçlar yalnızca üretimde sistem çıktılarıyla ilgili verileri toplama ve düzenleme değil, aynı zamanda bu sistemleri iyileştirmek için geliştirme süreçlerine derin entegrasyon da vaat ediyor. Bu araçları benimseyin ya da kendiniz geliştirin Satın alabileceğiniz LLM özelliklerini yapmayın Başarılı işlerin çoğu LLM işi değildir. Aynı zamanda çoğu işte LLM ile iyileştirme fırsatı vardır Bu iki gözlem, liderleri sık sık yanlış yönlendirir; maliyeti artırıp kaliteyi düşürürken sistemleri alelacele LLM ile elden geçirip yapay ve gösteriş meraklısı "AI" özellikleri olarak piyasaya sürmelerine yol açar. Korkulan pırıltılı simge artık tamamlanmıştır Daha iyi bir yol var: ürün hedefleriyle gerçekten uyumlu olan ve temel operasyonları güçlendiren LLM uygulamalarına odaklanın Ekibin zamanını boşa harcayan bazı yanlış denemeleri ele alalım İşiniz için özel bir text-to-SQL özelliği geliştirmek Belgelerle sohbet edebilen bir chatbot geliştirmek Şirket bilgi tabanını müşteri destek chatbot'u ile entegre etmek Bunlar LLM uygulamalarının hello world'ü olsa da, bir ürün şirketinin bunları bizzat geliştirmesi mantıklı değildir Çünkü bunlar birçok işte ortak olan genel problemlerdir; umut veren demolarla güvenilir bileşenler arasındaki fark büyüktür ve bu alan yazılım şirketlerinin alışıldık uzmanlık sahasıdır Y Combinator'ın mevcut batch'inde büyük ölçekte çözülmekte olan genel problemlere değerli Ar-Ge kaynakları yatırmak israftır Bu size basmakalıp bir iş tavsiyesi gibi geliyorsa, bunun nedeni mevcut hype dalgasının coşkulu heyecanı içinde "LLM" diye bir şeyin ileri düzey ve farklılaştırıcı olduğunun kolayca sanılması ve aslında çoktan sıradanlaşmış uygulamaların gözden kaçırılmasıdır AI'ı döngüye dahil edin, insanı merkeze koyun Bugünün LLM tabanlı uygulamaları kırılgandır. Çok büyük miktarda güvenlik önlemi ve savunmacı mühendislik gerektirirler ama yine de öngörülmesi zordur. Üstelik kapsamları sıkı biçimde tanımlandığında son derece faydalı olabilirler. Bu da LLM'lerin kullanıcı iş akışını hızlandıran mükemmel araçlar olduğu anlamına gelir LLM tabanlı uygulamaların iş akışını tamamen değiştirmesini ya da işlevlerin yerini almasını hayal etmek isteyebilirsiniz, ancak bugün en etkili paradigma insan-bilgisayar centaur'udur (Centaur chess) Yetkin bir insan, kendi hızlı kullanımına göre ayarlanmış LLM yetenekleriyle birleştiğinde, iş yapma verimliliği ve memnuniyeti büyük ölçüde artabilir LLM'lerin öne çıkan uygulamalarından biri olan GitHub CoPilot, bu iş akışının gücünü kanıtladı "Genel olarak geliştiriciler, GitHub Copilot ve GitHub Copilot Chat kullandıklarında kod yazmanın daha kolay olduğunu ve ortaya çıkan kodun daha az hatalı, daha okunabilir, daha yeniden kullanılabilir, daha özlü, daha kolay bakım yapılabilir ve daha dayanıklı olduğunu hissettiklerini söyledi." - Mario Rodriguez, GitHub Uzun süredir ML üzerinde çalışan kişiler "human-in-the-loop" fikrine hızla yönelebilir, ancak bu kadar acele etmeyin HITL machine learning, ML modelinin öngörüldüğü gibi çalışmasını sağlayan insan uzmanlara dayalı bir paradigmadır Burada önerilen şey bununla ilişkili olsa da daha inceliklidir. LLM tabanlı sistemler bugün çoğu iş akışının ana itici gücü olmamalı; yalnızca bir kaynak olmalıdır İnsanı merkeze koyup LLM'nin iş akışını nasıl destekleyebileceğini sormak, ürün ve tasarım kararları üzerinde oldukça farklı etkiler yaratır Sonuçta, tüm sorumluluğu hızla LLM'lere devretmeye çalışan rakiplerden farklı bir ürün ortaya çıkarırsınız; yani daha iyi, daha faydalı ve daha az riskli bir ürün Strateji 3. Prompting, Eval ve veri toplamayla başlamak Önceki bölümde çok sayıda teknik ve tavsiye sunduk. Bu, sindirmesi zor bir miktar. Yararlı tavsiyelerin asgari kümesini ele alalım Ekip bir LLM ürünü yapmak istiyorsa, nereden başlamalı? Son 1 yılda, başarılı LLM uygulamalarının tutarlı bir yörünge izlediğine bizi ikna edecek kadar çok örnek gördük. Bu bölümde bu temel "başlangıç" playbook'unu inceleyeceğiz Temel fikir, basit başlayıp ihtiyaç oldukça karmaşıklık eklemektir Rule of Thumb: Her bir gelişmişlik seviyesi, genellikle bir önceki aşamaya göre en az bir büyüklük mertebesi daha fazla çaba gerektirir. Bunu akılda tutarak... Öncelik 1: prompt engineering İşe prompt engineering ile başlayın Daha önce taktikler bölümünde tartışılan tüm teknikleri kullanın Chain-of-thought, n-shot örnekler ve yapılandırılmış girdi/çıktı neredeyse her zaman iyi bir fikirdir Zayıf bir modelden performans sıkıştırmaya çalışmadan önce prototipi en yüksek performanslı modelle oluşturun Yalnızca prompt engineering ile istenen performans düzeyine ulaşılamıyorsa fine-tuning düşünülmelidir Bu, proprietary model kullanımını engelleyen ve self-hosting gerektiren işlevsel olmayan gereksinimleriniz (ör. veri gizliliği, tam kontrol, maliyet) olduğunda daha sık ortaya çıkar Aynı gizlilik gereksinimlerinin, fine-tuning için kullanıcı verisinin kullanılmasını engellemediğinden emin olun Değerlendirmeleri oluşturun ve veri flywheel'ini başlatın Daha yeni başlayan ekiplerin bile değerlendirmelere (evals) ihtiyacı vardır. Aksi halde prompt engineering'in yeterli olup olmadığını ya da fine-tuned bir modelin temel modelin yerini almaya hazır olup olmadığını bilemezsiniz Etkili değerlendirmeler göreve özeldir ve hedeflenen kullanım durumunu yansıtır Önerdiğimiz ilk seviye değerlendirme, unit test'tir Bu basit assertion'lar, bilinen veya varsayılan hata modlarını tespit etmeye ve ilk tasarım kararlarını vermeye yardımcı olur Sınıflandırma, özetleme vb. için diğer göreve özel değerlendirmelere de bakın Unit test'ler ve model tabanlı değerlendirmeler faydalıdır, ancak insan değerlendirmesinin yerini tutmaz İnsanların modeli/ürünü kullanmasına ve geri bildirim vermesine imkân tanıyın Bu, gerçek performansı ve hata oranlarını ölçerken aynı zamanda gelecekte modeli fine-tuning için kullanılabilecek yüksek kaliteli açıklamalı veriler toplama gibi ikili bir amaca hizmet eder Bu, zamanla bileşik etki yaratan olumlu bir geri bildirim döngüsü ya da veri flywheel'i oluşturur Model performansını değerlendirmek veya kusurları bulmak için insan değerlendirmesi Açıklamalı verileri kullanarak modeli fine-tuning yapmak ya da prompt'ları güncellemek Tekrarlayın Örneğin, LLM tarafından üretilen özetlerdeki kusurları denetlerken, her cümle için olgusal tutarsızlık, ilgisizlik veya kötü üslup gibi ayrıntılı geri bildirim etiketleri atayabilirsiniz Sonrasında bu olgusal tutarsızlık açıklamalarını bir halüsinasyon sınıflandırıcısı eğitmek için ya da ilgililik açıklamalarını bir ilgililik ödül modeli eğitmek için kullanabilirsiniz LinkedIn, halüsinasyon, sorumlu yapay zeka ihlalleri, tutarlılık vb. tahmin etmek için model tabanlı değerlendiricileri kullanarak başarı hikâyeleri paylaştı Zamanla değeri artan varlıklar oluşturarak, değerlendirme (evals) oluşturmayı yalnızca bir operasyonel maliyetten stratejik bir yatırıma dönüştürün ve bu süreçte veri flywheel'ini kurun Strateji 4. Düşük maliyetli bilişin yüksek seviyeli eğilimi (The high-level trend of low-cost cognition) 1971’de Xerox PARC araştırmacıları, bugün yaşadığımız ağlarla bağlı kişisel bilgisayarlar dünyasını öngörmüştü Bu geleceğin doğmasına, onu mümkün kılan teknolojilerin (Ethernet, grafik işleme, mouse, pencereler vb.) icadında merkezi bir rol oynayarak katkı sundular Ayrıca basit bir alıştırma da yaptılar Çok faydalı olan (ör. video ekranı) ama henüz ekonomik olmayan uygulamalara baktılar (bir video ekranını çalıştıracak kadar RAM binlerce dolardı) Ardından ilgili teknolojinin tarihsel fiyat eğilimlerini (Moore yasasına benzer şekilde) inceleyip bu teknolojinin ne zaman ekonomik hale geleceğini tahmin ettiler Aynı şeyi LLM teknolojisi için de yapabiliriz. Dolar başına transistör sayısı kadar düzenli olmasa da Uzun süredir kullanılan popüler bir benchmark (ör. Massively-Multitask Language Understanding veri seti) ve tutarlı bir girdi yaklaşımı (5-shot prompting) seçin Sonra zaman içinde, bu benchmark üzerinde farklı performans seviyelerine sahip dil modellerini çalıştırmanın maliyetini karşılaştırın Sabit maliyet karşılığında yetenek hızla artıyor. Sabit bir yetenek seviyesi içinse maliyet hızla düşüyor OpenAI’nin davinci modeli API olarak sunulduğundan bu yana geçen 4 yılda, 1 milyon token (bu belgenin yaklaşık 100 kopyası) ölçeğinde o göreve denk performansa sahip bir modeli çalıştırmanın maliyeti 20 dolardan 10 centin altına düştü. Yarılanma süresi yalnızca 6 ay Benzer şekilde, Mayıs 2024 itibarıyla Meta’nın LLaMA 3 8B modelini API sağlayıcıları üzerinden ya da kendi başınıza çalıştırmanın maliyeti 1 milyon token başına sadece 20 cent ve ChatGPT’yi mümkün kılan model olan OpenAI’nin text-davinci-003 modeliyle benzer performans gösteriyor Aynı model, Kasım 2023 sonunda yayımlandığında bile 1 milyon token başına yaklaşık 20 dolara mal oluyordu. Sadece 18 ayda iki basamaklı fark oluştu. Bu, Moore yasasının öngördüğü basit iki kat artışla aynı zaman aralığı Şimdi çok faydalı ama (Park et al’daki gibi üretken video oyunu karakterlerini çalıştırmak) henüz ekonomik olmayan (saatlik maliyetin 625 dolar olduğu tahmin ediliyor) LLM uygulamalarını düşünelim İlgili makalenin Ağustos 2023’te yayımlanmasından bu yana maliyet yaklaşık bir basamak düşerek saat başına 62,50 dolara indi 9 ay sonra bunun saat başına 6,25 dolara düşmesini bekleyebiliriz Bu arada, Pac-Man 1980’de çıktığında, bugünün 1 dolarıyla birkaç dakika ya da birkaç on dakika oynayacak kredi satın alınabiliyordu. Buna saat başına 6 oyun ya da saat başına 6 dolar diyelim Bu kabataslak hesap, ilgi çekici LLM destekli oyun deneyimlerinin 2025 civarında ekonomik hale geleceğini gösteriyor Bu eğilimler yeni ve yalnızca birkaç yıllık. Ancak önümüzdeki birkaç yılda bu sürecin yavaşlamasını beklemek için pek neden yok Parametre başına yaklaşık 20 tokenlık “Chinchilla oranı”nın ötesine ölçekleme gibi algoritma ve veri seti tarafındaki kolay kazanımlar tükense bile, veri merkezlerinin içinde ve silikon katmanında daha derin yenilikler ve yatırımlar bu boşluğu dolduracaktır Ve bu muhtemelen en önemli stratejik gerçek Bugün tamamen uygulanamaz görünen bir fuar demosu ya da araştırma makalesi, birkaç yıl sonra premium bir özellik olacak ve kısa süre sonra da metalaşacak Sistemleri ve organizasyonları bunu akılda tutarak kurmalısınız [0’dan 1’e giden demo artık yeterli. Şimdi 1’den N’e giden ürünü yapma zamanı] LLM demosu yapmak gerçekten çok eğlenceli Birkaç satır kod, bir vektör veritabanı ve özenle yazılmış prompt’larla “sihir” yaratıyorsunuz Geçtiğimiz 1 yıl boyunca bu sihir internetle, akıllı telefonlarla, hatta matbaayla karşılaştırıldı Ne yazık ki, gerçek yazılımı piyasaya sürme işi yapmış herkesin bildiği gibi, kontrollü bir ortamda çalışan bir demo ile büyük ölçekte güvenilir biçimde çalışan bir ürün arasında devasa bir fark var Hayal etmesi ve demosunu yapması kolay ama ürüne dönüştürmesi çok zor olan pek çok problem var Örneğin otonom sürüş: Bir arabanın bir blok boyunca otonom gitmesini göstermek kolaydır, ama bunu ürüne dönüştürmek 10 yıl sürer - Andrej Karpathy Otonom araçları örnek alalım 1988’de sinir ağlarıyla sürülen ilk otomobil ortaya çıktı 25 yıl sonra Andrej Karpathy, Waymo’da ilk demo sürüşünü yaptı Ondan 10 yıl sonra şirket sürücüsüz kullanım izni aldı Prototipten ticari ürüne geçişte 35 yıl boyunca sıkı mühendislik, test, iyileştirme ve regülasyon süreçlerinde yol alma gerekti Son 1 yıldaki iniş çıkışları, sektör ve akademi genelinde gözlemledik: LLM uygulamaları için N yılın 1. yılı (Year 1 of N for LLM applications) Değerlendirme, prompt engineering, guardrail’ler gibi taktiklerden; operasyonel beceriler, ekip kurma ve hangi yeteneklerin şirket içinde geliştirileceğini seçme gibi stratejik bakış açılarına kadar, öğrendiğimiz derslerin 2. yılda ve sonrasında faydalı olmasını umuyoruz Bu heyecan verici yeni teknolojiyi birlikte ilerletmeyi dört gözle bekliyoruz

(eugeneyan.com)

75 puan yazan xguru 2024-06-10 | 9 yorum | WhatsApp'ta paylaş

Büyük dil modelleri (LLM) kullanarak geliştirme yapmak için heyecan verici bir dönemdeyiz
- Son 1 yılda LLM'ler gerçek uygulamalarda "yeterince iyi" düzeye geldi ve her yıl daha iyi ve daha ucuz hale geliyor
- Sosyal medyadaki demolarla birlikte, 2025'e kadar yapay zekaya yaklaşık 200 milyar dolar yatırım yapılacağı tahmin ediliyor
- Sağlayıcıların API'leri sayesinde LLM'lere erişim kolaylaştı; böylece yalnızca ML mühendisleri ve bilim insanları değil, herkes ürünlerine zekâ katmanı inşa edebilir hale geldi
Yapay zekâ ile bir şeyler inşa etmenin giriş bariyeri düştü, ancak demo seviyesinin ötesinde etkili ürünler ve sistemler yapmak hâlâ zor
Biz de son 1 yıldır ürün geliştiriyoruz ve bu süreçte birçok zorluk keşfettik
- Kendi hatalarımızdan kaçınmanıza ve daha hızlı iterasyon yapmanıza yardımcı olmak için öğrendiklerimizi paylaşmak istiyoruz
Bu yazı üç bölümden oluşuyor:
1. Tactical (Taktiksel): prompt yazımı, RAG, workflow engineering, değerlendirme ve izleme için bazı pratikler
  - LLM'lerle ürün geliştiren uygulayıcılar veya hafta sonu projeleri yapanlar için yazıldı
2. Operational (Operasyonel): ürün lansmanının organizasyonel ve günlük meseleleri ile etkili ekip kurma yöntemleri
  - Sürdürülebilir ve güvenilir biçimde dağıtım yapmak isteyen ürün/teknoloji liderlerine yönelik
3. Strategic (Stratejik): "PMF öncesi GPU yok", "modele değil sisteme odaklan" gibi görüşleri içeren uzun vadeli, büyük resim perspektifi ve iterasyon yaklaşımı
  - Kurucular ve yöneticiler düşünülerek yazıldı
Bu rehber, LLM kullanarak başarılı ürünler geliştirmek için pratik bir kılavuz olmayı amaçlıyor
- Kendi deneyimlerimizden doğdu ve sektör genelinden örnekler sunuyor

[Taktik: LLM kullanımının özü]

Bu bölümde, yeni ortaya çıkan LLM yığınının temel bileşenlerine ilişkin en iyi uygulamaları paylaşıyoruz
- Kalite ve güvenilirliği artırmaya yönelik prompt ipuçları, çıktıları değerlendirme stratejileri ve grounding'i iyileştirmek için retrieval-augmented generation fikirleri buna dahil
- Ayrıca human-in-the-loop workflow'larının nasıl tasarlanacağını da ele alacağız

Taktik 1. Prompt yazımı

Yeni bir uygulama geliştirirken prompt ile başlamanızı öneriyoruz
- Prompting'in önemini küçümsemek de abartmak da kolaydır
- Doğru prompting teknikleri düzgün kullanıldığında çok ileri gidilebildiği için genellikle küçümsenir
- Öte yandan, prompt tabanlı uygulamaların da düzgün çalışması için prompt'un etrafında ciddi mühendislik gerektiğinden, bazen gereğinden fazla önem atfedilir

Temel prompting tekniklerinden en yüksek verimi almaya odaklanın

Farklı modeller ve görevlerde performans artışına sürekli yardımcı olan bazı prompting teknikleri vardır
- Bunlar arasında N-shot prompt + in-context learning, Chain-of-Thought ve ilgili kaynakların sağlanması yer alır
N-shot prompt ve in-context learning
- N-shot prompt ile in-context learning'in temel fikri, LLM'e görevi birkaç örnekle göstermek ve çıktıyı beklentilere hizalamaktır
- N çok düşük olursa model bu belirli örneklere aşırı sabitlenebilir ve genelleme yeteneği düşebilir
- Deneyimsel olarak N ≥ 5 hedefleyin ve gerekirse onlarca örnek kullanmaktan çekinmeyin
- Örnekler, beklenen girdi dağılımını temsil etmelidir
- Tüm girdi-çıktı çiftlerini vermeniz gerekmez; birçok durumda istenen çıktının örnekleri yeterlidir
- Araç kullanımını destekleyen bir LLM kullanıyorsanız, N-shot örneklerde de ajanın kullanmasını istediğiniz araçları kullanın
Chain-of-Thought (CoT) prompting
- CoT prompting'de LLM, nihai cevabı vermeden önce düşünce sürecini açıklamaya teşvik edilir
- Bunu, LLM'in her şeyi bellekte yapmak zorunda kalmaması için ona bir taslak alanı sağlamak gibi düşünebilirsiniz
- İlk yaklaşım, yönergelerin bir parçası olarak basitçe "adım adım düşünelim" ifadesini eklemekti; ancak CoT'yi daha spesifik hale getirmenin faydalı olduğunu gördük
- 1-2 cümlelik ek özgüllük, çoğu zaman halüsinasyon oranını anlamlı biçimde azaltır
- Son dönemde bu tekniğin sanıldığı kadar güçlü olup olmadığı da sorgulanıyor
- Ayrıca CoT kullanıldığında muhakeme sırasında tam olarak ne olduğuna dair ciddi bir tartışma var
- Buna rağmen, mümkün olduğunda denenmeye değer bir tekniktir
İlgili kaynakları sağlama
- İlgili kaynaklar sağlamak, modelin bilgi tabanını genişleten, halüsinasyonu azaltan ve kullanıcı güvenini artıran güçlü bir mekanizmadır
- Bu çoğu zaman retrieval-augmented generation (RAG) ile yapılır
- Modele, yanıtında doğrudan kullanabileceği metin parçaları vermek temel bir tekniktir
- İlgili kaynaklar sağlarken bunları yalnızca eklemek yeterli değildir
  - Modele, kaynak kullanımına öncelik vermesini, bunlara doğrudan atıfta bulunmasını ve bazen kaynakların yetersiz kaldığını belirtmesini söylemeyi unutmayın
- Bunlar, ajan yanıtlarını kaynak korpusuna "ground" etmeye yardımcı olur

Girdi ve çıktıyı yapılandırın

Yapılandırılmış girdiler ve çıktılar, modelin girdiyi daha iyi anlamasına ve alt sistemlerle güvenilir biçimde entegre olabilecek çıktılar döndürmesine yardımcı olur
- Girdiye bir serileştirme biçimi eklemek, bağlamdaki token'lar arası ilişkileri, belirli token'lara dair ek metaveriyi (ör. tür) veya isteği modelin eğitim verisindeki benzer örneklerle ilişkilendirmeyi kolaylaştırabilir
- Örneğin internette SQL yazımıyla ilgili birçok soru, SQL şemasını belirterek başlar
  - Bu nedenle Text-to-SQL için etkili prompting, yapılandırılmış şema tanımlarını içermelidir
Yapılandırılmış çıktı benzer bir amaca hizmet eder, ancak sistemin alt bileşenleriyle entegrasyonu basitleştirir
- Instructor ve Outlines, yapılandırılmış çıktı için iyi çalışır
  - (Bir LLM API SDK'sı kullanıyorsanız Instructor'ı, kendi host ettiğiniz modellerde Huggingface kullanıyorsanız Outlines'ı tercih edin)
- Yapılandırılmış girdiler, görevi açık biçimde ifade ettiğinden ve eğitim verisinin formatına benzediğinden daha iyi çıktı alma olasılığını artırır
Yapılandırılmış girdi kullanırken, her LLM ailesinin tercih ettiği bir yaklaşım olduğunu unutmamak gerekir
- Claude, <xml> tercih ederken GPT, Markdown ve JSON'u tercih eder
- XML kullanırsanız, Claude'un yanıtını önceden doldurmak için <response> etiketi de verebilirsiniz

Küçük ve tek işi iyi yapan prompt'lar oluşturun

Yazılımda yaygın bir anti-pattern/kod kokusu, her şeyi yapan tek bir sınıf ya da fonksiyon olan "God Object"tir
- Aynısı prompt'lar için de geçerlidir
Prompt'lar genellikle basit başlar
- Birkaç cümlelik talimat ve birkaç örnekle başlayabilirsiniz
- Ancak performansı artırmaya ve daha fazla edge case işlemeye çalıştıkça karmaşıklık büyür
  - Daha fazla talimat, çok adımlı akıl yürütme, onlarca örnek vb. eklenir
- Sonunda başlangıçta basit olan prompt, 2.000 token'lık bir Frankenstein'a dönüşür
  - Üstelik daha genel ve sezgisel girdilerdeki performans bile kötüleşebilir
  - GoDaddy bunu, LLM ile ürün geliştirirken çıkardığı dersler arasında 1 numaraya koyuyor
Sistemleri ve kodu basit tutmaya çalıştığınız gibi prompt'lar da öyle olmalıdır
- Toplantı dökümü özetleyicisi için tek ve her şeyi yapan bir prompt kullanmak yerine, bunu şu adımlara bölebilirsiniz
  - Ana kararları, aksiyon maddelerini ve sorumlu kişileri yapılandırılmış biçimde çıkarma
  - Çıkarılan ayrıntıları özgün dökümle karşılaştırarak tutarlılık kontrolü yapma
  - Yapılandırılmış ayrıntılardan kısa bir özet üretme
Sonuç olarak tek bir prompt'u, birden çok basit, odaklı ve anlaşılır prompt'a bölmüş olursunuz
- Bu şekilde artık her prompt üzerinde ayrı ayrı iterasyon yapabilir ve değerlendirme gerçekleştirebilirsiniz

Bağlam token'ları oluşturma

Ajana gerçekten gönderilmesi gereken bağlam miktarına dair varsayımlar yeniden düşünülmeli ve sorgulanmalı
- Michelangelo gibi bir bağlam heykeli inşa etmek yerine, gereksiz malzemeyi yontup heykeli ortaya çıkarmak gerekir
- RAG, potansiyel olarak ilgili tüm mermer bloklarını toplamak için yaygın olarak kullanılan bir yöntemdir; peki gereken şeyi çıkarmak için ne yapıyorsunuz?
Modele gönderilen nihai prompt'u alıp tüm bağlam bileşimi, meta prompting ve RAG sonuçlarıyla birlikte boş bir sayfaya yerleştirip okumanın, bağlamı yeniden düşünmeye yardımcı olduğu görülmüştür
- Bu yöntemle tekrarlar, kendi içinde çelişen ifadeler ve kötü biçimlendirilmiş kısımlar tespit edilebilir
Bir diğer temel optimizasyon da bağlamın yapısıdır
- Bag-of-docs temsili insanlara yardımcı olmaz; bu yüzden ajan için de iyi olduğunu varsaymamalısınız
- Bağlamın her parçası arasındaki ilişkiyi vurgulayan ve çıkarımı mümkün olduğunca basit hale getiren bir bağlam yapısının nasıl kurulacağını dikkatle düşünmek gerekir

Taktik 2. Bilgi erişimi / RAG

Prompting'in yanı sıra, bir LLM'i yönlendirmenin etkili bir diğer yolu da prompt'un bir parçası olarak bilgi sağlamaktır
- Bu, LLM'i sağlanan bağlama ground eder ve bu da bağlam içi öğrenmede kullanılır
- Buna Retrieval-Augmented Generation (RAG) denir
- Uygulayıcılar, RAG'nin bilgi sağlama ve çıktıyı iyileştirme konusunda etkili olduğunu, ayrıca fine-tuning'e kıyasla çok daha az emek ve maliyet gerektirdiğini görmüştür
- RAG ancak getirilen belgelerin ilgililiği, bilgi yoğunluğu ve ayrıntı seviyesi kadar iyidir

RAG çıktısının kalitesi, getirilen belgelerin kalitesine bağlıdır ve değerlendirilebilecek birkaç unsur vardır

İlk ve en açık ölçüt "ilgililik"tir
- Bu genellikle Mean Reciprocal Rank (MRR) veya Normalized Discounted Cumulative Gain (NDCG) gibi sıralama metrikleriyle nicelleştirilir
- MRR, sistemin sıralı listede ilk ilgili sonucu ne kadar iyi konumlandırdığını değerlendirirken, NDCG tüm sonuçların ilgililiğini ve konumunu dikkate alır
- Bunlar, ilgili belgeleri daha yukarıya ve ilgisiz belgeleri daha aşağıya sıralayan sistemlerin performansını ölçer
- Örneğin film incelemelerinin özetini üretmek için kullanıcı özetleri getiriliyorsa, belirli bir filme ait incelemeleri daha yukarıda sıralamak ve diğer filmlere ait incelemeleri dışarıda bırakmak istenir
- Geleneksel öneri sistemlerinde olduğu gibi, getirilen öğelerin sıralaması LLM'in aşağı akış görevini nasıl yerine getirdiğini önemli ölçüde etkiler
- Etkiyi ölçmek için getirilen öğeleri karıştırılmış haldeyken RAG tabanlı görevi çalıştırın ve RAG çıktısının nasıl performans gösterdiğine bakın
İkinci unsur "bilgi yoğunluğu"dur
- İki belge eşit derecede ilgiliyse, daha kısa ve daha az ilgisiz ayrıntı içeren belge tercih edilmelidir
- Film örneğine dönersek, film senaryosu ile tüm kullanıcı incelemeleri geniş anlamda ilgili sayılabilir
- Buna rağmen yüksek puanlı incelemeler ve editoryal incelemeler muhtemelen daha yüksek bilgi yoğunluğuna sahiptir
Son olarak, belgede sunulan "ayrıntı düzeyi" dikkate alınmalıdır
- Doğal dilden SQL sorguları üretmek için bir RAG sistemi kurduğunuzu hayal edin
  - Sütun adlarını içeren tablo şemasını bağlam olarak vermek tek başına yeterli olabilir
  - Peki ya sütun açıklamaları ve bazı temsili değerler de eklenirse?
- Ek ayrıntılar, LLM'in tablonun anlamını daha iyi kavramasına ve daha doğru SQL üretmesine yardımcı olabilir

Anahtar kelime aramayı unutmayın; bunu baseline ve hibrit arama için kullanın

Embedding tabanlı RAG demoları yaygınlaştığı için, bilgi erişimi alanındaki onlarca yıllık araştırma ve çözümleri unutmak ya da göz ardı etmek kolaydır
- Yine de embedding'ler kuşkusuz güçlü araçlardır, ancak her derde deva değildir
Anahtar kelime tabanlı aramanın avantajları
- Birincisi, embedding'ler yüksek düzeyde anlamsal benzerliği yakalamada mükemmeldir; ancak kullanıcı bir ad (ör. Ilya), bir kısaltma (ör. RAG) veya bir kimlik (ör. claude-3-sonnet) aradığında olduğu gibi daha spesifik ve anahtar kelime tabanlı sorgularda zorlanabilir
  - BM25 gibi anahtar kelime tabanlı arama sistemleri bunun için açıkça tasarlanmıştır
  - Kullanıcılar anahtar kelime tabanlı aramayı uzun zamandır kullandığı için bunu doğal karşılar; aradıkları belge dönmezse hayal kırıklığı yaşayabilirler
- İkincisi, bir belgenin neden getirildiğini anlamak anahtar kelime aramada daha sezgiseldir
  - Çünkü sorguyla eşleşen anahtar kelimeler görülebilir
  - Buna karşılık embedding tabanlı arama daha az yorumlanabilirdir
- Üçüncüsü, Lucene veya OpenSearch gibi onlarca yıl boyunca optimize edilmiş ve sahada kanıtlanmış sistemler sayesinde anahtar kelime arama genellikle hesaplama açısından daha verimlidir
Çoğu durumda hibrit yaklaşım en etkilisidir
- Bariz eşleşmeler için anahtar kelime eşleştirme, eş anlamlılar, üst kavramlar, yazım hataları ve multimodal durumlar (ör. görsel ve metin) için embedding kullanın
- Shortwave, sorgu yeniden yazımı, anahtar kelime + embedding araması, sıralama vb. dahil olmak üzere kendi RAG pipeline'larını nasıl kurduklarını paylaştı

Yeni bilgi için fine-tuning yerine RAG'yi tercih edin

Hem RAG hem de fine-tuning, yeni bilgiyi LLM'e entegre etmek ve belirli görevlerde performansı artırmak için kullanılabilir
- Peki önce hangisini denemek gerekir?
RAG'nin avantajları
- Son araştırmalara göre RAG daha üstün olabilir
- Bir çalışmada RAG ile gözetimsiz fine-tuning (sürekli ön eğitim olarak da bilinir), MMLU ve güncel olaylara dair alt kümeler üzerinde değerlendirilerek karşılaştırılmıştır
  - RAG, hem eğitim sırasında karşılaşılan bilgi hem de tamamen yeni bilgi için fine-tuning'den sürekli olarak daha iyi performans göstermiştir
- Başka bir makalede tarım veri kümesi üzerinde RAG ile gözetimli fine-tuning karşılaştırılmıştır
  - Benzer şekilde, RAG'nin performans artışı fine-tuning'den daha büyük olmuştur; bu fark özellikle GPT-4'te belirgindir (makaledeki tablo 20'ye bakın)
- Performans artışının yanı sıra, RAG'nin çeşitli pratik avantajları da vardır
  - Birincisi, sürekli ön eğitim veya fine-tuning'e kıyasla arama indeksini güncel tutmak daha kolay ve daha ucuzdur
  - İkincisi, arama indeksinde zararlı ya da önyargılı içerik barındıran sorunlu belgeler varsa, bu belgeler kolayca silinebilir veya düzeltilebilir
- Ayrıca RAG'deki R, belgelerin nasıl getirileceği konusunda daha ayrıntılı kontrol sağlar
  - Örneğin birden fazla kuruluş için RAG sistemi barındırıyorsanız, her kuruluşun yalnızca kendi indeksindeki belgeleri getirebilmesi için arama indeksini bölümlere ayırabilirsiniz
  - Bu da bir kuruluşun bilgilerinin yanlışlıkla başka bir kuruluşa ifşa edilmesini önlemeye yardımcı olur

Uzun bağlamlı modeller RAG'yi işe yaramaz hale getirmeyecek

Gemini 1.5’in 10 milyon tokene kadar bağlam penceresi sunmasıyla birlikte bazıları RAG’in geleceğini sorgulamaya başladı
- 10 milyon tokenlik bir bağlam penceresi, mevcut RAG çerçevelerinin çoğunu gereksiz hale getiriyor
  - Veriyi bağlama koyup her zamanki gibi modelle konuşmanız yeterli
- Mühendislik çabasının büyük kısmını RAG’e yatıran startup’lar, ajanlar ve langchain projeleri için bunun ne anlama geleceğini düşünün
  - Tek cümlelik özet: 10 milyonluk bağlam RAG’i öldürür
RAG’in kalıcı gerekliliği
- Uzun bağlamın, çoklu belge analizi veya PDF’lerle sohbet gibi kullanım senaryolarında oyun değiştirici olacağı doğru olsa da, RAG’in sonuna dair söylentiler büyük ölçüde abartılı
  - Birincisi, 10 milyon tokenlik bir bağlam penceresi olsa bile modele hangi bilginin verileceğini seçmenin bir yoluna hâlâ ihtiyaç var
  - İkincisi, dar kapsamlı needle-in-a-haystack değerlendirmelerinin ötesinde, modelin bu kadar büyük bir bağlam üzerinde etkili biçimde akıl yürütebildiğini gösteren ikna edici veriler henüz görmedim
  - Bu nedenle, iyi bir retrieval (ve sıralama) olmadan modeli dikkat dağıtan bilgilerle boğma, hatta bağlam penceresini tamamen alakasız bilgilerle doldurma riski vardır
Son olarak maliyet sorunu var
- Transformer çıkarım maliyeti, bağlam uzunluğuna göre karesel olarak artar (veya hem alan hem zaman açısından doğrusal)
- Bir modelin bir kuruluşun tüm Google Drive içeriğini okuyabiliyor olması, her soruyu yanıtlamadan önce bunu yapmasının iyi bir fikir olduğu anlamına gelmez
- RAM kullanım biçimine dair şu benzetmeyi düşünün
  - Onlarca terabayt RAM’e sahip hesaplama örnekleri mevcut, ama buna rağmen hâlâ diskten okuma ve diske yazma yapıyoruz
Bu yüzden RAG’i henüz çöpe atmayın
- Bu örüntü, bağlam pencereleri büyüdükçe de faydalı olmaya devam edecek

Taktik 3. İş akışı ayarlama ve optimizasyon

LLM’e prompt vermek sadece başlangıçtır
- LLM’den en yüksek verimi almak için tek bir promptun ötesine geçip iş akışlarını benimsemek gerekir
- Örneğin, karmaşık tek bir görevi birden fazla daha basit göreve nasıl bölebiliriz?
- İnce ayar veya cache ne zaman performansı artırmaya ve gecikme/maliyeti düşürmeye yardımcı olur?
Bu bölümde, LLM iş akışlarını optimize edip kurmanıza yardımcı olmak için kanıtlanmış stratejiler ve gerçek örnekler paylaşılıyor

Adım adım, çok turlu "Flow" büyük performans artışları sağlayabilir

Tek bir büyük promptu birden fazla küçük prompa bölerek daha iyi sonuçlar alınabileceğini zaten biliyoruz
- AlphaCodium bunun bir örneği
  - Tek prompttan çok aşamalı iş akışına geçerek CodeContests’te GPT-4 doğruluğunu (pass@5) %19’dan %44’e çıkardı
- İş akışı şunları içerir
  - Problem üzerine düşünme
  - Açık testler üzerinde akıl yürütme
  - Olası çözümler üretme
  - Olası çözümleri sıralama
  - Sentetik test üretme
  - Çözümleri açık ve sentetik testler üzerinde yineleme
Net hedeflere sahip küçük görevler, en iyi ajan veya akış promptlarını oluşturur
- Her ajan promptunun yapılandırılmış çıktı istemesi gerekmez, ancak yapılandırılmış çıktı, ajanın çevresiyle etkileşimini yöneten sistemle arayüz açısından çok faydalıdır
Denemeye değer şeyler
- Mümkün olduğunca sıkı tanımlanmış, açık planlama adımları
  - Önceden tanımlanmış planlar arasından seçim yapmayı düşünün
- Orijinal kullanıcı promptunu ajan promptu olarak yeniden yazmak
  - Bu süreçte bilgi kaybı yaşanabileceği için dikkatli olun
- Doğrusal zincirler, DAG’ler ve durum makineleri olarak ajan davranışı
  - Farklı bağımlılıklar ve mantıksal ilişkiler, farklı ölçekler için daha uygun ya da daha az uygun olabilir
  - Farklı görev mimarilerinde performans optimizasyonu sağlayabilir miyiz?
- Plan doğrulama
  - Plan, nihai çıktının iyi çalışmasını sağlamak için diğer ajanların yanıtlarının nasıl değerlendirileceğine dair talimatlar içerebilir
- Sabit upstream durumla prompt mühendisliği
  - Ajan promptunun daha önce ortaya çıkabilecek farklı varyasyonlara karşı değerlendirildiğinden emin olun

Şimdilik deterministik iş akışlarına öncelik verin

Yapay zeka ajanları, kullanıcı isteklerine ve çevreye dinamik biçimde tepki verebilir, ancak deterministik olmayan yapıları dağıtımı zorlaştırır
- Ajanın yürüttüğü her adımın başarısız olma ihtimali vardır ve hatadan kurtulma olasılığı düşüktür
- Bu nedenle bir ajanın çok adımlı bir görevi başarıyla tamamlama olasılığı, adım sayısı arttıkça geometrik olarak azalır
- Sonuç olarak ajan geliştiren ekipler, güvenilir ajanları üretime almada zorlanır
Umut vadeden bir yaklaşım, deterministik bir plan üreten ve bunu yapılandırılmış, tekrar üretilebilir bir biçimde yürüten bir ajan sistemine sahip olmaktır
- İlk aşamada, üst düzey bir hedef veya prompt verildiğinde ajan bir plan üretir
- Ardından plan deterministik olarak yürütülür
- Bu, her adımı daha öngörülebilir ve güvenilir hale getirebilir
- Avantajlar
  - Üretilen planlar, ajanı promptlamak veya ince ayar yapmak için few-shot örnekleri olarak kullanılabilir
  - Deterministik yürütme sistemi daha güvenilir kılar; test ve debug daha kolay olur. Ayrıca başarısızlıklar planın belirli bir adımına kadar izlenebilir
  - Üretilen planlar yönlü çevrimsiz grafikler (DAG) olarak ifade edilebilir ve statik promptlara kıyasla anlaşılması ve yeni durumlara uyarlanması daha kolaydır
En başarılı ajan geliştiricileri, muhtemelen junior mühendisleri yönetme konusunda güçlü deneyime sahip kişiler olabilir
- Çünkü plan üretim süreci, junior birini yönlendirme ve yönetme biçimine benzer
- Junior’lara belirsiz ve açık uçlu yönlendirmeler yerine net hedefler ve somut planlar verdiğiniz gibi, ajanlara da aynısını yapmalısınız
Sonuçta güvenilir ve gerçekten çalışan ajanların anahtarı muhtemelen şurada yatıyor
- Daha yapılandırılmış ve deterministik bir yaklaşım benimsemekte,
- ve promptları iyileştirmekle modeli ince ayar yapmak için veri toplamaktadır
Bunlar olmadan, bazen çok iyi çalışan ama ortalamada kullanıcıyı hayal kırıklığına uğratan ve elde tutmayı düşüren ajanlar inşa edersiniz

Sıcaklık parametresinin ötesinde çeşitli çıktılar elde etmek

LLM çıktısında çeşitliliğe ihtiyaç duyan görevler olduğunu varsayalım
- Kullanıcının daha önce satın aldığı ürünler listesini dikkate alarak katalogdan satın alınabilecek ürünler öneren bir LLM pipeline’ı yazıyor olabilirsiniz
- Promptu birden çok kez çalıştırdığınızda öneri sonuçlarının birbirine fazla benzediğini fark edebilirsiniz
- Bu nedenle LLM isteğinin Temperature (sıcaklık) parametresini artırabilirsiniz
Sıcaklık parametresini yükseltmek, LLM yanıtlarını daha çeşitli hale getirir
- Örnekleme sırasında bir sonraki tokenın olasılık dağılımı daha düzleşir ve normalde seçilme ihtimali düşük tokenlar daha sık seçilir
Ancak sıcaklığı artırdığınızda çıktı çeşitliliğiyle ilgili bazı başarısızlık modları ortaya çıkabilir
- Örneğin katalogdaki bazı ürünler uygun olabilir ama LLM tarafından çıktıda yer almayabilir
- LLM, eğitim sırasında öğrendiklerine dayanarak promptu takip etmeye daha yatkınsa, aynı az sayıdaki ürün çıktıda aşırı temsil edilebilir
- Sıcaklık çok yükselirse var olmayan ürünlere (veya anlamsız içeriklere) atıf yapan çıktılar üretilebilir
Sıcaklığı artırmak, LLM’nin beklediğiniz olasılık dağılımından (ör. eşit rastgele) çıktı örnekleyeceğini garanti etmez
Buna rağmen çıktı çeşitliliğini artırmak için başka hileler de vardır
- En basit yöntem, prompt içindeki öğeleri ayarlamaktır
  - Örneğin prompt şablonu geçmiş satın alımlar gibi bir öğe listesi içeriyorsa, bu öğeleri prompa her ekleyişinizde sıralarını karıştırmak önemli fark yaratabilir
- Ayrıca son çıktılardan oluşan kısa bir liste tutmak da tekrarları önlemeye yardımcı olur
  - Ürün önerisi örneğinde, LLM’ye bu son listedeki öğeleri önermemesi talimatını verebilir veya son önerilere benzeyen çıktıları reddedip yeniden örnekleme yaparak yanıtları daha da çeşitlendirebilirsiniz
- Bir diğer etkili strateji, promptta kullanılan ifadeleri çeşitlendirmektir
  - Örneğin "kullanıcının düzenli olarak kullanmayı seveceği öğeleri seç" ya da "kullanıcının arkadaşına tavsiye etme olasılığı yüksek ürünleri seç" gibi ifadeleri dahil etmek, odağı kaydırarak önerilen ürünlerin çeşitliliğini etkileyebilir

Cache kullanımı hak ettiği değeri görmüyor

Önbellekleme, aynı girdi için yanıtı yeniden hesaplama gereğini ortadan kaldırarak maliyeti düşürür ve üretim gecikmesini kaldırır
- Ayrıca yanıt daha önce guardrail kontrollerinden geçtiyse, bu doğrulanmış yanıtları sunarak zararlı veya uygunsuz içerik verme riskini azaltabilir
Önbellekleme için basit bir yaklaşım, yeni bir makaleyi ya da ürün incelemesini özetleme durumunda olduğu gibi, işlenen öğe için benzersiz bir kimlik kullanmaktır
- Bir istek geldiğinde, özeti önbellekte zaten var mı diye kontrol edebilirsiniz
  - Varsa hemen döndürülebilir; yoksa oluşturulur, guardrail kontrolünden geçirilir ve sunulduktan sonra gelecekteki istekler için önbelleğe kaydedilir
Daha açık uçlu sorgular için, arama alanındaki tekniklerden yararlanarak açık uçlu girdilerde de önbellekleme kullanılabilir
- Otomatik tamamlama ve yazım düzeltme gibi özellikler, kullanıcı girdisini normalize ederek önbellek isabet oranını artırmaya yardımcı olur

finetune (ince ayar) ne zaman gerekir

En akıllıca tasarlanmış prompt'ların bile yetersiz kaldığı bazı görevler olabilir
- Örneğin, kayda değer prompt mühendisliğinden sonra bile sistem hâlâ güvenilir ve yüksek kaliteli çıktı üretmekten uzak kalabilir
- Bu durumda modeli belirli bir görev için ince ayar yapmak gerekebilir
Başarılı ince ayar örnekleri
- Honeycomb'un Natural Language Query Assistant'ı
  - Başlangıçta "programlama kılavuzu", bağlam içi öğrenme için n-shot örnekleriyle birlikte prompt içinde verildi
  - Bu işe yarasa da, model ince ayarlandığında alan özelindeki dilin sözdizimi ve kuralları konusunda daha iyi çıktılar alınabilir
- Rechat'in Lucy'si
  - LLM'in, frontend'in doğru şekilde render edebilmesi için yapılandırılmış ve yapılandırılmamış verileri birleştiren çok belirli bir biçimde yanıt üretmesi gerekir
  - Bunun tutarlı şekilde çalışması için ince ayar kritik önemdedir
İnce ayar etkili olabilir, ancak önemli bir maliyeti vardır
- İnce ayar verisini etiketlemeniz, modeli ince ayarlayıp değerlendirmeniz ve sonunda kendi başınıza barındırmanız gerekir
- Bu nedenle, daha yüksek başlangıç maliyetinin buna değip değmeyeceğini değerlendirmek gerekir
Prompting ile %90 seviyesine ulaşabiliyorsanız, ince ayara yatırım yapmak anlamlı olmayabilir
- Ancak ince ayar yapmaya karar verirseniz, insanlar tarafından etiketlenmiş veri toplama maliyetini azaltmak için sentetik veri üzerinde üretim ve ince ayar yapabilir ya da açık kaynak verilerle başlangıç seti oluşturabilirsiniz

Taktik 4. Değerlendirme ve izleme

LLM değerlendirmesi bir mayın tarlası olabilir
- LLM'in girdileri ve çıktıları serbest biçimli metindir ve tanımladığınız görevler de çeşitlidir
- Buna rağmen, sıkı ve dikkatli değerlendirme kritik önemdedir
  - OpenAI'nin teknik liderlerinin değerlendirmelere katılması ve tek tek değerlendirmeler için geri bildirim vermesi tesadüf değildir
LLM uygulamalarını değerlendirmek çeşitli tanımlar ve indirgemeler gerektirir
- Bu, basitçe unit test olabilir, daha çok gözlemlenebilirliğe benzeyebilir ya da sadece veri bilimi olabilir
- Biz bu bakış açılarının hepsinin faydalı olduğunu gördük
Bu bölümde, değerlendirme ve izleme hattını kurarken önemli olan noktalara dair öğrendiğimiz dersleri paylaşıyoruz

Gerçek girdi/çıktı örneklerinden assertion tabanlı birkaç unit test oluşturun

Prodüksiyondaki girdi ve çıktı örneklerinden oluşan unit testler (yani assertion'lar) oluşturun ve en az 3 farklı ölçüte göre çıktıya dair beklentiler belirleyin
- 3 ölçüt keyfi görünebilir, ancak başlamak için pratik bir sayıdır
  - Daha azı, görevin yeterince iyi tanımlanmadığı ya da genel amaçlı bir chatbot örneğinde olduğu gibi fazla açık uçlu olduğu anlamına gelebilir
- Bu unit testler veya assertion'lar, prompt düzenleme, RAG ile yeni bağlam ekleme ya da diğer değişiklikler gibi pipeline üzerindeki güncellemelerle tetiklenmelidir
Her yanıtta bulunması ya da bulunmaması gereken ifade ve fikirleri belirleyen assertion'larla başlamayı düşünün
- Ayrıca kelime, öğe veya cümle sayısının belirli bir aralıkta olup olmadığını kontrol eden testler de düşünülebilir
- Farklı üretim türleri için assertion'lar da farklı görünebilir
  - Örneğin kod üretimini değerlendirmek için güçlü bir yöntem olan yürütme değerlendirmesinde, üretilen kod çalıştırılır ve çalışma zamanı durumunun kullanıcının isteğini yeterince karşılayıp karşılamadığı kontrol edilir
Örneğin kullanıcı foo adında yeni bir fonksiyon isterse, ajan tarafından üretilen kod çalıştırıldıktan sonra foo çağrılabilmelidir
Yürütme değerlendirmesindeki zorluklardan biri, ajan kodunun çoğu zaman çalışma zamanını hedef koda göre biraz farklı bir durumda bırakmasıdır
- Assertion'ları, geçerli her yanıtın karşılayabileceği en zayıf varsayımlara göre "gevşetmek" etkili olabilir
Ürünü müşterinin amaçladığı şekilde kendiniz kullanmak (yani "dogfooding"), gerçek verideki hata modları hakkında içgörü sağlayabilir
- Bu yaklaşım yalnızca potansiyel zayıflıkları belirlemeye yardımcı olmakla kalmaz, aynı zamanda değerlendirmeye dönüştürülebilecek faydalı prodüksiyon örnekleri de sağlar

LLM-as-Judge (bir ölçüde) işe yarayabilir, ancak her derde deva değildir

LLM-as-Judge, güçlü bir LLM kullanarak başka bir LLM'in çıktısını değerlendirme yöntemidir ve bazı kişiler buna şüpheyle yaklaşır
Buna rağmen iyi uygulandığında, LLM-as-Judge insan yargısıyla anlamlı bir korelasyon yakalayabilir ve en azından yeni prompt'ların ya da tekniklerin nasıl performans gösterebileceğine dair ön bilgi oluşturmaya yardımcı olabilir
- Özellikle ikili karşılaştırmalarda (ör. kontrol grubu vs deney grubu), LLM-as-Judge genellikle yönü doğru belirler, ancak kazanma/kaybetme farkının büyüklüğü gürültülü olabilir
LLM-as-Judge'dan en iyi şekilde yararlanmak için öneriler
- İkili karşılaştırma kullanın
  - LLM'den tek bir çıktıyı Likert ölçeğinde puanlamasını istemek yerine, iki seçeneği gösterip daha iyi olanı seçmesini isteyin
  - Bu, daha istikrarlı sonuçlara yol açma eğilimindedir
- Konum yanlılığını kontrol edin
  - Sunulan seçeneklerin sırası, LLM'in kararını etkileyebilir
  - Bunu azaltmak için her ikili karşılaştırmayı iki kez çalıştırın ve her seferinde çiftin sırasını değiştirin
  - Sıra değiştirildikten sonra galibiyet doğru seçeneğe yazılmalıdır
- Beraberliğe izin verin
  - Bazı durumlarda iki seçenek de eşit derecede iyi olabilir
  - Bu nedenle LLM'in rastgele bir kazanan seçmek zorunda kalmaması için beraberlik ilan etmesine izin verin
- Chain-of-Thought kullanın
  - Son tercihi vermeden önce LLM'den kararını açıklamasını istemek, değerlendirmenin güvenilirliğini artırabilir
  - Ek bir avantaj olarak bu, daha zayıf ama daha hızlı bir LLM kullanırken bile benzer sonuçlar elde etmeyi sağlayabilir
  - Pipeline'ın bu kısmı çoğu zaman batch modunda çalıştığı için CoT'nin getirdiği ek gecikme sorun olmaz
- Yanıt uzunluğunu kontrol edin
  - LLM'ler daha uzun yanıtlara kayma eğilimindedir
  - Bunu azaltmak için yanıt çiftlerinin uzunluklarının benzer olduğundan emin olun
LLM-as-Judge'ın özellikle güçlü bir kullanım alanı, yeni prompt stratejilerini regresyon açısından kontrol etmektir
- Eğer bir prodüksiyon çıktıları koleksiyonunu takip ettiyseniz, bazen bu prodüksiyon örneklerini yeni prompt stratejisiyle yeniden çalıştırabilir ve LLM-as-Judge kullanarak yeni stratejinin nerelerde zorlanabileceğini hızlıca değerlendirebilirsiniz
LLM-as-Judge için basit ama etkili bir yaklaşım örneği
- LLM yanıtını, hakemin eleştirisini (yani CoT'yi) ve nihai sonucu kaydedin
- Ardından bunları paydaşlarla birlikte gözden geçirerek iyileştirme alanlarını belirleyin
- 3 yineleme sonunda insan ile LLM arasındaki uyum %68'den %94'e çıktı
Ancak LLM-as-Judge her derde deva değildir
- En güçlü modeller bile bazı ince dilsel yönleri güvenilir biçimde değerlendiremez
Ayrıca geleneksel sınıflandırıcıların ve ödül modellerinin, LLM-as-Judge'a kıyasla daha düşük maliyet ve gecikmeyle daha yüksek doğruluk sağlayabildiğini gördük
- Kod üretimi söz konusu olduğunda LLM-as-Judge, yürütme değerlendirmesi gibi daha doğrudan değerlendirme stratejilerine göre daha zayıf kalabilir

Üretim sonuçlarını değerlendirmek için "stajyer testi"

Üretim sonuçlarını değerlendirirken aşağıdaki gibi bir "stajyer testi" kullanmak faydalı olabilir
- Bağlamı da ekleyerek dil modeline verilen tam girdiyi ilgili alanda ortalama bir üniversite öğrencisine görev olarak verseniz, başarılı olabilirler mi?
- Ne kadar sürer?
Yanıt hayırsa
- Bunun nedeni LLM'in ihtiyaç duyduğu bilgiye sahip olmamasıysa, bağlamı zenginleştirmenin yollarını düşünün
- Bağlamı iyileştirmek de sorunu çözmüyorsa, bu görev günümüz LLM'leri için fazla zor olabilir
Yanıt evetse ama zaman alıyorsa
- Görevin karmaşıklığını azaltmayı deneyebilirsiniz
  - Parçalara ayrılabilir mi?
  - Görevin hangi yönleri daha fazla şablonlaştırılabilir?
Yanıt evetse ve hızlıca yapılabiliyorsa
- Veriyi derinlemesine incelerken
  - Model neyi yanlış yapıyor?
  - Başarısızlık örüntüleri bulunabilir mi?
- Modelden yanıt vermeden önce veya sonra kendi kendine açıklama yapmasını istemeyi deneyin

Belirli bir değerlendirmeye aşırı odaklanmak genel performansı düşürebilir

"Bir ölçüm metriği hedef haline geldiğinde artık iyi bir ölçüm metriği olmaktan çıkar." - Goodhart yasası

Buna örnek olarak Needle-in-a-Haystack (NIAH) değerlendirmesi verilebilir
- İlk haliyle bu değerlendirme, bağlam boyutu büyüdükçe modelin hatırlama performansını nicel olarak ölçmeye ve iğnenin konumunun bu hatırlamayı nasıl etkilediğini görmeye yardımcı olur
- Ancak buna gereğinden fazla vurgu yapıldı ve Gemini 1.5 raporunda Figure 1 olarak sunuldu
- Bu değerlendirme, Paul Graham'ın denemelerinin tekrarlandığı uzun bir belgeye belirli bir ifadeyi ("The special magic {city} number is: {number}") ekleyip ardından modele sihirli sayıyı hatırlatmayı istemeyi içerir
Bazı modeller neredeyse kusursuz hatırlama elde etse de, NIAH'ın gerçek uygulamaların gerektirdiği akıl yürütme ve hatırlama becerilerini gerçekten yansıtıp yansıtmadığı sorgulanabilir
Daha pratik senaryoları düşünün
- Elinizde 1 saatlik bir toplantı dökümü varsa, LLM ana kararları ve sonraki adımları özetleyip her maddeyi doğru sorumlu kişiye atfedebilir mi?
- Bu görev yalnızca basit ezberlemeyi değil, karmaşık tartışmaları kavrama, ilgili bilgiyi belirleme ve özeti sentezleme becerisini de içerdiği için daha gerçekçidir
Pratik bir NIAH değerlendirmesi örneği
- Doktor-hasta görüntülü görüşmesi dökümünü kullanarak LLM'e hastanın ilaçları hakkında sorular sormak
- Espressoya batırılmış hurma, limon, keçi peyniri gibi pizza malzemeleri için gereken rastgele içeriklere dair ifadeler eklenmesi gibi daha zorlayıcı NIAH örnekleri de dahil
- İlaç görevinde hatırlama yaklaşık %80, pizza görevinde ise %30 oldu
NIAH değerlendirmesine aşırı vurgu yapmak, çıkarım ve özetleme görevlerindeki performansı düşürebilir
- Çünkü bu tür LLM'ler her cümleye dikkat etmeleri için ince ayarlanır; bu da ilgisiz ayrıntıları ve dikkat dağıtıcı unsurları önemliymiş gibi ele almalarına yol açabilir
- Sonuçta bunlar nihai çıktıya dahil olabilir (dahil edilmemeleri gerekirken bile!)
Bu durum diğer değerlendirmeler ve kullanım senaryoları için de geçerli olabilir
- Örneğin özetleme
  - Olgusal tutarlılığa vurgu yapmak, daha az spesifik ve dolayısıyla gerçekle uyuşmama ihtimali daha düşük ama aynı zamanda daha az ilgili özetler üretebilir
  - Tersine, yazım tarzı ve ifade gücüne vurgu yapmak, olgusal tutarsızlıklara yol açabilecek daha gösterişli, pazarlama dili benzeri bir anlatım üretebilir

Etiketlemeyi ikili görevler veya ikili (pairwise) karşılaştırmalarla sadeleştirin

Model çıktısına açık uçlu geri bildirim vermek veya Likert ölçeğiyle değerlendirmek bilişsel olarak zordur
- Bunun sonucunda toplanan veri, insan değerlendiriciler arasındaki değişkenlik nedeniyle daha gürültülü olur ve bu yüzden daha az faydalı hale gelir
Daha etkili yaklaşım, görevi basitleştirmek ve etiketleyicinin bilişsel yükünü azaltmaktır
- İyi çalışan iki yöntem ikili sınıflandırma ve ikili karşılaştırmadır
İkili sınıflandırmada etiketleyiciden model çıktısı hakkında basit bir evet/hayır kararı vermesi istenir
- Üretilen özetin kaynak belgeyle olgusal olarak tutarlı olup olmadığı, önerilen yanıtın ilgili olup olmadığı ya da zararlı içerik barındırıp barındırmadığı sorulabilir
- Likert ölçeğine kıyasla ikili kararlar daha doğru, değerlendiriciler arası daha tutarlı ve daha yüksek verimlidir
- Doordash'in bir dizi evet/hayır sorusuyla menü öğelerini etiketlemek için bir etiketleme kuyruğu kurma biçimi buna örnektir
İkili karşılaştırmada (Pairwise Comparison) etiketleyiciye model yanıtlarından oluşan bir çift verilir ve hangisinin daha iyi olduğu sorulur
- İnsanların A ya da B'yi ayrı ayrı puanlamasındansa "A, B'den daha iyidir" demesi daha kolay olduğundan, bu yaklaşım daha hızlı ve daha güvenilir etiketleme sağlar (Likert ölçeğine göre)
Llama2 meetup'ında, Llama2 makalesinin yazarlarından Thomas Scialom, ikili karşılaştırmanın yazılı yanıtlar gibi denetimli ince ayar verisi toplamaktan daha hızlı ve daha ucuz olduğunu doğruladı
- İlkinin birim maliyeti 3,5 $, ikincisinin ise birim maliyeti 25 $

Referans gerektirmeyen değerlendirme ve guardrail'ler birbirinin yerine kullanılabilir

Guardrail'ler uygunsuz veya zararlı içeriği yakalamaya yardımcı olurken, değerlendirmeler model çıktısının kalitesini ve doğruluğunu ölçmeye yardımcı olur
- Referans gerektirmeyen değerlendirmeler söz konusu olduğunda bunlar aynı madalyonun iki yüzü gibi görülebilir
  - Referans gerektirmeyen değerlendirme, insan tarafından yazılmış bir yanıt gibi "golden" bir referansa dayanmadan yalnızca giriş prompt'u ve modelin yanıtını kullanarak çıktı kalitesini değerlendirebilen bir değerlendirmedir
Referans gerektirmeyen değerlendirmeye örnek: özet değerlendirmesi
- Özetin olgusal tutarlılığını ve ilgililiğini değerlendirmek için yalnızca giriş belgesini dikkate almak yeterlidir
- Özet bu metriklerde düşük puan alıyorsa, kullanıcıya gösterilmemesi seçilebilir; böylece değerlendirme fiilen bir guardrail olarak kullanılmış olur
Referans gerektirmeyen "çeviri" değerlendirmesi:
- İnsan tarafından yapılmış bir çeviri referansı olmadan da çeviri kalitesi değerlendirilebilir; bu da yine bir guardrail olarak kullanılabilir

LLM'ler, yapmamaları gereken durumlarda da çıktı döndürür

LLM'lerle çalışırken başlıca zorluklardan biri, LLM'in yapmaması gereken durumlarda bile sık sık çıktı üretmesidir
- Bu, zararsız ama anlamsız yanıtlardan zararlı veya riskli içerik gibi daha ciddi kusurlara kadar gidebilir
- Örneğin bir belgeden belirli özellikleri veya meta verileri çıkarması istendiğinde, ilgili değer gerçekte mevcut olmasa bile LLM kendinden emin şekilde bir değer döndürebilir
- Ya da bağlamda İngilizce dışı bir belge verildiği için model İngilizce dışı bir dilde yanıt verebilir
LLM'e "uygulanamaz" veya "bilmiyorum" yanıtı döndürmesini söyleyen prompt'lar verilebilir, ancak bu kusursuz değildir
- Log olasılıkları kullanılabiliyor olsa bile, bunlar çıktı kalitesinin zayıf bir göstergesidir
  - Log olasılıkları, token'ların çıktıda görünme olasılığını gösterir; ancak üretilen metnin doğruluğunu yansıtmaz
- Hatta sorgulara yanıt vermek ve tutarlı yanıtlar üretmek üzere eğitilmiş instruction-tuned modellerde log olasılıkları iyi kalibre edilmemiş olabilir
  - Bu nedenle yüksek log olasılığı, çıktının akıcı ve tutarlı olduğunu gösterebilir; ancak doğru veya ilgili olduğu anlamına gelmez
Dikkatli prompt mühendisliği bir ölçüde yardımcı olabilir, ancak bunu istenmeyen çıktıları tespit edip filtreleyen/yeniden üreten güçlü guardrail'lerle tamamlamak gerekir
- Örneğin OpenAI, nefret söylemi, kendine zarar verme veya cinsel içerik gibi güvensiz yanıtları tespit edebilen bir içerik moderasyon API'si sunar
- Benzer şekilde kişisel olarak tanımlanabilir bilgileri (PII) tespit etmek için çok sayıda paket vardır
Guardrail'lerin bir avantajı, kullanım senaryosundan büyük ölçüde bağımsız olmaları ve bu nedenle belirli bir dildeki tüm çıktılara geniş ölçekte uygulanabilmeleridir
- Ayrıca hassas retrieval sayesinde ilgili belge yoksa sistem kararlı biçimde "bilmiyorum" yanıtı verebilir
LLM'ler, çıktı beklenen durumlarda çıktı üretemeyebilir de
- Bu, API sağlayıcısının yüksek gecikmesi gibi basit sorunlardan içerik moderasyon filtreleri nedeniyle çıktının engellenmesi gibi daha karmaşık sorunlara kadar çeşitli nedenlerle olabilir
Bu nedenle, hata ayıklama ve izleme için girdileri ve (gerekirse çıktı eksikliğini de) tutarlı biçimde kaydetmek önemlidir

Halüsinasyon (Hallucination) kalıcı bir sorundur

İçerik güvenliği ya da PII kusurları çok fazla dikkat gördüğü için nadiren ortaya çıkarken, olgusal tutarsızlıklar inatçı biçimde sürer ve tespit edilmesi daha zordur
- Daha yaygın görülür; taban görülme oranı %5-10’dur ve LLM sağlayıcılarından öğrendiğimize göre özetleme gibi basit görevlerde bile bunu %2’nin altına indirmek zor olabilir
Bunu çözmek için prompt engineering (üretim öncesi) ile olgusal tutarsızlık guardrail’lerini (üretim sonrası) birleştirebilirsiniz
- Prompt engineering açısından, CoT gibi teknikler LLM’in nihai çıktıyı vermeden önce akıl yürütmesini açıklamasını sağlayarak halüsinasyonları azaltmaya yardımcı olur
- Ardından özetin olgusallığını değerlendirmek ve halüsinasyonları filtrelemek ya da yeniden üretmek için olgusal tutarsızlık guardrail’leri uygulanabilir
Bazı durumlarda halüsinasyonlar deterministik olarak tespit edilebilir
- RAG aramasının kaynakları kullanıldığında, çıktı yapılandırılmışsa ve kaynağın ne olduğu tanımlanabiliyorsa, girdideki bağlamdan alınıp alınmadığı manuel olarak doğrulanabilmelidir

[Operasyon: Günlük işleyiş (Day-to-Day) ve organizasyon sorunları ]

Operasyon 1. Veri

Nasıl malzemenin kalitesi yemeğin lezzetini belirliyorsa, girdi verisinin kalitesi de makine öğrenimi sisteminin performansını sınırlar
Ayrıca çıktı verisi, ürünün çalışıp çalışmadığını bilmenin tek yoludur
Tüm yazarlar, veri dağılımını (modlar, edge case’ler, modelin sınırları) daha iyi anlamak için her hafta birkaç saat boyunca girdileri ve çıktıları yakından inceler

Geliştirme-prodüksiyon sapmasını kontrol etme

Geleneksel makine öğrenimi pipeline’larında hataların yaygın nedenlerinden biri eğitim-servis sapmasıdır
- Bu, eğitimde kullanılan veri modelin prodüksiyonda karşılaştığı veriden farklı olduğunda ortaya çıkar
Eğitim ya da fine-tuning olmadan LLM kullanılabildiği için bir eğitim seti yoktur, ancak buna benzer bir sorun olan geliştirme-prodüksiyon veri sapması ortaya çıkar
- Temel olarak, geliştirme sırasında sistemi test ettiğiniz verinin, sistemin prodüksiyonda karşılaşacağı veriyi yansıtması gerekir
  - Aksi halde prodüksiyon doğruluğu düşebilir
LLM geliştirme-prodüksiyon sapması iki türe ayrılabilir: yapısal sapma ve içerik temelli sapma
- Yapısal sapma; liste değerleri içeren bir JSON dictionary ile bir JSON list arasındaki fark, tutarsız büyük/küçük harf kullanımı ve yazım hataları ya da cümle parçaları gibi hatalar dahil olmak üzere biçim uyumsuzluğu gibi sorunları kapsar
  - Bu tür hatalar, farklı LLM’lerin belirli veri biçimleriyle eğitilmiş olması ve prompt’ların küçük değişikliklere karşı çok hassas olabilmesi nedeniyle öngörülemez model performansına yol açabilir
- İçerik temelli ya da "semantik" sapma, verinin anlamı veya bağlamındaki farklılıkları ifade eder
Geleneksel ML’de olduğu gibi, LLM girdi-çıktı çiftleri arasındaki sapmayı periyodik olarak ölçmek faydalıdır
- Girdi ve çıktı uzunluğu ya da belirli biçim gereksinimleri (ör. JSON veya XML) gibi basit metrikler, değişiklikleri takip etmenin kolay bir yoludur
Daha "ileri" sapma tespiti için, kullanıcıların daha önce modele maruz kalmamış alanları keşfetmeye başladığını gösterebilecek, kullanıcıların tartıştığı konulardaki değişimler gibi semantik sapmaları tespit etmek amacıyla girdi-çıktı çiftlerinin embedding’lerini kümelemeyi değerlendirin
Prompt engineering gibi değişiklikleri test ederken, holdout veri setinin güncel olduğundan ve kullanıcı etkileşimlerinin en son türlerini yansıttığından emin olun
- Örneğin prodüksiyon girdilerinde yazım hataları yaygınsa, holdout verisinde de bulunmalıdır
Sapmayı yalnızca sayılarla ölçmenin ötesinde, çıktılar üzerinde nitel değerlendirme yapmak da yararlıdır
- Modelin çıktılarını düzenli olarak gözden geçirmek (argo olarak "vibe check" diye bilinen uygulama), sonuçların beklentileri karşılayıp karşılamadığını ve kullanıcı ihtiyaçlarıyla ilişkili kalmayı sürdürüp sürdürmediğini doğrular
Sapma kontrolüne nondeterminism’i dahil etmek de faydalıdır
- Test veri setindeki her girdi için pipeline’ı birden fazla kez çalıştırıp tüm çıktıları analiz ederek, yalnızca ara sıra ortaya çıkabilen anormallikleri yakalama olasılığınız artar

Her gün LLM girdi-çıktı örneklerini kontrol etmek

LLM’ler dinamiktir ve sürekli evrilmektedir
- Etkileyici zero-shot yeteneklerine ve çoğu zaman tatmin edici çıktılara rağmen, LLM’lerin hata modları son derece öngörülemezdir
Özelleştirilmiş görevlerde, LLM’in performansına dair sezgisel bir anlayış geliştirmek için veri örneklerini düzenli olarak incelemek şarttır
- Prodüksiyondaki girdi-çıktı çiftleri, LLM uygulamalarının "gerçek nesne, gerçek yer"idir (genchi genbutsu) ve bunun yerini başka bir şey tutamaz
Son araştırmalar, geliştirici ne kadar çok veriyle etkileşime girerse "iyi" çıktı ve "kötü" çıktı algısının o kadar değiştiğini vurguluyor (yani ölçüt sapması)
- Geliştiriciler, LLM çıktılarını değerlendirmek için bazı ölçütleri önceden belirleyebilir, ancak bu önceden tanımlı ölçütler çoğu zaman eksiktir
Örneğin geliştirme sürecinde, iyi yanıt olasılığını artırmak ve kötü yanıt olasılığını azaltmak için prompt güncellenebilir
- Değerlendirme, yeniden değerlendirme ve ölçüt güncellemenin bu yinelemeli süreci gereklidir; çünkü çıktıları doğrudan gözlemlemeden LLM davranışını ya da insan tercihlerini tahmin etmek zordur
Bunu etkili biçimde yönetmek için LLM girdileri ve çıktıları kaydedilmelidir
- Bu log örneklerini her gün incelemek, yeni örüntüleri veya hata modlarını hızlıca tespit edip uyum sağlamayı mümkün kılar
- Yeni bir sorun keşfedildiğinde, bunun için hemen bir assertion ya da eval yazılabilir
Benzer şekilde, hata modu tanımındaki tüm güncellemeler değerlendirme ölçütlerine yansıtılmalıdır
- Bu "vibe check"ler hatalı çıktının sinyalleridir; kod ve assertion’lar ise bunu operasyonel hale getirir
Son olarak bu yaklaşımın yaygınlaştırılması gerekir
- Örneğin on-call rotasyonuna girdi ve çıktı inceleme ya da açıklama eklemek

Operasyon 2. Modelle çalışmak

LLM API’lerini kullanmak, az sayıda sağlayıcının zekâsına bağımlı olmanız anlamına gelebilir
- Bu iyi bir şeydir, ancak bu bağımlılık performans, gecikme, throughput ve maliyet açısından çeşitli ödünleşmeleri beraberinde getirir
Ayrıca son bir yılda neredeyse her ay daha yeni ve daha iyi modeller çıktığından, eski modelleri emekliye ayırıp yeni modellere geçerken ürünü güncellemeye hazır olmalısınız
- Bu bölüm, tamamen kontrolünüzde olmayan, yani self-host edip yönetemeyeceğiniz teknolojileri kullanırken edinilen dersleri paylaşır
Çoğu gerçek kullanım senaryosunda, LLM çıktısı downstream uygulamalar tarafından bir tür makine tarafından okunabilir biçim üzerinden tüketilecektir
- Örneğin gayrimenkul CRM’i ReChat, frontend’de widget render etmek için yapılandırılmış yanıtlara ihtiyaç duyar
- Benzer şekilde ürün stratejisi fikir üretim aracı Boba, başlık, özet, uygulanabilirlik puanı ve zaman aralığı alanlarını içeren yapılandırılmış çıktılara ihtiyaç duyar
- Son olarak LinkedIn, kullanılacak tekniği belirlemek ve tekniği çağırmak için parametreleri sağlamak amacıyla LLM’i YAML üretmeye kısıtlama yöntemini paylaştı
Bu uygulama deseni, Postel yasasının uç bir versiyonudur
- Kabul ettiğiniz şeyde (serbest doğal dil) esnek, gönderdiğiniz şeyde (tiplenmiş, makine tarafından okunabilir nesneler) tutucu olmalısınız
- Bu nedenle bunun oldukça dayanıklı olmasını bekliyoruz
Bugün Instructor ve Outlines, LLM’lerden yapılandırılmış çıktı elde etmek için fiili standarttır
- LLM API’leri (ör. Anthropic, OpenAI) kullanıyorsanız Instructor, self-host edilen modeller (ör. Huggingface) kullanıyorsanız Outlines kullanın

Modeller arası prompt migrasyonu sancılıdır

Bazen özenle hazırlanmış bir prompt bir modelde harika çalışırken başka bir modelde düzgün çalışmayabilir
- Bu durum yalnızca farklı model sağlayıcıları arasında geçiş yaparken değil, aynı modelin sürümleri arasında yükseltme yaparken de ortaya çıkabilir
Örneğin Voiceflow, gpt-3.5-turbo-0301 sürümünden gpt-3.5-turbo-1106 sürümüne geçildiğinde niyet sınıflandırma görevlerinde performansın %10 düştüğünü fark etti
- (Neyse ki ellerinde değerlendirme vardı!)
Benzer şekilde GoDaddy, 1106 sürümüne yükseltildiğinde gpt-3.5-turbo ile gpt-4 arasındaki performans farkının olumlu yönde daraldığını gözlemledi
- (Ya da bardağın dolu tarafına bakmıyorsanız, yeni yükseltmeyle gpt-4'ün liderliğinin azalmasına hayal kırıklığı olarak da bakabilirsiniz)
Bu yüzden modeller arasında prompt taşımanız gerekiyorsa, bunun yalnızca API endpoint'ini değiştirmekten daha fazla zaman alacağını varsaymalısınız
- Aynı prompt'u bağlamanın benzer ya da daha iyi sonuçlar vereceğini varsaymayın
Ayrıca güvenilir ve otomatik değerlendirmeler, geçiş öncesi ve sonrası görev performansını ölçmeye yardımcı olur ve manuel doğrulama için gereken çabayı azaltır

Model sürüm yönetimi ve sabitleme

Her makine öğrenimi hattında, "herhangi bir şeyi değiştirirseniz her şey değişir"
- Bu, özellikle bizim eğitmediğimiz ve bize haber verilmeden değişebilen büyük dil modelleri (LLM'ler) gibi bileşenlere bağımlı olduğumuzda daha da önemlidir
Neyse ki birçok model sağlayıcısı, belirli bir model sürümünü (ör. gpt-4-turbo-1106) "sabitleme" seçeneği sunar
- Bu sayede model ağırlıklarının belirli bir sürümünü kullanıp onun değişmeden kalmasını sağlayabilirsiniz
Üretimde model sürümünü sabitlemek, model davranışındaki beklenmedik değişiklikleri önleyebilir
- Bu, model değiştirildiğinde ortaya çıkabilecek aşırı uzun çıktılar veya diğer beklenmedik hata modları gibi sorunlar nedeniyle müşteri şikayetlerinden kaçınmaya yardımcı olabilir
Ayrıca üretim ayarlarını yansıtan, ancak en yeni model sürümünü kullanan bir "gölge hat" sürdürmeyi de düşünebilirsiniz
- Bu, yeni sürümlerle güvenli deneyler ve testler yapmanızı sağlar
Bu yeni modellerde çıktıların kararlılığını ve kalitesini doğruladıktan sonra, üretim ortamındaki model sürümünü güvenle güncelleyebilirsiniz

İşi tamamlayabilecek en küçük modeli seçmek

Yeni bir uygulama üzerinde çalışırken eldeki en büyük ve en güçlü modeli kullanma cazibesi vardır
- Ancak bir görevin teknik olarak mümkün olduğu doğrulandıktan sonra, benzer sonuçların daha küçük bir modelle elde edilip edilemeyeceğini denemek faydalıdır
Küçük modellerin avantajı daha düşük gecikme ve maliyettir
- Daha zayıf olabilirler, ancak Chain-of-Thought, n-shot prompt'lar ve in-context learning gibi teknikler küçük modellerin kendi kapasitelerinin ötesine geçmesine yardımcı olabilir
LLM API'lerinin ötesinde, belirli görevlere yönelik fine-tuning de performans artışına yardımcı olabilir
Genel olarak, küçük modeller kullanan dikkatle tasarlanmış bir iş akışı, daha hızlı ve daha ucuz olurken tek bir büyük modelin çıktı kalitesine yetişebilir, hatta onu aşabilir
- Örneğin bu tweet, Haiku + 10-shot prompt'un zero-shot Opus ve GPT-4'ü nasıl geçtiğine dair bir anekdot paylaşıyor
Uzun vadede, çıktı kalitesi, gecikme ve maliyet arasında en iyi dengeyi sağlayan küçük modellerle akış mühendisliğine dair daha fazla örnek ortaya çıkması bekleniyor
Bir başka örnek olarak mütevazı sınıflandırma görevini ele alabiliriz
- DistilBERT (67 milyon parametre) gibi hafif modeller şaşırtıcı derecede güçlü bir başlangıç çizgisidir
- 400 milyon parametreli DistilBART da bir başka harika seçenektir
  - Açık kaynak veriler üzerinde fine-tuning yapıldığında, çoğu LLM'yi %5'ten az gecikme ve maliyetle geride bırakarak halüsinasyonları 0.84 ROC-AUC ile tespit edebilir
Buradaki çıkarım, küçük modelleri göz ardı etmemeniz gerektiğidir
- Her probleme devasa bir model uygulamak kolaydır, ancak biraz yaratıcılık ve denemeyle çoğu zaman daha verimli çözümler bulabiliriz

Operasyon 3. Ürün

Yeni teknoloji yeni imkanlar sunar, ancak harika ürünler inşa etmenin ilkeleri kalıcıdır
- Bu nedenle, ilk kez yeni bir problemi çözüyor olsanız bile ürün tasarımı konusunda tekerleği yeniden icat etmeniz gerekmez
LLM uygulama geliştirmeyi sağlam ürün temelleri üzerine kurarak çok şey kazanılabilir
- Bu, hizmet verdiğimiz insanlara gerçek değer sunmamıza yardımcı olur

Tasarımı en baştan sürece dahil etmek

Tasarımcıların varlığı, ürünü nasıl inşa edebileceğimizi ve kullanıcılara nasıl sunabileceğimizi anlamamızı ve bunun üzerine derinlemesine düşünmemizi sağlar
- Bazen tasarımcıları sadece işleri güzel gösteren kişiler olarak klişeleştiririz
- Oysa onlar yalnızca kullanıcı arayüzünü değil, gerekirse mevcut kuralları ve paradigmaları bozarak kullanıcı deneyimini nasıl iyileştirebileceğimizi de yeniden düşünür
Tasarımcılar, kullanıcı ihtiyaçlarını farklı biçimlerde yeniden çerçeveleme konusunda özellikle yeteneklidir
- Bu biçimlerin bazılarını çözmek diğerlerine göre daha kolaydır; dolayısıyla bazıları AI çözümleri için daha fazla, bazılarıysa daha az fırsat sunabilir
Diğer birçok üründe olduğu gibi, AI ürünü geliştirmek de ürünü çalıştıran teknoloji etrafında değil, yapılacak iş etrafında şekillenmelidir
Şu tür soruları kendinize sormaya odaklanın
- "Kullanıcı bu üründen hangi işi yapmasını istiyor? Bu iş bir chatbot'un iyi yapacağı türden bir iş mi? Ya otomatik tamamlama? Belki de bambaşka bir şeydir!"
Mevcut tasarım kalıplarını ve bunların yapılacak işle nasıl ilişkili olduğunu değerlendirin
- Bunlar, tasarımcıların takımın yeteneklerine kattığı değerli varlıklardır

Human-in-the-loop için UX tasarımı

İyi kalitede açıklama/veri etiketi elde etmenin bir yolu, kullanıcı deneyimine (UX) Human-in-the-Loop (HITL) yaklaşımını entegre etmektir
- Kullanıcıların kolayca geri bildirim ve düzeltme sağlayabilmesi, hem anlık çıktıyı iyileştirir hem de modeli geliştirmek için faydalı veriler toplar
Kullanıcıların ürün yükleyip sınıflandırdığı bir e-ticaret platformu hayal edelim
- UX’i tasarlamanın birden çok yolu vardır
  1. Kullanıcı doğru ürün kategorisini manuel olarak seçer, LLM ise periyodik olarak yeni ürünleri kontrol edip arka planda yanlış sınıflandırmaları düzeltir
  2. Kullanıcı hiç kategori seçmez, LLM ise periyodik olarak ürünleri arka planda sınıflandırır (olası hatalarla birlikte)
  3. LLM, ürün kategorisini gerçek zamanlı olarak önerir ve kullanıcı gerektiğinde bunu doğrulayıp güncelleyebilir
Üç yaklaşımın tümü LLM içerir, ancak çok farklı UX sunar
- İlk yaklaşım başlangıç yükünü kullanıcıya bindirir ve LLM sonradan kontrol eden bir denetim katmanı görevi görür
- İkinci yaklaşım kullanıcıdan hiç çaba istemez, ancak şeffaflık ya da kontrol sunmaz
- Üçüncü yaklaşım uygun dengeyi kurar
  - LLM’in önceden kategori önermesi, kullanıcının bilişsel yükünü azaltır ve ürünü sınıflandırmak için bizim taksonomimizi öğrenme gereğini ortadan kaldırır
  - Aynı anda, kullanıcının öneriyi gözden geçirip düzenleyebilmesine izin vererek ürünün nasıl sınıflandırılacağına ilişkin nihai karar yetkisini güçlü biçimde kullanıcının elinde tutar
- Ek olarak üçüncü yaklaşım, modeli iyileştirmek için doğal bir geri bildirim döngüsü oluşturur
  - İyi öneriler kabul edilir (pozitif etiket), kötü öneriler ise güncellenir (negatif ardından pozitif etiket)
Öneri, kullanıcı doğrulaması ve veri toplama kalıbı birçok uygulamada yaygın olarak görülür
- Kodlama asistanı: kullanıcı öneriyi kabul edebilir (güçlü pozitif), kabul edip düzenleyebilir (pozitif) veya görmezden gelebilir (negatif)
- Midjourney: kullanıcı görseli upscale edip indirebilir (güçlü pozitif), görseli değiştirebilir (pozitif) ya da yeni bir görsel seti oluşturabilir (negatif)
- Chatbot: kullanıcı yanıta beğen (pozitif) veya beğenme (negatif) verebilir ya da yanıt gerçekten kötüyse yeniden yanıt üretmeyi seçebilir (güçlü negatif)
Geri bildirim açık ya da örtük olabilir
- Açık geri bildirim, kullanıcının ürünün talebine yanıt olarak sağladığı bilgidir
- Örtük geri bildirim ise kullanıcının bilerek geri bildirim vermesi gerekmeden, kullanıcı etkileşimlerinden öğrenilen bilgidir
Kodlama asistanları ve Midjourney örtük geri bildirime örnektir; beğen ve beğenme ise açık geri bildirimdir
- Kodlama asistanları ve Midjourney’de olduğu gibi UX’i iyi tasarlarsanız, hem ürünü hem de modeli geliştirmek için çok miktarda örtük geri bildirim toplayabilirsiniz

Gereksinim hiyerarşisini acımasızca önceliklendirin

Bir demoyu production’a almayı düşünürken, şu gereksinimleri göz önünde bulundurmak gerekir
- Güvenilirlik: %99,9 uptime, yapılandırılmış çıktı uyumu
- Zararsızlık: saldırgan, NSFW veya başka türlü zararlı içerik üretmemek
- Olgusal tutarlılık: sağlanan bağlama sadık kalmak ve gerçekleri çarpıtmamak
- Faydalılık: kullanıcının ihtiyaç ve talepleriyle ilgili olmak
- Ölçeklenebilirlik: gecikme SLA’leri, desteklenen throughput
- Maliyet: çünkü bütçe sınırsız değildir
- Diğerleri: güvenlik, gizlilik, adillik, GDPR, DMA vb.
Bu gereksinimlerin hepsini aynı anda çözmeye çalışırsanız, hiçbir şeyi yayına alamazsınız
- Bu yüzden önceliklendirme yapmalısınız. Hem de acımasızca.
Bu, ürünün çalışmamasına ya da uygulanabilir olmamasına yol açabilecek, taviz verilemez unsurların (ör. güvenilirlik, zararsızlık) ne olduğunu netleştirmek anlamına gelir
- MVP (Minimum Lovable Product) ürünü tanımlamak önemlidir
İlk sürümün mükemmel olmayacağını kabul etmeli, yayına almalı ve yinelemelisiniz

Kullanım durumuna göre risk toleransını ayarlayın

Dil modeli ve uygulamalar için ne düzeyde inceleme gerektiğine karar verirken, kullanım durumunu ve hedef kitleyi dikkate almalısınız
- Tıbbi veya finansal tavsiye veren, müşteriye dönük bir chatbot için güvenlik ve doğruluk açısından çok yüksek bir standart gerekir
  - Hatalar veya yanlış çıktılar gerçek zarara yol açabilir ve güven kaybı yaratabilir
- Buna karşılık öneri sistemleri gibi daha az kritik uygulamalarda ya da içerik sınıflandırma veya özetleme gibi iç kullanıma dönük uygulamalarda, aşırı katı gereksinimler fazla değer katmadan sadece ilerlemeyi yavaşlatır
Bu, birçok şirketin dışa dönük uygulamalara kıyasla iç LLM uygulamalarında daha hızlı ilerlediğini söyleyen yakın tarihli a16z raporuyla da uyumludur
- Kurumlar, iç verimlilik için AI deneyleri yaparak, daha kontrollü bir ortamda riski nasıl yöneteceklerini öğrenirken değer elde etmeye başlayabilir
- Ardından, güven kazandıkça bunu müşteriye dönük kullanım senaryolarına genişletebilirler

Operasyon 4. Takım ve roller

Hiçbir iş rolünü tanımlamak kolay değildir, ancak bu yeni alanda iş tanımı yazmak diğerlerinden daha da zordur
- Kesişen unvanlara dair bir Venn diyagramını ya da iş tanımı önerilerini burada atlayacağım
- Ancak yeni bir rol olan AI engineer’ın varlığını kabul edip bu rolü tartışacağım
Daha önemlisi, ekibin geri kalanında görev ve sorumlulukların nasıl dağıtılması gerektiğini tartışacağım

Araçlara değil sürece odaklanın

LLM gibi yeni bir paradigma ile karşılaşıldığında, yazılım mühendisleri araçlara yönelme eğilimindedir
- Bunun sonucunda, bu araçların çözmeye çalıştığı problemler ve süreçler gözden kaçabilir
- Böyle yapıldığında birçok mühendis tesadüfi karmaşıklığı üzerine alır ve bu da ekibin uzun vadeli üretkenliğini olumsuz etkiler
Örneğin bu yazı, belirli bir aracın büyük dil modelleri için prompt’ları nasıl otomatik üretebildiğini açıklıyor
- Buradaki sav, problem çözme metodolojisini veya sürecini önce anlamadan bu araçları kullanan mühendislerin sonunda gereksiz teknik borç yükleneceğidir (bence haklı olarak)
Tesadüfi karmaşıklığın yanı sıra, araçlar çoğu zaman yetersiz biçimde tanımlanmıştır
- Örneğin zararlılık, kısalık, ton vb. için genel değerlendiriciler içeren “LLM evaluation toolbox” sunan bir LLM değerlendirme araçları endüstrisi büyüyor
- Birçok ekibin, kendi alanlarına özgü hata modları üzerine eleştirel biçimde düşünmeden bu araçları benimsediğini görüyorum
Buna karşılık EvalGen, alan özelinde değerlendirmeler üretme sürecini kullanıcıya öğretmeye; kullanıcıyı ölçüt tanımlama, veri etiketleme, değerlendirmeyi doğrulama gibi her adıma derinlemesine dahil etmeye odaklanır
- Yazılım, kullanıcıyı şu tür bir iş akışıyla yönlendirir
EvalGen’in yönlendirdiği LLM değerlendirmesi oluşturma için en iyi uygulamalar
1. Alana özgü testleri tanımlayın (prompt’lardan otomatik olarak bootstrap edilir)
  - Kodla veya LLM-as-a-Judge ile assertion olarak tanımlanır
2. Testlerin tanımlanan ölçütleri yakaladığını kullanıcının doğrulayabilmesi için, testleri insan yargısıyla hizalamanın önemini anlayın
3. Sistem (prompt vb.) değiştikçe testleri yineleyin
EvalGen, geliştiricilere değerlendirme oluşturma süreci için bir mental model sunar, ancak onları belirli bir araca kilitlemez
- AI engineer’lara bu bağlam sağlandıktan sonra, çoğu zaman daha basit araçları seçmeye ya da kendi araçlarını geliştirmeye karar verdiklerini görüyoruz
Prompt yazımı ve değerlendirme dışında, LLM’in o kadar çok bileşeni vardır ki hepsini burada listelemek mümkün değildir
- Yine de AI engineer’ların araçları benimsemeden önce süreci anlamaya çalışması önemlidir

Her zaman deney yapın

ML ürünleri deneylerle yakından ilişkilidir
- Bu, yalnızca A/B testleri ve rastgele kontrollü deneyler değil, aynı zamanda sistemin mümkün olan en küçük bileşenlerini değiştirip çevrimdışı değerlendirmeler yapmaya yönelik sık girişimler anlamına gelir
- Herkesin değerlendirmelere bu kadar ilgi duymasının nedeni, bunun aslında güvenilirlik ve özgüvenle değil, deney yapmayı mümkün kılmasıyla ilgili olmasıdır!
  - Değerlendirme ne kadar iyiyse, deneyleri o kadar hızlı yineleyebilirsiniz; dolayısıyla sistemin en iyi sürümüne de o kadar hızlı yakınsarsınız
Deney yapmak çok ucuz hale geldiği için, aynı problemi çözmek adına farklı yaklaşımlar denemek artık yaygındır
- Veri toplama ve model eğitiminin yüksek maliyeti en aza inmiştir
  - Prompt engineering maliyeti, insan zamanının biraz ötesine geçer
- Herkesin prompt engineering temellerini öğrenebilmesi için ekibi buna göre yapılandırın
  - Bu, herkesi deney yapmaya teşvik eder ve organizasyon genelinde çeşitli fikirlere yol açar
Yalnızca keşif için deney yapmayın; deneyleri kullanımdan yararlanmak için de kullanın!
- Yeni bir görevin çalışan bir sürümü var mı?
  - Ekipten başka birinin buna farklı bir şekilde yaklaşmasını değerlendirin
- Daha hızlı olabilecek farklı bir yöntem deneyin
- Kaliteyi artırmak için Chain-of-Thought veya Few-Shot gibi prompt tekniklerini araştırın
- Araçların deney yapmayı engellememesini sağlayın
  - Öyleyse yeniden inşa edin ya da iyileştirilebilecek bir şeyi satın alın
Ürün/proje planlaması sırasında, değerlendirme oluşturmak ve birden çok deney yürütmek için ayrıca zaman ayırın
- Mühendislik ürününe yönelik ürün gereksinimlerini düşünün ve buna değerlendirme için net kriterler ekleyin
Yol haritası hazırlarken deneyler için gereken süreyi olduğundan az tahmin etmeyin
- Prodüksiyon onayı almadan önce birden fazla geliştirme ve değerlendirme iterasyonu olacağını varsayın

Herkese yeni AI teknolojilerini kullanma yetkisi verin

Üretken yapay zekanın benimsenmesi arttıkça, yalnızca uzmanların değil tüm ekibin bu yeni teknolojiyi anlayabildiğini ve kullanabildiğini hissetmesini istersiniz
- LLM'lerin nasıl çalıştığına dair sezgi geliştirmek için daha iyi bir yol yoktur (ör. gecikme, hata modları, UX)
- LLM'ler nispeten erişilebilirdir
  - Pipeline performansını artırmak için kod yazmayı bilmek gerekmez; herkes prompt engineering ve değerlendirme yoluyla katkı sunabilir
Bunun büyük bir bölümü eğitimdir
- n-shot prompting ve CoT gibi tekniklerin, modeli istenen çıktı yönüne koşullandırmaya nasıl yardımcı olduğuna uzanan prompt engineering temelleriyle başlayabilirsiniz
Bilgi sahibi kişiler, LLM'lerin özünde otoregresif olması gibi daha teknik yönler hakkında da eğitim verebilir
- Yani giriş token'ları paralel olarak işlenir, ancak çıkış token'ları sıralı olarak üretilir
- Bu nedenle gecikme, giriş uzunluğundan çok çıkış uzunluğunun bir fonksiyonudur
  - Bu, UX tasarlarken ve performans beklentilerini belirlerken temel bir dikkate alma noktasıdır
Deney ve keşif için uygulamalı fırsatlar da sunabilirsiniz
- Bir hackathon nasıl olur?
  - Tüm ekibin birkaç gün boyunca spekülatif projeler üzerinde uğraşması pahalı görünebilir, ancak sonuçlar sizi şaşırtabilir
- Bir hackathon sayesinde 3 yıllık yol haritasını neredeyse 1 yılda tamamlayan bir ekip oldu
  - Başka bir ekip ise hackathon aracılığıyla, artık LLM'ler sayesinde mümkün hale gelen bir paradigma değişimi UX'ine ulaştı; bu da artık bu yılın ve sonrasının önceliği haline geldi

"AI engineering her şeydir" tuzağına düşmeyin

Yeni bir unvan ortaya çıktığında, başlangıçta bu rolle ilişkili yetkinlikleri abartma eğilimi vardır
- Bu da çoğu zaman, bu işlerin gerçek kapsamı netleştikçe acı verici düzeltmelere yol açar
- Bu alana yeni girenler ve işe alım yöneticileri abartılı iddialarda bulunabilir veya aşırı beklentilere kapılabilir
Son 10 yıldaki dikkat çekici örnekler şunlardır
- Veri bilimci: "Tüm yazılım mühendislerinden istatistiği daha iyi bilen ve tüm istatistikçilerden yazılım mühendisliğini daha iyi bilen kişi"
- Makine öğrenimi mühendisi (MLE): makine öğrenimine yazılım mühendisliği merkezli bir bakış
Başlangıçta birçok kişi, veri odaklı projeler için yalnızca veri bilimcilerin yeterli olduğunu varsaydı
- Ancak veri bilimcilerin, veri ürünlerini etkili biçimde geliştirmek ve dağıtmak için yazılım ve veri mühendisleriyle birlikte çalışması gerektiği zamanla netleşti
Bu yanlış anlama, AI engineer gibi yeni bir rolde yeniden ortaya çıktı ve bazı ekipler AI engineer'ın ihtiyaç duyulan tek şey olduğuna inandı
- Oysa pratikte, makine öğrenimi veya yapay zeka ürünü geliştirmek çok çeşitli uzman rolleri gerektirir
12'den fazla şirket ve AI ürünü hakkında danışmanlık verdik ve onların sürekli olarak "AI engineering ihtiyacınız olan tek şeydir" inancı tuzağına düştüğünü gözlemledik
- Sonuç olarak ürünler, ürün geliştirmek için gereken kritik yönleri gözden kaçırdıkları için, demoların ötesine ölçeklenmekte çoğu zaman zorlandı
Örneğin değerlendirme ve ölçüm, ürünü bir vibe check'in ötesine taşıyıp ölçeklemek için kritiktir
- Etkili değerlendirme için gereken beceriler, geleneksel olarak makine öğrenimi mühendislerinde görülen bazı güçlü yönlerle örtüşür
  - Yalnızca AI engineer'lardan oluşan bir ekibin bu becerilerden yoksun olma ihtimali yüksektir
Ortak yazarlardan Hamel Husain, veri yanlılığını tespit etme ve alana özgü değerlendirmeler tasarlamayla ilgili yakın dönem çalışmalarında bu becerilerin önemini açıklıyor
AI ürünü oluşturma yolculuğunda hangi rol türlerinin ne zaman gerekli olduğu
1. Önce ürün oluşturmaya odaklanın
- Bu aşamada AI engineer yer alabilir, ancak bu zorunlu değildir
- AI engineer, ürünü (UX, plumbing vb.) prototiplemek ve hızlı yinelemeler yapmak için faydalıdır
1. Sonraki adımda, sistemi enstrümante edin ve doğru temeli kurmak için veri toplayın
- Verinin türüne ve ölçeğine bağlı olarak platform ve/veya veri mühendislerine ihtiyaç duyabilirsiniz
- Ayrıca sorunları debug etmek için bu veriyi sorgulayıp analiz edebileceğiniz sistemler de olmalıdır
1. Sonra AI sistemini optimize edin
- Bu mutlaka model eğitimi anlamına gelmez
- Temel aşamalar arasında metrik tasarımı, değerlendirme sistemi kurma, deney yürütme, RAG retrieval optimizasyonu, olasılıksal sistemleri debug etme gibi adımlar yer alır
- MLE'ler bu alanda çok yetkindir (elbette AI engineer'lar da bunu edinebilir)
- Önceki adımları tamamlamadıysanız MLE işe almak genellikle mantıklı değildir
Bunun dışında her zaman alan uzmanlarına ihtiyaç vardır
- Küçük şirketlerde ideal olarak bu rolü kurucu ekip üstlenmelidir; büyük şirketlerde ise bu rolü ürün yöneticileri üstlenebilir
Roller arasındaki ilerleyişi ve zamanlamayı fark etmek önemlidir
- Yanlış zamanda insan işe almak (ör. MLE'yi çok erken işe almak) veya yanlış sırayla inşa etmek; zaman ve para kaybıdır, ayrıca işten ayrılmalara yol açar
Ayrıca 1-2. aşamalarda MLE'lerle düzenli check-in yapmak (ancak onları tam zamanlı işe almamak), şirketin doğru temeli kurmasına yardımcı olur

[Strateji: LLM ile ürün geliştirirken geride kalmamanın yolları]

Başarılı ürün geliştirme için, rastgele prototip üretmek veya en yeni modeli ya da trendi takip etmek yerine dikkatli planlama ve önceliklendirme gerekir
AI ürünü geliştirirken, doğrudan geliştirmek mi yoksa satın almak mı gibi temel trade-off'ları gözden geçirmek gerekir
İlk LLM uygulamalarını geliştirmek için bir "playbook" sunuluyor

Strateji 1: PMF öncesi GPU yok

Harika bir ürün olmak için, başkalarının API'sini yüzeysel biçimde paketlemekten daha fazlası olmak gerekir
Ancak ters yöndeki hata daha büyük maliyetlere yol açabilir
- Geçen yıl, net bir ürün vizyonu veya hedef pazar olmadan model eğitimi ve özelleştirmeye çok büyük miktarda girişim sermayesi harcandı
- Hatta bir şirket tam 6 milyar dolarlık Series A yatırımı aldı
Bu bölüm, neden hemen kendi modelinizi eğitmeye başlamanın bir hata olduğunu açıklayacak ve self-hosting'in rolünü değerlendirecek

En baştan (neredeyse) yeniden eğitmek anlamlı değil

Çoğu organizasyon için bir LLM’i en baştan pretraining etmek, ürün geliştirmeden uzaklaşan gerçekçi olmayan bir iştir
- Makine öğrenimi altyapısını geliştirmek ve sürdürmek çok fazla kaynak gerektirir
  - Buna veri toplama, model eğitimi ve değerlendirmesi, dağıtım gibi işler dahildir
- Ürün-pazar uyumunu doğrulama aşamasındaysanız, bu tür çabalar kaynakları çekirdek ürün geliştirmeden uzaklaştırır
- Hesaplama kaynağı, veri ve teknik yetkinlik olsa bile, pretrain edilmiş bir LLM birkaç ay içinde demode hale gelebilir
BloombergGPT örneği
- Finansal iş akışlarına özelleşmiş bir LLM olan BloombergGPT, 363B token ile pretraining edildi
- Yapay zeka mühendisliğinden 4 kişi, ML ürün ve araştırmadan 5 kişi olmak üzere 9 tam zamanlı çalışanın büyük emeği harcandı
- Buna rağmen 1 yıl içinde söz konusu görevlerde gpt-3.5-turbo ve gpt-4’ün gerisinde kaldı
Bu örnekler, çoğu gerçek dünya uygulamasında LLM’i sıfırdan pretraining etmenin kaynakların en iyi kullanımı olmadığını gösteriyor
- Bunun yerine ekiplerin, belirli gereksinimlere göre mevcut en güçlü açık kaynak modeli fine-tune etmesi daha iyidir
Elbette istisnalar vardır
- Replit’in kod modeli, kod üretimi ve anlamaya özelleşmiş, pretraining’in iyi bir örneğidir
- Pretraining sayesinde CodeLlama7b gibi daha büyük modellerden daha iyi performans gösterdi
- Ancak daha güçlü modeller piyasaya çıktıkça, faydasını korumak için sürekli yatırım gerekti

Gerektiği doğrulanana kadar fine-tuning yapmayın

Çoğu organizasyonda fine-tuning, stratejik düşünceden çok FOMO (Fear Of Missing Out, fırsatı kaçırma korkusu) tarafından yönlendirilir
- Organizasyonlar, “sadece basit bir wrapper” suçlamasından kaçınmak için fine-tuning’e çok erken yatırım yapar
- Oysa fine-tuning, ancak diğer yaklaşımların yeterli olmadığına ikna edecek kadar çok örnek toplandıktan sonra devreye alınması gereken ağır ekipman gibidir
1 yıl önce birçok ekip fine-tuning konusunda heyecanlıydı, ancak çok azı ürün-pazar uyumunu yakaladı ve çoğu kararından pişman oldu
- Fine-tuning yapacaksanız, temel model geliştikçe bunu tekrar tekrar yapmaya hazır olmalısınız
  - Aşağıdaki “Model ürün değildir” ve “LLMOps kurmak” bölümlerine bakın
Fine-tuning’in gerçekten doğru seçim olabileceği durumlar
- Mevcut modellerin eğitiminde kullanılan açık web ölçeğindeki veri setlerinin çoğunda bulunmayan verilere ihtiyaç duyuluyorsa
- Mevcut modellerin yeterli olmadığını gösteren bir MVP’yi zaten oluşturduysanız
- Ancak dikkatli olun: Harika eğitim verilerine model geliştiricileri bile kolayca erişemiyorsa, siz bunları nereden bulacaksınız?
LLM tabanlı uygulamalar bilim fuarı projesi değildir
- Yapılan yatırım, stratejik hedeflere ve rekabetçi farklılaşmaya katkısıyla orantılı olmalıdır

Çıkarım API’leriyle başlayın, ama self-hosting’den korkmayın

LLM API’lerini kullanmak, girişimlerin kendi modellerini sıfırdan eğitmeden dil modelleme yeteneklerini kolayca benimsemesini ve entegre etmesini sağlar
- Anthropic, OpenAI ve benzeri sağlayıcılar, yalnızca birkaç satır kodla ürüne zeka katabilecek genel API’ler sunar
- Bu hizmetleri kullanmak, harcanan çabayı azaltır ve müşteriler için değer üretmeye odaklanmanızı sağlayarak fikirleri doğrulamayı ve ürün-pazar uyumuna daha hızlı yinelemelerle ulaşmayı mümkün kılar
Ancak veritabanlarında olduğu gibi, yönetilen hizmetler ölçek ve gereksinimler arttıkça her kullanım senaryosuna uygun olmayabilir
- Hatta self-hosting, sağlık ve finans gibi regülasyona tabi sektörlerde ya da sözleşmesel yükümlülükler ve gizlilik gereksinimleri nedeniyle, gizli/kişisel verileri ağ dışına göndermeden modeli kullanmanın tek yolu olabilir
Ayrıca self-hosting, çıkarım sağlayıcılarının dayattığı hız sınırları, modelin kullanımdan kaldırılması ve kullanım kısıtları gibi sınırlamaları aşar
- Self-hosting, model üzerinde tam kontrol sağlayarak farklılaşmış ve yüksek kaliteli sistemler kurmayı kolaylaştırır
Son olarak self-hosting, özellikle de fine-tuning, büyük ölçekte maliyetleri düşürebilir
- Örneğin Buzzfeed, açık kaynak bir LLM’i fine-tune ederek maliyetleri %80 azalttığını paylaşmıştı

Strateji 2: Daha iyisine doğru yinelemek

Uzun vadede rekabet avantajını korumak için modelin ötesinde, ürünü farklılaştırabilecek unsurları düşünmek gerekir
Uygulama hızı önemlidir, ancak tek avantaj bu olmamalıdır

Model ürün değildir, ürün modeli çevreleyen sistemdir

Model inşa etmeyen ekipler için yeniliğin hızlı temposu bir nimettir
- Çünkü bağlam boyutu, akıl yürütme yeteneği ve fiyat/performans gibi iyileştirmeleri takip ederek en yeni modellere geçip daha iyi ürünler oluşturabilirler
- Bu ilerlemeler öngörülebilir olacak kadar heyecan vericidir
- Bütün bunlar birlikte düşünüldüğünde, model muhtemelen sistemde en az kalıcı bileşendir
Bunun yerine çabayı kalıcı değer sağlayabilecek kısımlara yoğunlaştırmak gerekir
- Evals: farklı modeller genelinde görev performansını güvenilir biçimde ölçmek için
- Guardrails: modelden bağımsız olarak istenmeyen çıktıları önlemek için
- Caching: modeli tamamen devre dışı bırakarak gecikmeyi ve maliyeti azaltmak için
- Data flywheel: yukarıdakilerin hepsinde yinelemeli iyileştirmeyi hızlandırmak için
- Bu bileşenler, ham model yeteneklerinden daha güçlü bir ürün kalitesi hendeği oluşturur
Ancak bu, uygulama katmanında bir şeyler inşa etmenin risksiz olduğu anlamına gelmez
- OpenAI veya diğer model sağlayıcılarının uygulanabilir kurumsal yazılımlar sunabilmesi için kaçınılmaz olarak çözeceği alanlarda yatırım yapmayın
Örneğin bazı ekipler, özel modellerden gelen yapılandırılmış çıktıları doğrulamak için özel araçlar geliştirmeye yatırım yaptı
- Burada asgari düzeyde yatırım önemlidir, ancak derin yatırım yapmak zamanı iyi kullanmak değildir
- OpenAI, function calling istendiğinde geçerli function calling çıktısı sağlamalıdır; çünkü bunu tüm müşteriler ister
- Burada “stratejik erteleme” uygulayın, mutlak gerekli olanı inşa edin ve sağlayıcının yeteneklerini genişletmesini bekleyin

Küçük başlayın ve güven kazanın

Herkes için her şey olmaya çalışan bir ürün yapmak, sıradanlığın reçetesidir
İkna edici bir ürün oluşturmak için şirketler, kullanıcıları geri getiren yapışkan deneyimler üretme konusunda uzmanlaşmalıdır
Kullanıcıların sorduğu her soruyu yanıtlamayı hedefleyen genel bir RAG sistemini düşünün
- Uzmanlaşma eksikliği, sistemin güncel bilgiye öncelik verememesi, alana özgü formatları ayrıştıramaması veya belirli görevlerin nüanslarını anlayamaması anlamına gelir
- Sonuç olarak kullanıcılar yüzeysel ve güvenilmez bir deneyim yaşar; ihtiyaçları karşılanmaz ve ürünü terk ederler
Bunu çözmek için belirli alanlara ve kullanım senaryolarına odaklanmak gerekir
- Genişlik yerine derinlik katarak kapsam daraltılmalıdır
- Böylece kullanıcıda karşılık bulan, alana özgü araçlar geliştirilebilir
Uzmanlaşma sayesinde sistemin yetenekleri ve sınırları dürüstçe anlatılabilir
- Sistemin ne yapabildiği ve ne yapamadığı konusunda şeffaf olmak, öz farkındalık gösterir; kullanıcıların en çok nerede değer katabileceklerini anlamalarına yardımcı olur ve sonuçta çıktılara duyulan güveni artırır

LLMOps kurun, ama doğru gerekçeyle: hızlı yineleme

DevOps temelde yeniden üretilebilir iş akışları, sola kaydırma ya da iki pizzalık ekiplere yetki vermek değildir. Hele hele YAML dosyaları yazmak hiç değildir
DevOps, hata yerine iyileştirmelerin birikmesini sağlamak için iş ile sonuçları arasındaki geri bildirim döngüsünü kısaltmaktır
- Kökleri, yalın girişim hareketi üzerinden yalın üretim ve Toyota Production System'a kadar uzanır; single-minute die exchange ve kaizen'i vurgular
MLOps, DevOps'un biçimini ML'e uyguladı
- Yeniden üretilebilir deneyler ve model geliştiricilerin dağıtım yapabilmesini sağlayan hepsi bir arada araç paketleri vardır. Bir sürü YAML dosyası da vardır
Ancak sektör olarak MLOps, DevOps'un işlevini benimsemedi. Model ile üretimdeki çıkarım ve etkileşimler arasındaki geri bildirim açığını azaltmadı
Neyse ki LLMOps alanı, prompt yönetimi gibi tali sorunlardan uzaklaşıp iterasyonu engelleyen zor sorunlara, yani üretim izleme ve değerlendirmeyle bağlantılı sürekli iyileştirmeye doğru yön değiştirdi
Zaten sohbet ve kodlama modelleri için tarafsız ve crowdsourced değerlendirme sağlayan konuşmalı arenalar var. Bu, kolektif ve yinelemeli iyileştirmenin dış döngüsüdür
- LangSmith, Log10, LangFuse, W&B Weave, HoneyHive gibi araçlar yalnızca üretimde sistem çıktılarıyla ilgili verileri toplama ve düzenleme değil, aynı zamanda bu sistemleri iyileştirmek için geliştirme süreçlerine derin entegrasyon da vaat ediyor. Bu araçları benimseyin ya da kendiniz geliştirin

Satın alabileceğiniz LLM özelliklerini yapmayın

Başarılı işlerin çoğu LLM işi değildir. Aynı zamanda çoğu işte LLM ile iyileştirme fırsatı vardır
Bu iki gözlem, liderleri sık sık yanlış yönlendirir; maliyeti artırıp kaliteyi düşürürken sistemleri alelacele LLM ile elden geçirip yapay ve gösteriş meraklısı "AI" özellikleri olarak piyasaya sürmelerine yol açar. Korkulan pırıltılı simge artık tamamlanmıştır
Daha iyi bir yol var: ürün hedefleriyle gerçekten uyumlu olan ve temel operasyonları güçlendiren LLM uygulamalarına odaklanın
Ekibin zamanını boşa harcayan bazı yanlış denemeleri ele alalım
- İşiniz için özel bir text-to-SQL özelliği geliştirmek
- Belgelerle sohbet edebilen bir chatbot geliştirmek
- Şirket bilgi tabanını müşteri destek chatbot'u ile entegre etmek
Bunlar LLM uygulamalarının hello world'ü olsa da, bir ürün şirketinin bunları bizzat geliştirmesi mantıklı değildir
- Çünkü bunlar birçok işte ortak olan genel problemlerdir; umut veren demolarla güvenilir bileşenler arasındaki fark büyüktür ve bu alan yazılım şirketlerinin alışıldık uzmanlık sahasıdır
- Y Combinator'ın mevcut batch'inde büyük ölçekte çözülmekte olan genel problemlere değerli Ar-Ge kaynakları yatırmak israftır
Bu size basmakalıp bir iş tavsiyesi gibi geliyorsa, bunun nedeni mevcut hype dalgasının coşkulu heyecanı içinde "LLM" diye bir şeyin ileri düzey ve farklılaştırıcı olduğunun kolayca sanılması ve aslında çoktan sıradanlaşmış uygulamaların gözden kaçırılmasıdır

AI'ı döngüye dahil edin, insanı merkeze koyun

Bugünün LLM tabanlı uygulamaları kırılgandır. Çok büyük miktarda güvenlik önlemi ve savunmacı mühendislik gerektirirler ama yine de öngörülmesi zordur. Üstelik kapsamları sıkı biçimde tanımlandığında son derece faydalı olabilirler. Bu da LLM'lerin kullanıcı iş akışını hızlandıran mükemmel araçlar olduğu anlamına gelir
LLM tabanlı uygulamaların iş akışını tamamen değiştirmesini ya da işlevlerin yerini almasını hayal etmek isteyebilirsiniz, ancak bugün en etkili paradigma insan-bilgisayar centaur'udur (Centaur chess)
- Yetkin bir insan, kendi hızlı kullanımına göre ayarlanmış LLM yetenekleriyle birleştiğinde, iş yapma verimliliği ve memnuniyeti büyük ölçüde artabilir
- LLM'lerin öne çıkan uygulamalarından biri olan GitHub CoPilot, bu iş akışının gücünü kanıtladı
  - "Genel olarak geliştiriciler, GitHub Copilot ve GitHub Copilot Chat kullandıklarında kod yazmanın daha kolay olduğunu ve ortaya çıkan kodun daha az hatalı, daha okunabilir, daha yeniden kullanılabilir, daha özlü, daha kolay bakım yapılabilir ve daha dayanıklı olduğunu hissettiklerini söyledi." - Mario Rodriguez, GitHub
Uzun süredir ML üzerinde çalışan kişiler "human-in-the-loop" fikrine hızla yönelebilir, ancak bu kadar acele etmeyin
- HITL machine learning, ML modelinin öngörüldüğü gibi çalışmasını sağlayan insan uzmanlara dayalı bir paradigmadır
- Burada önerilen şey bununla ilişkili olsa da daha inceliklidir. LLM tabanlı sistemler bugün çoğu iş akışının ana itici gücü olmamalı; yalnızca bir kaynak olmalıdır
İnsanı merkeze koyup LLM'nin iş akışını nasıl destekleyebileceğini sormak, ürün ve tasarım kararları üzerinde oldukça farklı etkiler yaratır
- Sonuçta, tüm sorumluluğu hızla LLM'lere devretmeye çalışan rakiplerden farklı bir ürün ortaya çıkarırsınız; yani daha iyi, daha faydalı ve daha az riskli bir ürün

Strateji 3. Prompting, Eval ve veri toplamayla başlamak

Önceki bölümde çok sayıda teknik ve tavsiye sunduk. Bu, sindirmesi zor bir miktar. Yararlı tavsiyelerin asgari kümesini ele alalım
- Ekip bir LLM ürünü yapmak istiyorsa, nereden başlamalı?
Son 1 yılda, başarılı LLM uygulamalarının tutarlı bir yörünge izlediğine bizi ikna edecek kadar çok örnek gördük. Bu bölümde bu temel "başlangıç" playbook'unu inceleyeceğiz
Temel fikir, basit başlayıp ihtiyaç oldukça karmaşıklık eklemektir
- Rule of Thumb: Her bir gelişmişlik seviyesi, genellikle bir önceki aşamaya göre en az bir büyüklük mertebesi daha fazla çaba gerektirir. Bunu akılda tutarak...

Öncelik 1: prompt engineering

İşe prompt engineering ile başlayın
- Daha önce taktikler bölümünde tartışılan tüm teknikleri kullanın
- Chain-of-thought, n-shot örnekler ve yapılandırılmış girdi/çıktı neredeyse her zaman iyi bir fikirdir
- Zayıf bir modelden performans sıkıştırmaya çalışmadan önce prototipi en yüksek performanslı modelle oluşturun
Yalnızca prompt engineering ile istenen performans düzeyine ulaşılamıyorsa fine-tuning düşünülmelidir
- Bu, proprietary model kullanımını engelleyen ve self-hosting gerektiren işlevsel olmayan gereksinimleriniz (ör. veri gizliliği, tam kontrol, maliyet) olduğunda daha sık ortaya çıkar
- Aynı gizlilik gereksinimlerinin, fine-tuning için kullanıcı verisinin kullanılmasını engellemediğinden emin olun

Değerlendirmeleri oluşturun ve veri flywheel'ini başlatın

Daha yeni başlayan ekiplerin bile değerlendirmelere (evals) ihtiyacı vardır. Aksi halde prompt engineering'in yeterli olup olmadığını ya da fine-tuned bir modelin temel modelin yerini almaya hazır olup olmadığını bilemezsiniz
Etkili değerlendirmeler göreve özeldir ve hedeflenen kullanım durumunu yansıtır
- Önerdiğimiz ilk seviye değerlendirme, unit test'tir
- Bu basit assertion'lar, bilinen veya varsayılan hata modlarını tespit etmeye ve ilk tasarım kararlarını vermeye yardımcı olur
- Sınıflandırma, özetleme vb. için diğer göreve özel değerlendirmelere de bakın
Unit test'ler ve model tabanlı değerlendirmeler faydalıdır, ancak insan değerlendirmesinin yerini tutmaz
- İnsanların modeli/ürünü kullanmasına ve geri bildirim vermesine imkân tanıyın
- Bu, gerçek performansı ve hata oranlarını ölçerken aynı zamanda gelecekte modeli fine-tuning için kullanılabilecek yüksek kaliteli açıklamalı veriler toplama gibi ikili bir amaca hizmet eder
- Bu, zamanla bileşik etki yaratan olumlu bir geri bildirim döngüsü ya da veri flywheel'i oluşturur
  - Model performansını değerlendirmek veya kusurları bulmak için insan değerlendirmesi
  - Açıklamalı verileri kullanarak modeli fine-tuning yapmak ya da prompt'ları güncellemek
  - Tekrarlayın
Örneğin, LLM tarafından üretilen özetlerdeki kusurları denetlerken, her cümle için olgusal tutarsızlık, ilgisizlik veya kötü üslup gibi ayrıntılı geri bildirim etiketleri atayabilirsiniz
- Sonrasında bu olgusal tutarsızlık açıklamalarını bir halüsinasyon sınıflandırıcısı eğitmek için ya da ilgililik açıklamalarını bir ilgililik ödül modeli eğitmek için kullanabilirsiniz
LinkedIn, halüsinasyon, sorumlu yapay zeka ihlalleri, tutarlılık vb. tahmin etmek için model tabanlı değerlendiricileri kullanarak başarı hikâyeleri paylaştı
Zamanla değeri artan varlıklar oluşturarak, değerlendirme (evals) oluşturmayı yalnızca bir operasyonel maliyetten stratejik bir yatırıma dönüştürün ve bu süreçte veri flywheel'ini kurun

Strateji 4. Düşük maliyetli bilişin yüksek seviyeli eğilimi (The high-level trend of low-cost cognition)

1971’de Xerox PARC araştırmacıları, bugün yaşadığımız ağlarla bağlı kişisel bilgisayarlar dünyasını öngörmüştü
- Bu geleceğin doğmasına, onu mümkün kılan teknolojilerin (Ethernet, grafik işleme, mouse, pencereler vb.) icadında merkezi bir rol oynayarak katkı sundular
Ayrıca basit bir alıştırma da yaptılar
- Çok faydalı olan (ör. video ekranı) ama henüz ekonomik olmayan uygulamalara baktılar (bir video ekranını çalıştıracak kadar RAM binlerce dolardı)
- Ardından ilgili teknolojinin tarihsel fiyat eğilimlerini (Moore yasasına benzer şekilde) inceleyip bu teknolojinin ne zaman ekonomik hale geleceğini tahmin ettiler
Aynı şeyi LLM teknolojisi için de yapabiliriz. Dolar başına transistör sayısı kadar düzenli olmasa da
- Uzun süredir kullanılan popüler bir benchmark (ör. Massively-Multitask Language Understanding veri seti) ve tutarlı bir girdi yaklaşımı (5-shot prompting) seçin
- Sonra zaman içinde, bu benchmark üzerinde farklı performans seviyelerine sahip dil modellerini çalıştırmanın maliyetini karşılaştırın
Sabit maliyet karşılığında yetenek hızla artıyor. Sabit bir yetenek seviyesi içinse maliyet hızla düşüyor
- OpenAI’nin davinci modeli API olarak sunulduğundan bu yana geçen 4 yılda, 1 milyon token (bu belgenin yaklaşık 100 kopyası) ölçeğinde o göreve denk performansa sahip bir modeli çalıştırmanın maliyeti 20 dolardan 10 centin altına düştü. Yarılanma süresi yalnızca 6 ay
- Benzer şekilde, Mayıs 2024 itibarıyla Meta’nın LLaMA 3 8B modelini API sağlayıcıları üzerinden ya da kendi başınıza çalıştırmanın maliyeti 1 milyon token başına sadece 20 cent ve ChatGPT’yi mümkün kılan model olan OpenAI’nin text-davinci-003 modeliyle benzer performans gösteriyor
- Aynı model, Kasım 2023 sonunda yayımlandığında bile 1 milyon token başına yaklaşık 20 dolara mal oluyordu. Sadece 18 ayda iki basamaklı fark oluştu. Bu, Moore yasasının öngördüğü basit iki kat artışla aynı zaman aralığı
Şimdi çok faydalı ama (Park et al’daki gibi üretken video oyunu karakterlerini çalıştırmak) henüz ekonomik olmayan (saatlik maliyetin 625 dolar olduğu tahmin ediliyor) LLM uygulamalarını düşünelim
- İlgili makalenin Ağustos 2023’te yayımlanmasından bu yana maliyet yaklaşık bir basamak düşerek saat başına 62,50 dolara indi
- 9 ay sonra bunun saat başına 6,25 dolara düşmesini bekleyebiliriz
Bu arada, Pac-Man 1980’de çıktığında, bugünün 1 dolarıyla birkaç dakika ya da birkaç on dakika oynayacak kredi satın alınabiliyordu. Buna saat başına 6 oyun ya da saat başına 6 dolar diyelim
- Bu kabataslak hesap, ilgi çekici LLM destekli oyun deneyimlerinin 2025 civarında ekonomik hale geleceğini gösteriyor
Bu eğilimler yeni ve yalnızca birkaç yıllık. Ancak önümüzdeki birkaç yılda bu sürecin yavaşlamasını beklemek için pek neden yok
- Parametre başına yaklaşık 20 tokenlık “Chinchilla oranı”nın ötesine ölçekleme gibi algoritma ve veri seti tarafındaki kolay kazanımlar tükense bile, veri merkezlerinin içinde ve silikon katmanında daha derin yenilikler ve yatırımlar bu boşluğu dolduracaktır
Ve bu muhtemelen en önemli stratejik gerçek
- Bugün tamamen uygulanamaz görünen bir fuar demosu ya da araştırma makalesi, birkaç yıl sonra premium bir özellik olacak ve kısa süre sonra da metalaşacak
- Sistemleri ve organizasyonları bunu akılda tutarak kurmalısınız

[0’dan 1’e giden demo artık yeterli. Şimdi 1’den N’e giden ürünü yapma zamanı]

LLM demosu yapmak gerçekten çok eğlenceli
Birkaç satır kod, bir vektör veritabanı ve özenle yazılmış prompt’larla “sihir” yaratıyorsunuz
Geçtiğimiz 1 yıl boyunca bu sihir internetle, akıllı telefonlarla, hatta matbaayla karşılaştırıldı
Ne yazık ki, gerçek yazılımı piyasaya sürme işi yapmış herkesin bildiği gibi, kontrollü bir ortamda çalışan bir demo ile büyük ölçekte güvenilir biçimde çalışan bir ürün arasında devasa bir fark var
Hayal etmesi ve demosunu yapması kolay ama ürüne dönüştürmesi çok zor olan pek çok problem var
- Örneğin otonom sürüş: Bir arabanın bir blok boyunca otonom gitmesini göstermek kolaydır, ama bunu ürüne dönüştürmek 10 yıl sürer - Andrej Karpathy
Otonom araçları örnek alalım
- 1988’de sinir ağlarıyla sürülen ilk otomobil ortaya çıktı
- 25 yıl sonra Andrej Karpathy, Waymo’da ilk demo sürüşünü yaptı
- Ondan 10 yıl sonra şirket sürücüsüz kullanım izni aldı
- Prototipten ticari ürüne geçişte 35 yıl boyunca sıkı mühendislik, test, iyileştirme ve regülasyon süreçlerinde yol alma gerekti
Son 1 yıldaki iniş çıkışları, sektör ve akademi genelinde gözlemledik: LLM uygulamaları için N yılın 1. yılı (Year 1 of N for LLM applications)
- Değerlendirme, prompt engineering, guardrail’ler gibi taktiklerden; operasyonel beceriler, ekip kurma ve hangi yeteneklerin şirket içinde geliştirileceğini seçme gibi stratejik bakış açılarına kadar, öğrendiğimiz derslerin 2. yılda ve sonrasında faydalı olmasını umuyoruz
- Bu heyecan verici yeni teknolojiyi birlikte ilerletmeyi dört gözle bekliyoruz

9 yorum

inthelife 2024-06-17

İçerik güzel olduğu için, dönüp dönüp bakmak üzere bunu bir Mindmap olarak hazırladım ^^;

https://drive.google.com/file/d/…

hheungsu 2024-06-15

Çok güzel bir yazı!! Baştan sona tekrar tekrar düşünüp değerlendirmeye değer pek çok faydalı nokta var. Böyle mücevher değerinde bir yazıyı çevirip paylaştığınız için teşekkür ederim!!

nutella 2024-06-12

Şu anda gerçekten çok yardımcı oluyor.

komanabi 2024-06-11

Megastudy bitti, şimdi sıra Omega-3'te!!!

ssifood 2024-06-11

Artık Skynet bitti, MegaStudy geliyor.

my0075425 2024-06-11

Artık insanlığın sonu geldi, Skynet geliyor!!

zihado 2024-06-10

Orijinal yazının yazarının kariyeri de ilgi çekiciydi
https://tr.news.hada.io/topic?id=1626

eungook 2024-06-11

Vay be.. gerçekten çok ilham verici.. paylaştığınız için teşekkürler

humblebee 2024-06-10

İçgörü ve deneyimin canlı bir şekilde hissedildiği harika bir yazı! Bana ve ekibime büyük fayda sağlayacağını düşünüyorum. Keyifle okudum. Teşekkürler ☺️