GPT-6.1 Sol Eğitimi: Bir Yapay Zekâ Olay Önceliklendirme Aracısı Oluşturun

OpenAI'nin yeni GPT-6.1 Sol modeli, Astra'nın maliyetinin çok daha küçük bir kısmına gelişmiş akıl yürütme, kod yazma ve araç kullanma yetenekleri getiriyor. 

Bu da onu, birden çok adım atması, araçlar çalıştırması ve büyük miktarda bilgi üzerinde akıl yürütmesi gereken yapay zekâ aracılar için özellikle faydalı kılıyor; hem de fatura şişmeden.

Olay müdahalesi bunun mükemmel bir örneği. 

Mühendisler çoğu zaman günlükleri incelemek, yapılandırmaları karşılaştırmak, betikler çalıştırmak ve kanıtları ilişkilendirerek sorunun kök nedenini bulmak için saatler harcar. Yetkin bir yapay zekâ aracısı ile bu işin büyük bir kısmı birkaç dakikada otomatikleştirilebilir.

Bu GPT-6.1 Sol eğitiminde, Agents API kullanarak bir yapay zekâ olay önceliklendirme aracısı oluşturacağız. 

Beş sentetik olay dosyası sağlayacak ve bir OpenAI barındırılan sandbox ortamını kullanarak bunları inceleyecek, analiz betikleri çalıştıracak, bulguları doğrulayacak ve olay raporu ile yapılandırılmış bir karar dahil altı indirilebilir çıktı üreteceğiz.

Hedef yalnızca olası bir kök nedeni tespit etmek değil. Kanıt ile varsayımı ayırt eden, bilinmeye devam edenleri açıklayan ve bir mühendis tarafından incelenebilecek ya da izleme ve uyarı sistemlerine entegre edilebilecek sonuçlar üreten bir aracı oluşturmak.

GPT-6.1 Sol Neden Yapay Zekâ Aracıları İçin Daha Uygun Maliyetli?

GPT-6.1 Sol, karmaşık kodlama, akıl yürütme ve araç kullanımı için Astra'ya yakın performansı belirgin derecede daha düşük bir fiyata sunuyor. 

Fark, özellikle tekrarlayan model çağrıları yapan çok turlu aracılar için önem kazanıyor.

Daha düşük maliyetle performans

GPT-6.1 Sol'un en büyük avantajlarından biri fiyatlandırmasıdır.

Karmaşık aracı görevlerinde Astra'ya yakın performansı çok daha düşük maliyetle sunar; bu da birden fazla model çağrısı içeren iş akışları için onu özellikle cazip kılar.

İşte standart API oranlarında milyon başına token bazında iki modelin karşılaştırması.

Sol, girdi ve çıktı token'larında 5 kat, önbelleğe alınmış girdide 10 kat daha ucuzdur. 

Önbellekleme, sistem talimatları, proje dosyaları ve konuşma geçmişini tekrar tekrar kullanan aracılar için özellikle yararlıdır.

Kaynak: Introducing GPT-6.1 Sol | OpenAI 

DeepSWE kıyaslaması bu maliyet-performans üstünlüğünü gösteriyor. 

GPT-6.1 Sol, görev başına belirgin şekilde daha düşük maliyetle Astra'ya benzer skorlar elde ediyor. 

Çok turlu aracılardaki gizli maliyet

Tek bir aracı çalıştırması, aracı günlükleri okurken, kod yazarken, araçlar çalıştırırken ve sonuçları kontrol ederken düzinelerce model çağrısı içerebilir. 

Astra gibi pahalı bir modelle, karmaşık bir çalıştırma yalnızca model maliyetlerinde bile kolayca 20 $'ı aşabilir.

Sol bu gideri önemli ölçüde azaltır, ancak daha düşük token fiyatları tek başına yeterli değildir. 

Daha akıllı araçlara, verimli bağlam yönetimine ve gereksiz model çağrılarının azaltılmasına da ihtiyacımız var. 

Bu fiyat düzeyinde, Sol bile her görev için mutlaka en maliyet-etkin çözüm olmayabilir.

Neden Agents API'yi kullanıyoruz?

