Hızlı operasyonların yükselişi: Kötü girdilerden ve bağlam şişkinliğinden kaynaklanan gizli yapay zeka maliyetlerinin ele alınması

Bu makale, VentureBeat'in "Yapay Zekanın Gerçek Maliyeti: Ölçekte Performans, Verimlilik ve Yatırım Getirisi" adlı özel sayısının bir parçasıdır. Bu özel sayıdan daha fazlasını okuyun .

Model sağlayıcıları, daha uzun bağlam pencereleri ve gelişmiş muhakeme yeteneklerine sahip giderek daha karmaşık büyük dil modelleri (LLM) sunmaya devam ediyor.

Bu, modellerin daha fazla işlem yapmasını ve "düşünmesini" sağlar, ancak aynı zamanda hesaplamayı da artırır: Bir model ne kadar çok şey alıp verirse, o kadar fazla enerji harcar ve maliyetleri de o kadar yüksek olur.

Bunu, istemle ilgili tüm ince ayarlarla birleştirin; istenen sonuca ulaşmak için birkaç deneme gerekebilir ve bazen eldeki sorunun bir doktora öğrencisi gibi düşünebilen bir modele ihtiyacı olmayabilir; o zaman hesaplama harcamaları kontrolden çıkabilir.

Bu durum, yapay zekanın yeni doğduğu çağda yepyeni bir disiplin olan hızlı operasyonların ortaya çıkmasına neden oluyor.

IDC başkanı Crawford Del Prete, VentureBeat'e verdiği demeçte, "Hızlı mühendislik, yazma, gerçek yaratma gibi bir şeyken, hızlı operasyonlar, içeriği geliştirdiğiniz yayınlama gibidir," dedi. "İçerik canlıdır, içerik değişir ve bunu zaman içinde iyileştirdiğinizden emin olmak istersiniz."

Vector Institute'da uygulamalı bilim insanı olan David Emerson, LLM bağlamında hesaplama kullanımı ve maliyetin "ilgili ancak ayrı iki kavram" olduğunu açıkladı. Genellikle, kullanıcıların ödediği fiyat hem girdi belirteçlerinin sayısına (kullanıcının ne istediğine) hem de çıktı belirteçlerinin sayısına (modelin ne sunduğuna) göre ölçeklenir. Ancak, meta istemler, yönlendirme talimatları veya geri alma-artırılmış üretim (RAG) gibi perde arkası eylemler için değiştirilmezler.

Daha uzun bağlam, modellerin aynı anda çok daha fazla metni işlemesine izin verse de, bunun doğrudan önemli ölçüde daha fazla FLOPS'a (bir işlem gücü ölçüsü) dönüştüğünü açıkladı. Transformatör modellerinin bazı yönleri, iyi yönetilmezse giriş uzunluğuyla ikinci dereceden ölçeklenebilir. Gereksiz yere uzun yanıtlar ayrıca işlem süresini yavaşlatabilir ve yanıtları kullanıcıların umduğu cevaba dönüştürmek için algoritmalar oluşturmak ve sürdürmek için ek işlem ve maliyet gerektirebilir.

