bilalabic/toolcall-tr-pilot

ToolCall-TR — Pilot v0.1

Türkçe, execution-verified tool-calling veri seti. Her tool çağrısı gerçek bir implementasyon tarafından çalıştırıldı ve çıktısı doğrulandı; hiçbir tool observation'ı bir LLM tarafından yazılmadı.

⚠️ Önce şunu bilin: bu küçük bir ilk sürüm

İçinde 200 örnek var. Bu sayı bir modeli eğitmek için yeterli değildir.

Ne için uygun:

• —Yöntemi ve veri biçimini incelemek
• —Örneklere tek tek bakmak
• —Az sayıda örnekle deneme yapmak (few-shot)
• —Kendi ölçüm setinizi kurmadan önce prototip çıkarmak

Ne için uygun değil:

• —Tek başına eğitim verisi olarak kullanmak
• —Model karşılaştırmak — 200 örnek güvenilir bir sonuç vermez

Hedef 10.000–15.000 örnektir; o sürüm henüz üretilmedi.

Neden 200'de duruldu

Daha büyük bir koşu yapıldı ve reddedildi. 1.000 örneklik üretim tamamlandı ama yalnızca 20 family'den türetildiği için ~50× parametre fan-out gerekti ve kompozisyon çöktü: %94,3 tool_call, 11 senaryo türünün 6'sı sıfır örnekle.

Kalite kapısı buna "geçti" dedi. Sebebi bütçenin kendisiydi: tool_call için minimum_ratio: 0.90 isteniyordu. Kapı doğru çalışıyordu, yanlış hedefe bakıyordu.

Bunun yerine 74 family'den üretilen 200 örnek yayımlanıyor — family başına ~2,7× fan-out. Darboğaz throughput değil family sayısıdır; aynı family'yi ağır fan-out'la çoğaltmak korpusu tek tipleştiriyor.

Veri seti içeriği

200 örnek · 74 family · 15 sağlayıcı · 35 tool · 0 reddedilen

Split

Split family düzeyinde ve fan-out'tan önce atanır; hash(family_id)'den türetilir ve paraphrase'ler ait oldukları family'nin split'ini miras alır. Aksi hâlde aynı görevin bir varyantı train'e, diğeri test'e düşer ve benchmark sessizce kirlenir. Sızıntı denetimi 0 ihlal verir.

Karar dağılımı

%28,5'i tool çağrısı içermez. Bu kasıtlıdır: bir tool-calling veri setinin en zor kısmı modelin ne zaman çağırmayacağını öğretmektir.

Senaryo türleri — 11'inin hepsi var

Diğer boyutlar

• —`interaction_type`: 170 single_turn, 30 `multi_turn`
• —Zorluk: 85 easy, 100 medium, 15 hard
• —Örnek başına tool: ortalama 2,6 — bir kısmı distractor'dır, model doğru tool'u seçmeyi öğrensin diye kasıtlı olarak gösterilir
• —Çağrı içeren örnekte ortalama çağrı: 1,41
• —State: 31 örnek initial_state_hash/final_state_hash taşır ve 17'sinde state fiilen değişir. Yani confirmation_required ve user_cancellation akışları anlatılmakla kalmıyor, gerçek bir durum makinesine karşı çalıştırılıp doğrulanıyor (mock_version: calendar_mock/1.0.0).

Execution class

Her örnek tool çıktısının nasıl elde edildiğini beyan eder:

Veri kaynakları ve lisanslar

Tek tip bir lisans iddia edilmiyor. ToolCall-TR tarafından yazılan kısım (Türkçe ifadeler, blueprint'ler, karar etiketleri, doğrulama annotation'ları) CC BY 4.0'tır. Tool observation'ları kaynağının koşullarını taşır ve her ToolSpec kendi source.license alanını içinde tutar.

"Yalnızca metadata" bir cümle değil, bir mekanizmadır. Normalizasyon alanları beyaz listeler; listede olmayan hiçbir alan veriye giremez. Wikipedia extracts ve REST summary CC BY-SA (viral) olduğu için alınmaz; GitHub'dan yalnızca repo istatistikleri alınır — description, README, issue/PR gövdeleri ve kullanıcı login'leri alınmaz. Bir test bunu zorlar, böylece upstream bir şema değişikliği lisanslı metni sessizce geri sokamaz.