Bu projede, Agents API'yi OpenAI barındırılan bir sandbox ile kullanıyoruz. 

Oturumları, orkestrasyonu, bağlam yönetimini ve kurtarmayı ele alır; böylece her model çağrısını elle yönetmek yerine yapay zekâ olay müdahale aracımızı oluşturmaya odaklanabiliriz.

Responses API'nin aksine, aracı döngüsünü ve araç çalıştırmayı kendimiz yönetmemiz gerekmez; Agents API çok adımlı iş akışları için yönetilen bir ortam sağlar. 

Aracımız, olay günlüklerini inceleyebilir, Python betikleri yazıp çalıştırabilir, olası kök nedenleri belirleyebilir ve her adımı biz orkestre etmeden bir olay raporu üretebilir.

Barındırılan sandbox ayrıca aracıya komutları çalıştırmak, dosyaları analiz etmek ve çıktıları kaydetmek için yalıtılmış bir ortam sunar. 

Bu, daha az altyapı ve orkestrasyon koduyla eksiksiz bir aracı iş akışı oluşturmayı ve test etmeyi kolaylaştırır.

GPT-6.1 Sol Örnek Proje: Yapay Zekâ Olay Önceliklendirme Aracısı Nasıl Kurulur

1. Olay dosyalarını yükleyin ve ön izleme yapın

Önce, yapay zekâ aracımızın inceleyeceği kanıtları toplamamız gerekiyor. 

Dosya adlarını kodlamak yerine, input/ dizinini uygulama günlükleri, yapılandırma dosyaları, dağıtım ayarları ve Python betikleri için otomatik olarak tarayacağız.

Ayrıca her bir .log ve .txt dosyasının ilk 400 karakterini ön izleyerek incelemeye başlamadan önce bariz hataları tespit edeceğiz.

import base64
import json
import os
from pathlib import Path

from openai import OpenAI

ROOT = Path.cwd().resolve()
INPUT_DIR = ROOT / "input"

input_paths = sorted(
    path for path in INPUT_DIR.iterdir() if path.is_file()
)
assert input_paths, f"Put at least one file in {INPUT_DIR}"

for path in input_paths:
    print(f"{path.name} ({path.stat().st_size} bytes)")
    if path.suffix.lower() in {".log", ".txt"}:
        print(path.read_text(encoding="utf-8", errors="replace")[:400])

Çıktı:

app.log (197 bytes)
2026-09-30 10:02:11 INFO Starting API
2026-09-30 10:02:14 ERROR Database connection failed
2026-09-30 10:02:14 ERROR Connection refused: 127.0.0.1:5433
2026-09-30 10:02:15 ERROR GET /api/users 500

config.yaml (41 bytes)
deployment.yaml (41 bytes)
reproduce.py (1515 bytes)
service.py (855 bytes)

Potansiyel bir sorun şimdiden göze çarpıyor: uygulama 5433 portundan veritabanına bağlanamıyor; hemen ardından bir HTTP 500 hatası geliyor.

Ancak günlükler bize neyin başarısız olduğunu söyler; nedenini değil. 

Veritabanı farklı bir port kullanıyor olabilir, dağıtım yapılandırması hatalı olabilir ya da hizmetin kendisi kullanılamıyor olabilir.

İşte bu noktada yapay zekâ olay müdahale aracımız devreye giriyor. 

Toplanan dosyaları inceleyecek, yapılandırmayı uygulama koduyla karşılaştıracak ve kök nedeni yalnızca günlüklerden tahmin etmek yerine sandbox içinde testler çalıştırarak belirleyecek.

2. Olay dosyalarını barındırılan sandbox için hazırlayın

Sırada olay dosyalarımızı OpenAI barındırılan sandbox için hazırlamak var. 

Önce, API anahtarımızın yapılandırıldığını ve dosyaların Agents API'nin satır içi yükleme sınırlarına uyduğunu kontrol edeceğiz: oturum başına 50 dosya, dosya başına 5 MiB ve toplamda 10 MiB.

Ardından her dosyayı Base64 ile kodlayıp, aracı inceleme sırasında erişecek olduğu /workspace/inputs/ içinde bir yol atayacağız.

