Geliştirici Araçları'nı tasarlama: Yapay zeka yardımında verimli jeton kullanımı

Alina Varkki

Yayınlanma tarihi: 30 Ocak 2026

Performans için yapay zeka desteği geliştirilirken karşılaşılan temel mühendislik sorunu, Gemini'ın DevTools'da kaydedilen performans izleriyle sorunsuz bir şekilde çalışmasını sağlamaktı.

Büyük dil modelleri (LLM'ler), aynı anda işleyebilecekleri bilgi miktarını kesin olarak sınırlayan bir "bağlam penceresi" içinde çalışır. Bu kapasite, jeton cinsinden ölçülür. Gemini modellerinde bir jeton yaklaşık dört karakterden oluşan bir gruptur.

Performans izleri, genellikle birkaç megabayttan oluşan büyük JSON dosyalarıdır. Ham izleme göndermek, modelin bağlam penceresini anında tüketir ve sorularınız için yer bırakmaz.

Performans için yapay zeka yardımını mümkün kılmak amacıyla, minimum jeton kullanımıyla bir LLM için faydalı veri miktarını en üst düzeye çıkaran bir sistem tasarlamamız gerekiyordu. Bu blogda, bu amaçla kullandığımız teknikler hakkında bilgi edinebilir ve bunları kendi projelerinizde uygulayabilirsiniz.

İlk bağlamı özelleştirme

Bir web sitesinin performansında hata ayıklamak karmaşık bir görevdir. Geliştiriciler, bağlam için tam izlemeye bakabilir, Temel Web Verileri ve izlemenin ilgili zaman aralıklarına odaklanabilir, hatta ayrıntılara inerek tıklamalar veya kaydırmalar gibi tek tek etkinliklere ve bunlarla ilişkili çağrı yığınlarına odaklanabilir.

Hata ayıklama sürecine yardımcı olmak için DevTools'un yapay zeka yardımının bu geliştirici yolculuklarıyla eşleşmesi ve yalnızca geliştiricinin odak noktasına özel tavsiyeler vermek için ilgili verilerle çalışması gerekir. Bu nedenle, her zaman tam izleme göndermek yerine, verileri hata ayıklama görevinize göre dilimlemek için yapay zeka destekli bir özellik geliştirdik:

İzleme özeti, yapay zeka yardımının temel modeli olan Gemini'a ilk bağlamı sağlamak için neredeyse her zaman gönderilir. Yapay zekayla üretilen ek açıklamalar için bu bilgi atlanır.

Yapay zekaya araçlar verme

Geliştirici Araçları'ndaki yapay zeka desteği, bir aracı olarak işlev görür. Bu sayede, geliştiricinin ilk istemine ve kendisiyle paylaşılan ilk bağlama göre daha fazla veri için bağımsız olarak sorgu oluşturabilir. Daha fazla veri sorgulamak için yapay zeka yardımına, çağırabileceği bir dizi önceden tanımlanmış işlev verdik. İşlev Çağrısı veya Araç Kullanımı olarak bilinen bir kalıp.

Daha önce belirtilen hata ayıklama yolculuklarına dayanarak, aracı için bir dizi ayrıntılı işlev tanımladık. Bu işlevler, ilk bağlama göre önemli kabul edilen ayrıntıları inceler. Bu, bir insan geliştiricinin performans hata ayıklamasına yaklaşımına benzer. İşlevler şunlardır:

Veri alımını bu işlev çağrılarıyla sınırlayarak yalnızca alakalı bilgilerin bağlam penceresine iyi tanımlanmış bir biçimde girmesini ve jeton kullanımının optimize edilmesini sağlarız.

Aracı işlemi örneği

Yapay zeka yardımının daha fazla bilgi almak için işlev çağırmayı nasıl kullandığına dair pratik bir örneğe bakalım. "Bu istek neden yavaş?" şeklinde bir ilk istemden sonra, Yapay zeka asistanı, aşağıdaki işlevleri artımlı olarak çağırabilir:

1. getEventByKey: Kullanıcı tarafından seçilen belirli isteğin ayrıntılı zamanlama dökümünü (TTFB, indirme süresi) getirin.
2. getMainThreadTrackSummary: İstek başlatılması gerektiğinde ana iş parçacığının meşgul (engellenmiş) olup olmadığını kontrol edin.
3. getNetworkTrackSummary: Diğer kaynakların aynı anda bant genişliği için rekabet edip etmediğini analiz edin.
4. getInsightDetails: İzleme Özetinde, bu istekle ilgili bir performans sorunu olarak bir analizden bahsedilip bahsedilmediğini kontrol edin.

Yapay zeka yardımı, bu çağrıların sonuçlarını birleştirerek teşhis sağlayabilir ve getFunctionCode kullanarak kod iyileştirmeleri önerme veya getResourceContent temelinde kaynak yüklemeyi optimize etme gibi uygulanabilir adımlar önerebilir.

Ancak ilgili verilerin alınması, zorluğun yalnızca yarısıdır. Ayrıntılı veriler sağlayan işlevler olsa bile bu işlevler tarafından döndürülen veriler büyük boyutlu olabilir. Başka bir örnek verecek olursak getDetailedCallTree, yüzlerce düğüm içeren bir ağaç döndürebilir. Standart JSON'da bu, yalnızca iç içe yerleştirme için birçok { ve } olurdu.

Bu nedenle, jeton açısından verimli olacak kadar yoğun ancak LLM'nin anlayıp referans verebileceği kadar da yapılandırılmış bir biçime ihtiyaç vardır.

Verileri serileştirme

Bu zorluğun üstesinden nasıl geldiğimizi daha ayrıntılı bir şekilde inceleyelim. Performans izlemesindeki verilerin büyük bir bölümünü arama ağaçları oluşturduğundan, arama ağacı örneğiyle devam edeceğiz. Referans olarak, aşağıdaki örneklerde bir çağrı yığınındaki tek bir görev JSON biçiminde gösterilmektedir:

{
  "id": 2,
  "name": "animate",
  "selected": true,
  "duration": 150,
  "selfTime": 20,
  "children": [3, 5, 6, 7, 10, 11, 12]
}

Aşağıdaki ekran görüntüsünde gösterildiği gibi, bir performans izi binlerce etkinlik içerebilir. Her küçük renkli kutu bu nesne yapısı kullanılarak gösterilir.

Bu biçim, DevTools'ta programatik olarak çalışmak için uygundur ancak aşağıdaki nedenlerden dolayı LLM'ler için gereksizdir:

1. Gereksiz anahtarlar: "duration", "selfTime" ve "children" gibi dizeler, çağrı ağacındaki her bir düğüm için tekrarlanır. Bu nedenle, bir modele gönderilen 500 düğümlü bir ağaç, bu anahtarların her biri için 500 kez jeton kullanır.
2. Ayrıntılı listeler: children aracılığıyla her alt kimliği ayrı ayrı listelemek, özellikle çok sayıda sonraki etkinliği tetikleyen görevlerde çok sayıda jeton tüketir.

Performans için yapay zeka destekli tüm verilerde jeton açısından verimli bir biçimin uygulanması adım adım gerçekleştirilen bir süreçti.

İlk yineleme

Performans için yapay zeka yardımı üzerinde çalışmaya başladığımızda kargo hızını optimize etmiştik. Jeton optimizasyonuyla ilgili yaklaşımımız basitti. Orijinal JSON'daki küme parantezlerini ve virgülleri kaldırdık. Bu da aşağıdaki gibi bir biçimle sonuçlandı:

allUrls = [...]

Node: 1 - update
Selected: false
Duration: 200
Self Time: 50
Children:
   2 - animate

Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children:
   3 - calculatePosition
   5 - applyStyles
   6 - applyStyles
   7 - calculateLayout
   10 - applyStyles
   11 - applyStyles
   12 - applyStyles

Node: 3 - calculatePosition
Selected: false
Duration: 15
Self Time: 2
URL: 0
Children:
   4 - getBoundingClientRect

...

Ancak bu ilk sürüm, ham JSON'a kıyasla yalnızca küçük bir gelişme sunuyordu. Yine de kimlikleri ve adları olan alt düğümleri açıkça listeliyor ve her satırın önüne açıklayıcı, tekrarlanan anahtarlar (Node:, Selected:, Duration:, …) ekliyordu.

Alt düğüm listelerini optimize etme

Daha fazla optimizasyon için bir sonraki adım olarak düğüm alt öğelerinin adlarını kaldırdık (calculatePosition, applyStyles, … önceki örnekte). Yapay zeka yardımcısı, işlev çağrısı aracılığıyla tüm düğümlere erişebildiğinden ve bu bilgiler zaten düğüm başlığında (Node: 3 - calculatePosition) yer aldığından bu bilgilerin tekrar edilmesi gerekmez. Bu sayede Children öğesini basit bir tam sayı listesine dönüştürebildik:

Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children: 3, 5, 6, 7, 10, 11, 12

..

Bu, önceki duruma kıyasla önemli bir iyileşme olsa da optimizasyon için hâlâ yer vardı. Önceki örneğe baktığınızda Children öğesinin neredeyse sıralı olduğunu, yalnızca 4, 8 ve 9 öğelerinin eksik olduğunu fark edebilirsiniz.

Bunun nedeni, ilk denememizde performans izinden ağaç verilerini serileştirmek için Derinlik Öncelikli Arama (DFS) algoritmasını kullanmamızdır. Bu durum, kardeş düğümler için sıralı olmayan kimliklere yol açtı ve her kimliği ayrı ayrı listelememizi gerektirdi.

Ağacı genişlik öncelikli arama (BFS) kullanarak yeniden indekslersek bunun yerine sıralı kimlikler elde edeceğimizi ve başka bir optimizasyonun mümkün olacağını fark ettik. Artık tek tek kimlikleri listelemek yerine, orijinal örnekteki gibi 3-9 ile yüzlerce çocuğu tek bir kompakt aralıkta temsil edebiliyoruz.

Optimize edilmiş Children listesiyle birlikte nihai düğüm gösterimi şu şekilde görünür:

allUrls = [...]

Node: 2 - animate
Selected: true
Duration: 150
Self Time: 20
URL: 0
Children: 3-9

Anahtar sayısını azaltma

Optimize edilmiş düğüm listeleriyle yedekli anahtarlara geçtik. Önce önceki biçimdeki tüm anahtarları kaldırdık. Sonuç olarak aşağıdaki biçim elde edildi:

allUrls = [...]

2;animate;150;20;0;3-10

Token açısından verimli olsa da Gemini'a bu verileri nasıl anlayacağıyla ilgili talimatlar vermemiz gerekiyordu. Bu nedenle, Gemini'a ilk kez arama ağacı gönderdiğimizde aşağıdaki istemi ekledik:

...
Each call frame is presented in the following format:

'id;name;duration;selfTime;urlIndex;childRange;[S]'

Key definitions:

*   id: A unique numerical identifier for the call frame.
*   name: A concise string describing the call frame (e.g., 'Evaluate Script', 'render', 'fetchData').
*   duration: The total execution time of the call frame, including its children.
*   selfTime: The time spent directly within the call frame, excluding its children's execution.
*   urlIndex: Index referencing the "All URLs" list. Empty if no specific script URL is associated.
*   childRange: Specifies the direct children of this node using their IDs. If empty ('' or 'S' at the end), the node has no children. If a single number (e.g., '4'), the node has one child with that ID. If in the format 'firstId-lastId' (e.g., '4-5'), it indicates a consecutive range of child IDs from 'firstId' to 'lastId', inclusive.
*   S: **Optional marker.** The letter 'S' appears at the end of the line **only** for the single call frame selected by the user.

....

Bu biçim açıklaması jeton maliyetine neden olsa da bu maliyet, tüm görüşme için bir kez ödenen statik bir maliyettir. Maliyet, önceki optimizasyonlar sayesinde elde edilen tasarruflardan daha düşüktür.

Sonuç

Yapay zeka ile geliştirme yaparken jeton kullanımını optimize etmek önemli bir husustur. Ham JSON'dan özel bir biçime geçerek, ağaçları genişlik öncelikli arama ile yeniden indeksleyerek ve verileri isteğe bağlı olarak getirmek için araç çağrılarını kullanarak Chrome Geliştirici Araçları'ndaki yapay zeka yardımının kullandığı jeton miktarını önemli ölçüde azalttık.

Bu optimizasyonlar, performans izleri için yapay zeka yardımının etkinleştirilmesi için ön koşuldu. Aksi takdirde, sınırlı bağlam penceresi nedeniyle verilerin hacmini yönetemeyebilir. Ancak optimize edilmiş biçim, daha uzun bir sohbet geçmişini koruyabilen ve gürültüden etkilenmeden daha doğru, bağlama duyarlı yanıtlar verebilen bir performans aracısı sağlar.

Bu tekniklerin, yapay zeka için tasarım yaparken kendi veri yapılarınızı tekrar gözden geçirmeniz konusunda size ilham vereceğini umuyoruz. Web uygulamalarında yapay zekayı kullanmaya başlamak için web.dev'de Yapay Zeka'yı öğrenin başlıklı makaleyi inceleyin.