Biçimler

İki datasets konfigürasyonu vardır:

canonical bizim biçimimizdir; diğer her şey ondan türetilmiş birer görünümdür ve canonical veriyi değiştirmez (her görünüm için round-trip testi vardır).

Sohbet şemasına sığmayan alanlar (split, family_id, provenance, execution_classes, final_response_source) her görünümde toolcall_tr yan alanında taşınır — hiçbir bilgi kaybolmaz.

Varsayılan biçim: hf_chat

Her mesajda content, images, name, role, thinking, tool_calls alanlarının tamamı bulunur; kullanılmayanlar None kalır. Alan kümesi sabit olduğu için datasets mesajları düzgün bir struct olarak çıkarır:

List({'content': string, 'images': null, 'name': string,
      'role': string, 'thinking': null,
      'tool_calls': List({'function': {'arguments': string, 'name': string},
                          'type': string})})

name yalnız tool mesajlarında doludur ama her mesajda bulunur. HF şemasında tool adı için ayrı bir alan yoktur ve parallel_tool_call örneklerinde hangi observation'ın hangi çağrıya ait olduğu aksi hâlde kaybolurdu. Alanı yalnız tool mesajlarına koymak alan kümesini bozuyor ve mesajları opak JSON'a düşürüyordu — ölçüldü ve düzeltildi.

İki alan bu sürümde her satırda None, dolayısıyla datasets onları null tipinde çıkarır:

• —`images` — veri seti multimodal değildir.
• —`thinking` — alan reasoning_summary_tr'den beslenir; bu korpus şablon üreticisiyle koşulduğu için özet üretilmemiştir. Doldurulduğunda içeriği kısa ve denetlenebilir bir karar özeti olur; ham düşünce zinciri hiçbir görünüme yazılmaz. Boşken uydurulmaz.

tools alanındaki JSON Schema properties alt alanı tool'dan tool'a değiştiği için datasets onu JSON olarak saklayıp okurken çözer; parametre kısıtları (minimum, maximum, default) kayıpsız korunur.

Yükleme

Varsayılan (hf_chat):

from datasets import load_dataset

ds = load_dataset("bilalabic/toolcall-tr-pilot")
print(ds["train"][0]["messages"][0]["content"])

Tüm alanların bulunduğu canonical biçim:

ds = load_dataset("bilalabic/toolcall-tr-pilot", "canonical")

Belirli bir eğitim görünümü için:

ds = load_dataset(
    "bilalabic/toolcall-tr-pilot",
    data_files="formats/openai_trajectory.jsonl",
    split="train",
)

Örnek

Kullanıcı:

2026-07-20 ile 2026-07-28 arasında Elazığ'ın 300 km çevresindeki 3 ve üzeri depremleri bul.

Ground-truth — iki adımlı zincir; ikinci çağrı birincinin observation'ına bağlı:

[
  {"name": "search_places",
   "arguments": {"query": "Elazığ", "limit": 5, "sort_by": "relevance",
                 "include_alternate_names": false}},
  {"name": "search_earthquakes",
   "arguments": {"latitude": 38.6743, "longitude": 39.2232, "radius_km": 300.0,
                 "minimum_magnitude": 3.0, "start_date": "2026-07-20",
                 "end_date": "2026-07-28", "limit": 20}}
]

Koordinat kullanıcı tarafından verilmedi; enlem/boylam birinci adımın gerçek çıktısından geldi (PRIOR_OBSERVATION).

Örnek 4 tool taşıyor — ikisi distractor. Türü empty_result: sonuç boş liste döndü, ve bu bir hata değil, o pencerede kayıt bulunmadığını söyleyen geçerli bir cevaptır.

Metodoloji

Üç faz — asla tek adımda birleşmez

Blueprint --[planner, SAF, I/O yok]--> CallPlan
CallPlan  --[runner, I/O, seed altında deterministik]--> Trace
Trace     --[validation, SAF]--> Example