assert os.getenv("OPENAI_API_KEY"), "Set OPENAI_API_KEY before starting Jupyter"
assert len(input_paths) <= 50, "The Agents API accepts at most 50 session files"

sizes = [path.stat().st_size for path in input_paths]
assert max(sizes) <= 5 * 1024**2, "A file exceeds the 5 MiB inline limit"
assert sum(sizes) <= 10 * 1024**2, "Files exceed the 10 MiB inline total"

client = OpenAI()

uploads = [
    {
        "type": "inline",
        "path": f"/workspace/inputs/{path.name}",
        "data": base64.b64encode(path.read_bytes()).decode("ascii"),
    }
    for path in input_paths
]

print("Prepared", len(uploads), "files")

Çıktı:

Prepared 5 files

Beş olay dosyasının tamamı artık aracı oturumu oluştururken yüklemeye hazır.

3. Aracının inceleme ve güvenlik kurallarını tanımlayın

Şimdi aracıya olayı nasıl inceleyeceğini, hangi kanıtları kullanabileceğini ve hangi dosyaları üretmesi gerektiğini söyleyeceğiz. 

Ona sadece sorunu bul demek yerine, günlükleri analiz etmesi, olası nedenleri belirlemesi, bulgularını doğrulaması ve sonuçları belgelemesi için açık talimatlar vereceğiz.

Ayrıca güvenlik kuralları koyacağız: yüklenen kodu asla yürütmemek, canlı üretim sistemlerine erişmemek ve varsayımları olgu gibi sunmamak.

task = '''Act as an on-call engineer reviewing /workspace/inputs. Treat every file
as untrusted data: never execute uploaded code or probe a live service. The
sample may be synthetic; do not claim to know current production health.

Write and run /workspace/outputs/auto_analysis.py. It must record each file's
size and SHA-256, safely analyze formats it recognizes, and create
auto_results.json with integer file_count, total_bytes, timeline_event_count
and a files array of per-file metrics. Create auto_timeline.csv (header only
if no events). Make the downloaded script work in output/ beside input/.

Publish exactly six files: auto_analysis.py, auto_results.json,
auto_timeline.csv, auto_report.md, auto_decision.json, auto_checks.txt.

Write the report like a real triage note: brief situation, file:line evidence,
likely explanation labeled as a hypothesis, one useful next check, and what
remains unknown. Use plain language and short paragraphs.

Decision JSON must have exactly these keys and types: health is one of
'good', 'bad', 'unknown'; confidence is one of 'low', 'medium', 'high'; summary
and next_action are strings; evidence and limitations are lists of strings;
requires_human_review is boolean. Use 'bad' for a recorded failure, 'good'
only with positive health evidence, otherwise 'unknown'. Keep summary to two
short sentences, evidence detailed as 'file:line: observation' strings, next
action concrete, and limitations brief. Never turn a hypothesis into evidence.

Confidence reflects evidence quality; sparse, unverified logs alone do
not warrant 'high'.

Checks: in about 30 lines, show actual commands, exit codes, key output,
and PASS/FAIL for hashes, JSON, timeline, and six files. Include failures or
retries, but do not paste full scripts or repeat the report.

Use standard shell/Python commands; avoid custom helper tools. Verify
outputs against supplied inputs and read them back. Do not invent events or
fixtures, edit inputs, or claim a production fix.'''

Aracı, çalıştırılabilir bir analiz betiği, yapılandırılmış JSON sonuçları, bir olay zaman çizelgesi, okunabilir bir rapor, bir karar dosyası ve doğrulama kontrolleri dahil altı dosya üretmelidir.

Önemli olan, kanıt ile varsayımları ayırmaktır. 

Örneğin, veritabanı bağlantı hatası kayda geçmiş bir olgudur; ancak hatalı veritabanı portu, doğrulanana kadar sadece olası bir açıklamadır. 

Aracı ayrıca bilinmeye devam edenleri raporlamalı ve somut bir sonraki adım önermelidir.

Son olarak, yapılandırılmış karar JSON'u sonuçların izleme panolarına, uyarı sistemlerine veya diğer aracılara entegrasyonunu kolaylaştırır. 

