* Custom Chat Template
Bu depoda, dil modellerinin dış veri kaynaklarıyla haberleşmesini ve karmaşık "Agentic" işlemleri yapabilmesini sağlayan özel bir Jinja2 Chat Template yaptım.
Çıkış noktam, ders kapsamında incelenmesi için verilen Gemma 3 tabanlı örnek şablondu. Ancak o şablon daha çok standart sohbetler için tasarlandığından, modeli bir "Ajan" olarak kullanmak istediğimizde bazı yapısal tıkanıklıklar yaşatıyordu. Ben de o şablonun multimodal ve düşünce gizleme gibi özelliklerini koruyarak, üstüne kendi yazdığım Tool Calling motorunu entegre ettim.
* Örnek Şablondan Farklı Olarak Neleri Değiştirdim?
Örnek şablonu alıp doğrudan kullanmak yerine, sistemin daha güvenli ve esnek çalışması için şu 5 değişikliği yaptım:
- Sıra Kontrolü:
Örnek şablonda
Conversation roles must alternate user/assistant... şeklinde, konuşmanın illa bir kullanıcı bir yapay zeka şeklinde gitmesini zorunlu kılan katı bir kural vardı. Ancak Tool Calling yaparken asistan aracı çağırır, tool cevap verir, asistan tekrar konuşur (Sıra bozulur). Bu döngünün çökmemesi için o katı sıra kuralını tamamen kaldırdım.
- Available Tools Motoru:
Model, hangi araçları kullanabileceğini gaipten bilemez. Bu yüzden kodun en başına bir kontrol ekledim. Eğer sisteme
tools parametresi gönderirsek, şablonum bunu otomatik algılayıp system promptunun en başına [AVAILABLE TOOLS] etiketiyle, JSON formatında şık bir şekilde enjekte ediyor.
- String Birleştirme (
~) ve JSON Güvenliği:
Jinja2'de değişkenleri + operatörü ile birleştirmek, özellikle API'lerden dönen farklı veri tiplerinde (dict vs. string) çökmelere yol açar. Kodun tamamındaki riskli + işaretlerini Jinja'nın güvenli birleştirme operatörü olan ~ ile değiştirdim. Ayrıca modelin araç argümanlarını doğrudan dictionary olarak atma ihtimaline karşı mapping kontrolü ve tojson filtresi ekledim.
- Araç Yanıtlarını Özel Olarak Ayarladım:
Dışarıdan gelen verileri (örneğin hava durumu veya API sonucu) modelin standart bir metin gibi okuyup kafasının karışmasını engellemek istedim. Bu yüzden
role == "tool" olan mesajları <tool_response> ... </tool_response> etiketleri içine alarak modelin bu veriyi net bir şekilde idrak etmesini sağladım.
- Exceptions:
Eğer modele string veya iterable dışında bilinmeyen bir format gelirse, sistemin bunu sessizce yutup hatayı saklamasını istemedim. Orijinal koddan çıkarılan
raise_exception("Invalid content type") bloklarını geri ekleyerek hata ayıklamayı çok daha güvenli hale getirdim.
* Nasıl Çalışıyor?
Bu şablon sayesinde modelimiz şu döngüyü kusursuz işletiyor:
- Önce sistemde hangi araçların olduğunu (
[AVAILABLE TOOLS]) okuyor.
- Kullanıcıdan gelen isteğe göre karar verip
<tool_calls> etiketi açıyor ve JSON formatında ilgili fonksiyonu çağırıyor.
- Bizim uygulamamızdan dönen yanıtı
<tool_response> içinde alıp analiz ediyor.
- Son olarak kullanıcıya en doğru ve güncel nihai cevabını üretiyor.
Vakit ayırıp incelediğiniz için teşekkürler!