Planner gerçek bir derleyicidir: tool/parametre varlığı, tip uyumu ve adımlar arası referansların geçerliliği ağ olmadan hard-fail eder. Validator'lar yalnızca kaydedilmiş Trace'i okur ve execution katmanını import edemez — etselerdi doğrulama sırasında yeniden çalıştırma kapısı açılır ve veri doğrulanabilir olmaktan çıkardı. Katman ihlali CI'da lint-imports ile patlar.

LLM'in rolü sınırlıdır

LLM yalnızca doğal Türkçe ifadeyi yazar. Ground-truth tool çağrıları koddan derlenir, gerçekten çalıştırılır ve bağımsız olarak doğrulanır.

Üretici model ölçülerek seçildi (gpt-4.1-mini): 104 çağrılık karşılaştırmada %100 kabul, %99,0 benzersiz, 0,144 n-gram benzerliği. Yalnızca kabul oranına bakılmadı — bir aday %100 kabul alırken ortalama 22 karakterlik çöp üretiyordu ve yapısal validator'ları geçiyordu.

Determinizm

Donmuş saat, sıradan bağımsız seed (sha256(blueprint_id + variant_index)), pinlenmiş sıralama ve cassette replay. Aynı girdi aynı trace_id'yi üretir.

Doğal dil validator'a uydurulmadı

Bu proje bir kez bunun tersini yaptı: grounding validator argümanın mesajda birebir geçmesini istediği için ifadelere UUID'ler ve ham koordinatlar yazıldı. Sonuç hiçbir insanın kurmayacağı cümlelerdi.

Bunun yerine argüman kaynağı kategorileri eklendi — USER_MESSAGE, USER_MESSAGE_DERIVED, SYSTEM_STATE, PRIOR_OBSERVATION, PINNED_FIXTURE — ve Türkçe gevşek eşleştirme yazıldı. Kullanıcı UUID yapıştırmaz, slug bilmez, koordinat okumaz.

Bilinen sınırlamalar

1. 1.Ölçek. 200 örnek tek başına eğitim için yetersizdir.
2. 2.Family başına düşük fan-out. 74 family'nin bazıları yalnızca 2 varyant taşır; family düzeyinde dengesizlik vardır.
3. 3.`calendar_mock` ve `general_local` baskın. Tool görünümlerinin ~%40'ı bu ikisinden; canlı sağlayıcı çeşitliliği hedeflenenin altında.
4. 4.Judge, üretici ile aynı sağlayıcıdan. Self-preference bias tam olarak elenmiş değildir; ideali farklı bir sağlayıcıdır.
5. 5.İnsan incelemesi tam örneklem değil. Kalite kapısı yapısaldır; yapısal validator'lar akıcılığı ölçmez.
6. 6.PII tarayıcısında yanlış pozitif. VKN checksum'ı zayıf olduğu için rastgele 10 haneli sayıların ~%10'u geçer; bu korpusta 12 bulgu üretti ve hepsi yanlış pozitiftir (GBIF occurrence ID'leri ve SHA-256 hash'lerinin içindeki hane dizileri). Gerçek TCKN/VKN/IBAN sayısı sıfırdır.
7. 7.Stateful kapsam dar. State doğrulaması yalnızca calendar_mock üzerindedir (31 örnek); diğer sağlayıcılar read-only olduğu için state_hash alanları null'dır.

Kişisel veri

Veri seti gerçek kişisel veri içermez. Sentetik kimlikler kanıtlanabilir şekilde geçersizdir: sentetik TCKN'ler 0 ile başlar (gerçek bir TCKN 0 ile başlayamaz), VKN'ler checksum-geçersiz, IBAN'lar mod-97-geçersizdir. Bu politika CI'da zorlanır.

Atıf

@misc{toolcall_tr_pilot_2026,
  title  = {ToolCall-TR: Execution-Verified Turkish Tool-Calling Dataset (Pilot v0.1)},
  author = {Abiç, Bilal},
  year   = {2026},
  url    = {https://huggingface.co/datasets/bilalabic/toolcall-tr-pilot}
}

Türetilmiş kaynaklara atıf yapılırken yukarıdaki sağlayıcı tablosu ve her örneğin toolcall_tr.provenance.sources alanı kullanılmalıdır.

Kaynak kod: https://github.com/BilalAbic/toolcall-tr (Apache-2.0)