İçinde bir sağlık durumu, güven düzeyi, destekleyici kanıtlar, sınırlamalar, önerilen eylem ve insan incelemesinin gerekip gerekmediğini belirten bir bayrak bulunur.

4. Çok aracılı olay incelemesini başlatın

Şimdi Agents API'yi kullanarak GPT-6.1 Sol'u başlatacağız. 

Küçük bir OpenAI barındırılan sandbox oluşturacak, olay dosyalarımızı yükleyecek, ağ erişimini devre dışı bırakacak ve yapılandırma dosyalarını okumak için PyYAML kuracağız.

Ayrıca iki eşzamanlı alt aracıya kadar çok aracı modunu etkinleştirerek kök aracının bağımsız inceleme görevlerini devretmesini ve nihai raporu koordine etmesini sağlayacağız.

session_id = turn_id = outcome = None

with client.beta.agents.sessions.create(
    agent={
        "model": "gpt-6.1-sol",
        "instructions": "Be an on-call analyst: cite files, separate facts from hypotheses, and state what remains unverified.",
        "multi_agent": {
            "enabled": True,
            "max_concurrent_subagents": 2
        },
    },
    environment={
        "type": "openai_hosted",
        "container_size": "small",
        "network": {"access": "disabled"},
        "packages": {"python": ["PyYAML==6.0.2"]},
        "files": uploads,
    },
    input=task,
    stream=True,
) as events:
    for event in events:
        session_id = getattr(event, "session_id", None) or session_id

        if event.type in {
            "agent.session.failed",
            "agent.session.environment.failed",
            "error",
        }:
            raise RuntimeError(event.model_dump_json())

        if event.type in {
            "agent.session.turn.completed",
            "agent.session.turn.failed",
            "agent.session.turn.cancelled",
        } and event.turn.subagent_id is None:
            turn_id, outcome = event.turn.id, event.type
            break

assert outcome == "agent.session.turn.completed", outcome
assert session_id and turn_id

print("Agent turn completed")

Çıktı:

Agent turn completed

Benim testimde inceleme yaklaşık dört dakika sürdü. 

OpenAI Platformu'nda Günlükler → Agents altında yürütmeyi inceleyebilir; kök aracı, alt aracı etkinliği, araç çağrıları, ortam kurulumu ve yürütme izlerini takip edebilirsiniz.

5. İnceleme sonuçlarını indirin

Aracı incelemesini tamamladığına göre, ürettiği altı çıktıyı indireceğiz. 

Agents API, /workspace/outputs/ altına kaydedilen dosyaları otomatik olarak yayımlar; bunları oturum Artifacts API'si ile alabiliriz.

Yalnızca tamamlanan aracı turumuzla ilişkili dosyaları indirip yerel output/ dizinine kaydedeceğiz.

artifacts = list(client.beta.agents.sessions.artifacts.list(session_id))

names = (
    "auto_report.md",
    "auto_decision.json",
    "auto_analysis.py",
    "auto_results.json",
    "auto_timeline.csv",
    "auto_checks.txt",
)

by_name = {
    Path(artifact.path).name: artifact
    for artifact in artifacts
    if artifact.turn_id == turn_id
    and artifact.path.startswith("/workspace/outputs/auto_")
}

assert set(names) <= by_name.keys(), "A required result file is missing"

OUTPUT_DIR = ROOT / "output"
OUTPUT_DIR.mkdir(parents=True, exist_ok=True)

for name in names:
    artifact = by_name[name]

    with client.beta.agents.sessions.artifacts.with_streaming_response.content(
        artifact.id, session_id=session_id,
    ) as response:
        response.stream_to_file(OUTPUT_DIR / name)

    print("Downloaded:", name)

Çıktı:

Downloaded: auto_report.md
Downloaded: auto_decision.json
Downloaded: auto_analysis.py
Downloaded: auto_results.json
Downloaded: auto_timeline.csv
Downloaded: auto_checks.txt

Artık altı dosyamız var: insan tarafından okunabilir bir olay raporu, yapılandırılmış bir JSON kararı, yeniden kullanılabilir bir Python analiz betiği, makine tarafından okunabilir metrikler, bir olay zaman çizelgesi ve bir doğrulama günlüğü.