Emerson, tipik olarak, daha uzun bağlam ortamlarının sağlayıcıları kasıtlı olarak ayrıntılı yanıtlar vermeye teşvik ettiğini söyledi. Örneğin, birçok daha ağır muhakeme modeli (örneğin, OpenAI'dan o3 veya o1 ) genellikle basit sorulara bile uzun yanıtlar sağlayacak ve ağır bilgi işlem maliyetlerine yol açacaktır.

İşte bir örnek:

Giriş : Aşağıdaki matematik problemini cevaplayın. 2 elmam varsa ve 1'ini yedikten sonra marketten 4 tane daha alırsam, kaç tane elmam olur?

Çıktı : 1 tane yersem sadece 1 tane kalır. 4 tane daha alırsam 5 tane elmam olur.

Model yalnızca ihtiyaç duyduğundan daha fazla token üretmekle kalmadı, cevabını da gömdü. Daha sonra bir mühendis, nihai cevabı çıkarmak için programatik bir yol tasarlamak veya daha da fazla API maliyetine yol açan 'Nihai cevabınız nedir?' gibi takip soruları sormak zorunda kalabilir.

Alternatif olarak, istem, modeli anında bir cevap üretmeye yönlendirecek şekilde yeniden tasarlanabilir. Örneğin:

Giriş : Aşağıdaki matematik problemini cevaplayın. 2 elmam varsa ve 1'ini yedikten sonra marketten 4 tane daha alırsam, kaç elmam olur? Cevabınıza "Cevap şudur" ile başlayın…

Veya:

Giriş : Aşağıdaki matematik problemini cevaplayın. 2 elmam varsa ve 1'ini yedikten sonra marketten 4 tane daha alırsam, kaç elmam olur? Son cevabınızı kalın etiketlerle sarın .

Emerson, "Sorunun sorulma şekli, istenen cevaba ulaşma çabasını veya maliyetini azaltabilir" dedi. Ayrıca, az sayıda çekimlik istem (kullanıcının aradığı şeye dair birkaç örnek sağlama) gibi tekniklerin daha hızlı çıktılar üretmeye yardımcı olabileceğini belirtti.

Emerson, tehlikelerden birinin , düşünce zinciri (CoT) uyarımı (adım adım yanıt üretme) veya kendi kendini iyileştirme gibi karmaşık tekniklerin ne zaman kullanılacağını bilmemek olduğunu, çünkü bunların doğrudan modellerin çok sayıda belirteç üretmesini veya yanıt üretirken birkaç yinelemeden geçmesini teşvik ettiğini belirtti.

Her sorgu, bir cevap sağlamadan önce analiz edilecek ve yeniden analiz edilecek bir model gerektirmez, diye vurguladı; doğrudan yanıt vermeleri istendiğinde doğru şekilde yanıt verme konusunda mükemmel bir yeteneğe sahip olabilirler. Ek olarak, yanlış istem API yapılandırmaları (yüksek bir akıl yürütme çabası gerektiren OpenAI o3 gibi) daha düşük çaba gerektiren, daha ucuz bir istek yeterli olduğunda daha yüksek maliyetlere yol açacaktır.

"Daha uzun bağlamlarda, kullanıcılar mümkün olduğunca çok metni bir model bağlamına dökerek modelin bir görevi daha doğru bir şekilde gerçekleştirmesine yardımcı olma umuduyla 'mutfak lavabosu hariç her şey' yaklaşımını kullanmaya da meyilli olabilirler," dedi Emerson. "Daha fazla bağlam, modellerin görevleri gerçekleştirmesine yardımcı olabilirken, her zaman en iyi veya en etkili yaklaşım değildir."

Yapay zekaya uygun altyapıya ulaşmanın günümüzde zor olduğu büyük bir sır değil; IDC'den Del Prete, işletmelerin GPU boşta kalma süresini en aza indirebilmeleri ve GPU istekleri arasındaki boş döngülere daha fazla sorgu doldurabilmeleri gerektiğini belirtti.

"Bu çok, çok değerli emtialardan nasıl daha fazlasını elde edebilirim?" diye belirtti. "Çünkü sistem kullanımımı artırmam gerekiyor, çünkü soruna daha fazla kapasite atmanın avantajına sahip değilim."

İstem operasyonları, nihayetinde istemin yaşam döngüsünü yönettiği için bu zorluğun üstesinden gelmek için uzun bir yol kat edebilir. İstem mühendisliği istemin kalitesiyle ilgiliyken, istem operasyonları tekrar ettiğiniz yerdir, diye açıkladı Del Prete.

"Bu daha çok orkestrasyon," dedi. "Bunu, soruların düzenlenmesi ve yapay zekayla nasıl etkileşim kuracağınızın düzenlenmesi olarak düşünüyorum, böylece bundan en iyi şekilde yararlandığınızdan emin oluyorsunuz."

Modeller, çıktı kalitesinin düştüğü döngülerde dönerek "yorgunlaşmaya" meyilli olabilir, dedi. İstem operasyonları, istemleri yönetmeye, ölçmeye, izlemeye ve ayarlamaya yardımcı olur. "Bence bundan üç veya dört yıl sonra geriye baktığımızda, bunun bütün bir disiplin olacağını düşünüyorum. Bir beceri olacak."

Hala çok yeni bir alan olsa da, erken sağlayıcılar arasında QueryPal, Promptable, Rebuff ve TrueLens yer alıyor. İstem operasyonları geliştikçe, bu platformlar yinelemeye, iyileştirmeye ve kullanıcılara zaman içinde istemleri ayarlamaları için daha fazla kapasite sağlamak amacıyla gerçek zamanlı geri bildirim sağlamaya devam edecek, diye belirtti Dep Prete.

Sonunda, ajanların kendi başlarına komutları ayarlayabileceklerini, yazabileceklerini ve yapılandırabileceklerini öngördü. "Otomasyon seviyesi artacak, insan etkileşimi seviyesi azalacak, ajanların oluşturdukları komutlarda daha özerk bir şekilde çalışmasını sağlayabileceksiniz."

Prompt ops tam olarak gerçekleştirilinceye kadar, nihai olarak mükemmel bir prompt yoktur. Emerson'a göre insanların yaptığı en büyük hatalardan bazıları:

• Çözülecek sorun hakkında yeterince spesifik olmamak. Bu, kullanıcının modelin cevabını nasıl vermesini istediği, yanıt verirken nelerin dikkate alınması gerektiği, hesaba katılması gereken kısıtlamalar ve diğer faktörleri içerir. Emerson, "Birçok ortamda, modellerin kullanıcıların beklentilerini karşılayan bir yanıt sağlamak için iyi miktarda bağlama ihtiyacı vardır" dedi.
• Bir sorunun yanıt kapsamını daraltmak için basitleştirilme yollarını hesaba katmamak. Cevap belirli bir aralıkta mı olmalı (0 ila 100)? Cevap açık uçlu bir şey yerine çoktan seçmeli bir problem olarak mı ifade edilmeli? Kullanıcı sorguyu bağlamlandırmak için iyi örnekler sağlayabilir mi? Sorun ayrı ve daha basit sorgular için adımlara bölünebilir mi?
• Yapıdan faydalanmamak. LLM'ler desen tanıma konusunda çok iyidir ve birçoğu kodu anlayabilir. Madde işaretleri, maddeler halinde listeler veya kalın göstergeler (****) kullanmak insan gözüne "biraz karmaşık" görünse de, Emerson bu çağrıların bir LLM için faydalı olabileceğini belirtti. Yapılandırılmış çıktılar (JSON veya Markdown gibi) istemek, kullanıcılar yanıtları otomatik olarak işlemek istediklerinde de yardımcı olabilir.

Emerson, mühendislik en iyi uygulamalarına dayalı olarak bir üretim hattını sürdürürken dikkate alınması gereken birçok başka faktör olduğunu belirtti. Bunlar şunları içerir:

• Boru hattının veriminin tutarlı kalmasını sağlamak;
• İstemlerin performansının zaman içinde izlenmesi (potansiyel olarak bir doğrulama kümesine karşı);
• Boru hattı sorunlarını belirlemek için testler ve erken uyarı tespiti kurulması.

Kullanıcılar ayrıca istem sürecini desteklemek için tasarlanmış araçlardan da yararlanabilirler. Örneğin, açık kaynaklı DSPy, birkaç etiketli örneğe dayanarak alt akış görevleri için istemleri otomatik olarak yapılandırabilir ve optimize edebilir. Bu oldukça karmaşık bir örnek olsa da, istem tasarımında yardımcı olabilecek birçok başka teklif (ChatGPT, Google ve diğerleri gibi araçlara yerleşik olanlar dahil) vardır.

Ve son olarak Emerson, "Kullanıcıların yapabileceği en basit şeylerden birinin, etkili yönlendirme yaklaşımları, model geliştirmeleri ve modelleri yapılandırmanın ve onlarla etkileşim kurmanın yeni yolları konusunda güncel kalmaya çalışmak olduğunu düşünüyorum." dedi.