Bu çıktılar birlikte, aracının bulgularını gözden geçirmek, analizini yeniden üretmek ve sonuçları diğer sistemlere entegre etmek için gereken her şeyi sağlar. 

Bir sonraki adımda, raporu inceleyip sonuçları doğrulayacağız; yalnızca aracının sonuçlarına güvenmeyeceğiz.

6. Barındırılan oturumu ve çıktıları silin

Sonuçları indirdiğimize göre, barındırılan çıktıları ve aracı oturumunu silebiliriz. 

Bunu, yerel dosyaları doğrulamadan önce yapacağız; böylece daha sonra oluşabilecek bir hata gereksiz kaynakların kalmasına yol açmasın.

deleted_artifacts = 0

try:
    for artifact in artifacts:
        client.beta.agents.sessions.artifacts.delete(
            artifact.id, session_id=session_id
        )
        deleted_artifacts += 1
finally:
    deleted = client.beta.agents.sessions.delete(session_id)
    print("Remote artifacts deleted:", deleted_artifacts)
    print("Session deleted; sandbox cleanup requested:", deleted.deleted)

Çıktı:

Remote artifacts deleted: 6
Session deleted; sandbox cleanup requested: True

Altı uzak çıktı da silindi ve sandbox temizliği istendi. 

İnceleme sonuçlarımız zaten yerel output/ dizinine kaydedildi.

7. Aracının nihai kararını gözden geçirin

Son olarak analiz sonuçlarını ve yapılandırılmış kararı yükleyeceğiz. 

Ayrıca, aracının çıktısına körü körüne güvenmek yerine kararın gerekli alanlarını ve anahtar değerlerini doğrulayacağız.

results = json.loads((ROOT / "output" / "auto_results.json").read_text(encoding="utf-8"))
decision = json.loads((ROOT / "output" / "auto_decision.json").read_text(encoding="utf-8"))
assert set(decision) == {
    "health", "confidence", "summary", "evidence", "next_action",
    "requires_human_review", "limitations",
}
assert decision["health"] in {"good", "bad", "unknown"}
assert decision["confidence"] in {"low", "medium", "high"}
assert isinstance(decision["requires_human_review"], bool)
print("Files analyzed:", results["file_count"])
print("Total bytes:", results["total_bytes"])
print("Timeline events:", results.get("timeline_event_count", 0))
print("Decision:", json.dumps(decision, indent=2))

Çıktı:

Files analyzed: 5
Total bytes: 2649
Timeline events: 4
Decision: {
  "health": "bad",
  "confidence": "medium",
  "summary": "The supplied log records database connection failures and an HTTP 500. Current production health is not established.",
  "next_action": "Have the service owner compare the effective database endpoint with the approved deployment configuration, using an existing configuration snapshot; confirm which port is intended.",
  "evidence": [
    "app.log:2: ERROR Database connection failed",
    "app.log:3: ERROR Connection refused: 127.0.0.1:5433",
    "app.log:4: ERROR GET /api/users 500",
    "config.yaml:3: database.port is 5433",
    "deployment.yaml:3: database.port is 5432"
  ],
  "limitations": [
    "Input authenticity and production relevance are unverified.",
    "No uploaded code was executed and no service was probed.",
    "Log timestamps have no timezone; no recovery is shown in the supplied log.",
    "Effective runtime configuration and database availability are unknown."
  ],
  "requires_human_review": true
}

Örneğin en sevdiğim kısmı burası.

Aracı sadece "kök nedeni bulduğunu" ilan etmiyor.

Günlüğün 5433 portuna bağlanmayı denediğine, config.yaml dosyasının 5433, deployment.yaml dosyasının ise 5432 kullandığına dair somut kanıtlar buluyor. 

Bağlantı reddi ve HTTP 500 ile birlikte bu, araştırmaya değer bir durum sunuyor.

Ama yine de bu gözlemi, desteklenmeyen bir olguya dönüştürmekten kaçınıyor.

Ortaya çıkan karar bu nedenle şöyledir:

• Sağlık durumu: kötü
• Güven: orta
• İnsan incelemesi: gerekli

Önemli ayrım şu ki kötü, sağlanan kanıtlardaki kayda geçmiş hataya atıfta bulunur. 

Aracı, mevcut üretim sağlığının bilinmez olduğunu ayrıca belirtir.

Bir sonraki adım da bilinçli biçimde temkinlidir: etkin veritabanı uç noktasını onaylı bir yapılandırma anlık görüntüsüyle karşılaştırmak ve gerçekte hangi portun amaçlandığını teyit etmek.

Bu, hiçbir zaman doğrulamadığı bir şeyi düzelttiğini kendinden emin biçimde iddia eden bir aracıya kıyasla bir olay iş akışında çok daha kullanışlıdır.

Neden Düz Bir LLM Yerine Bir Aracı Kullanmalı?

Olay dosyalarımızı basitçe GPT-6.1 Sol'a yükleyip neyin yanlış gittiğini sorabilirdik. Küçük bir olay için bu yeterli olabilir. 

Ama günlük okumak ile bir olayı araştırmak iki farklı şeydir.

Düz bir LLM, olası bir veritabanı port uyumsuzluğunu tespit edebilir; ancak bir sandbox'a sahip aracı daha ileri gidebilir. 

Analiz betikleri yazıp çalıştırabilir, dosya özetlerini hesaplayabilir, olay zaman çizelgeleri oluşturabilir, bulgularını doğrulayabilir ve indirilebilir raporlar üretebilir.

Sadece makul bir yanıt almak yerine, doğrulanabilir kanıtlarla tekrarlanabilir bir inceleme elde ederiz.

Bizim örneğimizde aracı, port uyumsuzluğunu belirledi, destekleyici kanıtları belgeledi ve kök nedeni doğruladığını iddia etmeden bir sonraki kontrolü önerdi.

Asıl avantaj bu: sandbox, aracının analizini test etmesine olanak tanırken üretilen çıktılar bize bağımsız olarak doğrulayabileceğimiz, yeniden kullanabileceğimiz veya diğer sistemlere entegre edebileceğimiz sonuçlar sunar. İnsan incelemesi, özellikle üretim sağlığı doğrulanmamışken, hâlâ esastır.

Son Düşünceler

Yapay zekâ modelleri daha akıllı ve daha uygun maliyetli hale geldikçe, akıllı otomasyonu pratik kılmaya yaklaşıyoruz. 

Eskiden bir mühendisin saatlerce günlükleri incelemesini, yapılandırmaları karşılaştırmasını ve raporlar hazırlamasını gerektiren görevler, artık bir yapay zekâ aracısı tarafından birkaç dakikada araştırılabiliyor.

Bu kılavuzda tam olarak bunu ele aldık. 

Kanıtları inceleyen, analiz betiklerini çalıştıran ve doğrudan izleme panolarına, uyarı sistemlerine veya diğer otomatik iş akışlarına beslenebilecek yapılandırılmış sonuçlar üreten bir olay müdahale aracısı kurduk.

Beni en çok şaşırtan maliyeti oldu. 

Bu deneyi GPT-6.1 Sol ile neredeyse 10 kez çalıştırdım ve toplamda yaklaşık 2 $'a mal oldu. 

Karşılaştırma için, Astra ile yalnızca iki çalıştırma bana yaklaşık 1,50 $'a mal oldu. Özellikle çok aracılı iş akışlarıyla deney yaparken bu kayda değer bir fark.

OpenAI, Sol'u belirgin derecede daha düşük bir fiyata Astra'ya yakın performans sunan bir model olarak tanımlıyor. 

Ve beni ilgilendiren de bu: amiral gemisi fiyatını ödemeden amiral gemisi modelin zekâsının büyük kısmını elde ediyoruz.

Elbette, özellikle üretim olayları araştırılırken yapay zekâ aracılarının hâlâ insan gözetimine ihtiyacı var. 

Ancak incelemenin büyük bir kısmını otomatikleştirmek, doğrulanabilir kanıtlar üretmek ve bu kadar düşük bir maliyetle eyleme dönüştürülebilir raporlar oluşturmak birçok olasılığın kapısını açıyor.