Bir AI Modeli veya API Kapatıldığında Uygulamanız Çalışmaya Devam Eder mi? Sağlayıcı Bağımlılığını Azaltma Rehberi

model: "some-model-version"

const result = await openai.responses.create({

return result.output_text

const AI_MODELS = {

## Basit bir interface nasıl görünebilir?

interface AIProvider {
generateText(input: GenerationInput): Promise<GenerationResult>
generateStructured<T>(
input: StructuredGenerationInput<T>
): Promise<T>
}
OpenAI:
class OpenAIProvider implements AIProvider {
// OpenAI-specific implementation
}
Anthropic:
class AnthropicProvider implements AIProvider {
// Anthropic-specific implementation
}
Google:
class GeminiProvider implements AIProvider {
// Gemini-specific implementation
}
Business layer ise:
await ai.generateStructured(...)
çağırır.
Bu yapı InoviqLab mimari önerisidir; ilgili sağlayıcıların zorunlu SDK tasarımı değildir.
Ama bütün sağlayıcıları tek interface'e zorlamak da hata olabilir
Burada önemli bir denge vardır.
Üç sağlayıcıyı şu şekilde düşünmek:
Model A = Model B = Model C
doğru değildir.
Farklı olabilirler:
- context window,
- tool calling,
- structured output,
- reasoning controls,
- multimodal input,
- caching,
- streaming,
hosted tools.
Aşırı abstraction yaparsanız provider’ın güçlü özelliklerini kullanamaz hale gelebilirsiniz.
Bu nedenle:
Common Core
+
Provider-specific capability
yaklaşımı daha dengelidir.
Önerilen yapı
interface AIProvider {
generateText(...)
generateStructured(...)
}
interface ToolCallingProvider extends AIProvider {
runTools(...)
}
interface RealtimeProvider extends AIProvider {
createRealtimeSession(...)
}
Böylece bütün sağlayıcıları olmayan yetenekleri varmış gibi davranmaya zorlamazsınız.

## Model değişikliği neden yalnızca model adını değiştirmek değildir?

Örneğin:
Model A
→ Model B
geçişinde şunlar değişebilir:
- cevap uzunluğu,
- JSON üretimi,
- tool seçimi,
- refusal davranışı,
- reasoning ayarları,
- latency,
- maliyet,
prompt sensitivity.
OpenAI’nin güncel GPT-5.6 migration rehberi bile önceki modellerden geçerken reasoning effort gibi ayarların gerçek workload üzerinde tekrar test edilmesini öneriyor. (OpenAI Developers)
Anthropic de deprecated model replacement’ına geçmeden önce yeni modeli uygulamanın gerçek görevleri üzerinde kapsamlı biçimde test etmeyi öneriyor. (Claude Platform)
Dolayısıyla:
model string değişti
↓
migration bitti
yaklaşımı doğru değildir.
En önemli koruma: Eval suite
Bir AI sisteminde regression test yalnızca klasik unit test değildir.
AI çıktısı deterministik olmayabilir.
Bu nedenle representative dataset tutulmalıdır.
Örneğin destek uygulaması:
100 gerçek destek talebi
için beklenen kriterleri saklayabilir.
Migration sırasında:
Eski model
vs
Yeni model
karşılaştırılır.

## Neler ölçülmeli?

Kalite
task success
factuality
classification accuracy
extraction accuracy
tool success.
Davranış
format uyumu
instruction following
refusal değişimi
gereksiz tool call.
Operasyon
latency
input tokens
output tokens
cost.
Örnek model migration tablosu
Metrik
Eski model
Yeni model

## Sonuç

Task success
%91
%94
✅
JSON validation
%97
%99
✅
Ortalama latency
2,4 sn
3,1 sn
⚠️
Ortalama maliyet
$0,012
$0,009
✅
Tool success
%95
%92
⚠️
Bu durumda:
Yeni model genel olarak daha iyi.
demek yerine hangi trade-off’un kabul edilebilir olduğunu ürün gereksinimine göre değerlendirmek gerekir.
Prompt'ları kodun içine dağıtmak migration'ı zorlaştırır
Örneğin 30 dosyada:
const prompt = `You are...`
bulunması model migration testini zorlaştırır.
Daha sağlıklı:
Prompt Registry
↓
Version
↓
Model
↓
Eval
yaklaşımıdır.
Örneğin:
const prompts = {
invoiceExtraction: {
- version: "v4",
- template: "...",
- },
}
Böylece model değişikliğinde hangi prompt versiyonunun test edildiği bilinir.

## Prompt ile model birlikte versionlanmalı mı?

Çoğu önemli AI use case’inde evet.
Örneğin:
invoice-extraction-v4
+
model-A
ile:
invoice-extraction-v4
+
model-B
ayrı eval sonuçlarına sahip olabilir.
Model B için:
invoice-extraction-v5
daha iyi çalışabilir.
Dolayısıyla deployment bilgisi:
model
+
prompt version
+
tool version
olarak kaydedilebilir.

## Model alias mı snapshot mı?

Bu tercih sağlayıcıya göre değişir.
Bazı sistemlerde alias:
latest
veya family alias kullanmak modeli otomatik güncelleyebilir.
Bu operasyonel kolaylık sağlar.
Ancak davranışın sizin kontrolünüz dışında değişmesi riskini de artırabilir.
OpenAI model dokümantasyonunda örneğin gpt-5.6 alias’ının belirli bir model ailesine yönlendirildiği açıkça belirtiliyor. Bazı model sayfaları ayrıca davranış tutarlılığı için belirli snapshot’ların seçilebilmesini açıklıyor. (OpenAI Developers)

## Ne zaman snapshot mantıklı?

Özellikle:
- finansal classification,
- regüle output,
- kritik extraction,
doğrulanmış production prompt
gibi kullanımda davranışı sabitlemek faydalı olabilir.
Ancak snapshot’ın da sonsuza kadar kalacağını varsaymayın.
OpenAI’nin Ağustos 2026’da bazı snapshot’ları tamamen kaldırması bunun açık örneğidir. (OpenAI Developers)

## Preview model production'da kullanılmalı mı?

Preview model:
gelecekte değişme veya hızlı emekliye ayrılma ihtimali daha yüksek
olabilir.
Google’ın deprecation tablosu stable ve preview modeller için ayrı lifecycle’lar gösteriyor; geçmişte bazı preview modellerin birkaç ay içinde kapandığı görülebiliyor. (Google AI for Developers)
Bu nedenle kritik product logic için:
Stable / GA
model varsayılan olarak daha güvenli lifecycle tercihi olabilir.
Preview gerekli ise:
- replacement plan,
- eval,
- feature flag,
monitoring
ile kullanılmalıdır.

## Model retirement bildirimleri takip edilmeli mi?

Kesinlikle.
Bu iş yalnızca developer’ın kişisel e-postasına bırakılmamalı.
Anthropic, aktif deployment’ı bulunan public modeller için retirement öncesinde müşterilere en az 60 gün bildirim verdiğini belirtiyor. Ayrıca Console kullanım verilerinin export edilerek deprecated model kullanımının audit edilebildiğini açıklıyor. (Claude Platform)
Ancak migration planının başlaması için:
son hafta
beklenmemelidir.
AI model envanteri tutun
Basit bir tablo yeterli olabilir:
Use case
Provider
Model
Owner
Criticality
Support Summary
OpenAI
Model A
Backend
Medium
PDA Extraction
Provider B
Model B
Product
High
Classification
Provider C
Model C
Backend
High
Internal Search
Provider A
Model D
Platform
Low
Ek alanlar:
GA / preview

## deprecated?

replacement
last eval
prompt version
fallback.
Bu tablo migration duyurusu geldiğinde:

- Nerede kullanıyoruz?

sorusunu saniyeler içinde cevaplar.

## Model ID'yi loglamak neden önemli?

AI request telemetry’de en az:
provider
model
prompt_version
request_id
latency
usage
success
tutulabilir.
Böylece provider:
Model X artık deprecated.
dediğinde geçmiş loglardan gerçekten kullanım olup olmadığı tespit edilebilir.
API endpoint de kapanabilir
Vendor lock-in yalnızca model adıyla ilgili değildir.
Örneğin OpenAI deprecation tanımı hem:
model
hem de:
endpoint
için geçerlidir. (OpenAI Developers)
Bir endpoint kapanıyorsa:
SDK method
request schema
response schema
state management
tool model
hep birlikte değişebilir.
Bu, model migration’dan daha maliyetli olabilir.
Provider SDK'sını bütün uygulamaya dağıtmayın
Örneğin:
import OpenAI from "openai"
şu dosyalarda bulunuyorsa:
invoice.ts
report.ts
email.ts
support.ts
search.ts
admin.ts
vendor-specific API product katmanına yayılmış olur.
Daha kontrollü:
/lib/ai/
provider.ts
openai.ts
anthropic.ts
gemini.ts
gibi merkezi katman kullanılabilir.
Application:
/lib/features/
içinden kendi domain service’inize bağlanır.

## Provider SDK'larını hiç kullanmamak mı gerekir?

Hayır.
Resmî SDK:
- authentication,
- streaming,
- retry,
- typing,
yeni özelliklere erişim
açısından değerlidir.
Ama SDK:
application architecture’ın kendisi
haline gelmemelidir.
SDK provider adapter içinde kalabilir.

## Provider bağımsız internal response oluşturmak faydalı mı?

Evet.
Örneğin sağlayıcı A:
{
"output_text": "..."
}
sağlayıcı B:
{
"content": [...]
}
sağlayabilir.
Application’ın ikisini bilmesi yerine:
type AIResult = {
text: string
model: string
provider: string
usage?: {
inputTokens: number
outputTokens: number
}
}
gibi internal yapı kullanılabilir.
Tool calling en zor migration alanlarından biri
Tool calling provider’lar arasında farklılaşabilir.
Farklı olabilir:
- tool schema,
- parallel calls,
- streaming,
- tool result formatı,
approval davranışı.
Bu nedenle tool definition’ları da mümkünse internal domain formatından provider formatına çevrilebilir.
Örneğin:
const tools = {
- searchCustomer: {...},
- createInvoice: {...},
}
sonra:
Internal Tool
↓
Provider Adapter
↓
Provider Schema
Ama MCP bu sorunu tamamen çözmez
Model Context Protocol ortak tool/data bağlantı katmanı oluşturmada yardımcı olabilir.
Ancak:
MCP kullanıyorum
→ provider bağımlılığım yok
sonucu doğru değildir.
Çünkü model provider hâlâ:
- reasoning,
- tool selection,
- context,
output behavior
sağlar.
MCP daha çok tool integration lock-in’ini azaltabilir.
Model davranışının kendisini standartlaştırmaz.

## Multi-provider kullanmak zorunlu mu?

Hayır.
Burası önemli.
Bir şirket:
OpenAI
+
Anthropic
+
Google
üçünü aynı anda production’da aktif tutmak zorunda değildir.
Bu:
- ekstra kod,
- daha fazla test,
- iki kat telemetry,
- farklı güvenlik politikaları,
daha fazla operasyon
yaratır.
Küçük veya orta proje için:
Primary provider
+
Clean adapter boundary
+
Documented migration plan
çoğu zaman yeterlidir.

## Gerçek multi-provider ne zaman mantıklı?

Özellikle:
- AI ürünün çekirdek fonksiyonuysa,
- provider outage ürünü tamamen durduruyorsa,
- yüksek trafik varsa,
- bölgesel availability önemliyse,
- tek model kapasitesi yetersiz olabiliyorsa,
kritik uptime SLA varsa.
Bu durumda:
Primary
↓ failure
Secondary
stratejisi değerlendirilebilir.

## Fallback nasıl tasarlanmalı?

Fallback her hata için çalışmamalıdır.
Örneğin:
400 Bad Request
aldığınızda başka sağlayıcıya geçmek genellikle problemi çözmez.
Ama:
timeout
429
5xx
provider outage
gibi transient failure’larda fallback düşünülebilir.
Örnek:
try {
return await primary.generate(input)
} catch (error) {
if (!isRetryableProviderFailure(error)) {
throw error
}
return secondary.generate(input)
}
Fallback kullanmanın gizli riski: davranış değişikliği
Primary model:
%97 doğru JSON
üretirken secondary:
%85
üretiyor olabilir.
Bu nedenle:
Secondary çalışıyor.
yeterli değildir.
Fallback provider da eval suite üzerinde test edilmelidir.

## Fallback sonucu kullanıcıya açıklanmalı mı?

Use case’e bağlıdır.
Örneğin arka plandaki:
email subject generation
için gerekmeyebilir.
Ama:
medical
financial
legal
high-impact recommendation
gibi hassas uygulamalarda kullanılan model/değişiklik daha önemli olabilir.
Burada ürün ve compliance politikası devreye girer.
Provider outage ile model retirement aynı şey değildir
Outage
Geçici:
Model geri gelecek.
Retirement
Kalıcı:
Model geri gelmeyecek.
Dolayısıyla outage için:
retry + fallback
kullanılırken retirement için:
migration
gerekir.

## Model alias kullanmak retirement problemini çözer mi?

Kısmen bakım yükünü azaltabilir.
Ama tamamen çözmez.
Alias:
model-family-latest
altındaki gerçek model değişebilir.
Bu durumda uygulama çalışmaya devam edebilir fakat:
- davranış,
- latency,
- cost,
output format kalitesi
değişebilir.
Bu nedenle floating alias kullanılıyorsa da eval ve monitoring gerekir.
Model değiştiğinde ilk bakılması gereken 8 alan

### 1. Output kalite

## İş sonucu hâlâ doğru mu?

### 2. Structured output

## Schema validation oranı değişti mi?

### 3. Tool calling

## Doğru tool seçiliyor mu?

### 4. Prompt uyumu

## Eski prompt hâlâ iyi çalışıyor mu?

### 5. Safety/refusal

## Beklenmeyen refusal değişiklikleri var mı?

### 6. Latency

## P95/P99 değişti mi?

### 7. Token ve maliyet

## Aynı request ne kadar pahalı?

### 8. Limits

## Context/output limitleri aynı mı?

Örnek migration süreci
Bir provider:
Model X 60 gün sonra retired.
dedi.
Gün 1
Envanter:

- Model X nerede kullanılıyor?

Gün 2–7
Replacement model staging'e eklenir.
Hafta 2
Eval dataset çalıştırılır.
Hafta 3
Prompt/tool değişiklikleri yapılır.
Hafta 4
Shadow veya düşük trafik rollout.
Hafta 5
Production migration.
Hafta 6
Eski model kullanımı loglardan doğrulanır.
Son
Eski config kaldırılır.
Bu süreç örnektir; kritik sistemlerde daha uzun olabilir.

## Shadow testing nedir?

Kullanıcının gerçek request’i:
Primary Model
→ gerçek cevap
üretirken aynı input:
New Model
→ yalnızca değerlendirme
için de çalıştırılabilir.
Kullanıcı yeni modelin cevabını görmez.
Böylece gerçek workload üzerinde:
- kalite,
- latency,
maliyet
karşılaştırılabilir.
Ancak:
- kullanıcı verisinin ikinci modele gönderilmesi,
- privacy,
maliyet
ayrıca değerlendirilmelidir.
Canary rollout model migration'da kullanılabilir
Örneğin:
%5 → yeni model
%95 → eski model
Sonra:
%25
↓
%50
↓
%100
artırılabilir.
Takip edilen metrikler:
- errors,
- user success,
- manual overrides,
- latency,
token usage.

## Feature flag neden değerli?

Kod:
const model = flags.newModel
? NEW_MODEL
: OLD_MODEL
gibi merkezi geçiş sağlayabilir.
Sorun çıkarsa:
deploy gerekmeden
↓
eski modele dön
mümkün olabilir.
Ancak eski model shutdown olmuşsa rollback yolu artık mevcut olmayabilir.
Bu nedenle migration son güne bırakılmamalıdır.

## AI provider abstraction'ın aşırı maliyeti var mı?

Evet.
Aşırı provider-neutral mimari:
- daha fazla interface,
- daha fazla mapping,
- provider capability kaybı,
daha fazla test
yaratabilir.
Bu nedenle soyutlama seviyesi product riskine göre belirlenmelidir.
Üç olgunluk seviyesi
Seviye 1 — Küçük uygulama
Tek provider
+
Model config env'de
+
Merkezi AI service
Yeterli olabilir.
Seviye 2 — SaaS
Provider adapter
+
Prompt registry
+
Eval suite
+
Model inventory
+
Feature flag
önerilebilir.
Seviye 3 — AI-kritik platform
Multi-provider adapters
+
Routing
+
Fallback
+
Shadow eval
+
Canary
+
Full observability
değerlendirilebilir.

## Model routing nedir?

Her görev için en güçlü modeli kullanmak zorunda değilsiniz.
Örneğin:
Classification
→ düşük maliyetli model
Complex report
→ güçlü reasoning model
Extraction
→ structured-output modeli
kullanılabilir.
Bu aynı zamanda model değişiminde:
bütün ürünün tek model ID’sine bağlı olmasını
azaltabilir.
Routing aynı zamanda maliyet stratejisidir
Örneğin:
1 milyon basit classification
için en pahalı frontier model gerekmeyebilir.
Provider abstraction:
- fallback,
migration
kadar:
- cost routing,
latency routing
için de kullanılabilir.

## Model-specific özellikler nerede tutulmalı?

Örneğin:
provider.generate({
reasoningEffort: "xhigh"
})
bütün business code’a yayılmamalıdır.
Daha iyi:
AI_PROFILES = {
complexAnalysis: {
- provider: "openai",
- model: "...",
- reasoning: "high",
}
}
gibi bir config layer olabilir.
“Model capability profile” yaklaşımı
Model ID yerine uygulama:
fast
balanced
deep
vision
realtime
gibi profile kullanabilir.
Örneğin:
const profile = aiProfiles.deepReasoning
altında bugün:
Provider A / Model X
yarın:
Provider B / Model Y
olabilir.
Business logic değişmez.
Provider değiştirirken veri politikası da kontrol edilmeli
Bu konu yalnızca teknik migration değildir.
Yeni provider için:
- data retention,
- training policy,
- region,
- DPA,
- privacy,
compliance
yeniden değerlendirilmelidir.
Dolayısıyla teknik olarak:
adapter switch
kolay olsa bile hukuki/kurumsal geçiş otomatik değildir.
Model migration kontrol listesi
Envanter
Kullanılan bütün provider’lar kayıtlı.
Kullanılan model ID’leri biliniyor.
Preview / GA ayrımı biliniyor.
Owner belirli.
Kritik kullanım alanları işaretli.
Deprecation takibi yapılıyor.
Mimari
Model ID business logic’e dağılmamış.
Merkezi AI service bulunuyor.
Provider-specific response normalize ediliyor.
Provider SDK yalnızca entegrasyon katmanında.
Prompt’lar versionlanıyor.
Tool definitions merkezi yönetiliyor.
Kalite
Representative eval dataset var.
Structured output validate ediliyor.
Tool-call success ölçülüyor.
Regression metric’leri tanımlı.
Manual evaluation örnekleri var.
Operasyon
Provider ve model telemetry’de tutuluyor.
Latency ölçülüyor.
Token usage ölçülüyor.
Cost ölçülüyor.
Error türleri normalize ediliyor.
Timeout tanımlı.
Migration
Replacement model belirlendi.
Staging testi yapıldı.
Eval karşılaştırması yapıldı.
Prompt yeniden test edildi.
Tool compatibility test edildi.
Feature flag mevcut.
Canary mümkünse kullanıldı.
Fallback
Fallback gerekli mi kararlaştırıldı.
Secondary provider test edildi.
Retryable error listesi belli.
Fallback sonucu validate ediliyor.
Sonsuz retry engelleniyor.
Sağlayıcı bağımlılığını azaltmak için 10 temel kural
Model adını business logic’e gömmeyin.
Provider çağrılarını merkezi katmanda tutun.
Prompt’ları versionlayın.
Representative eval dataset oluşturun.
Model kullanım envanteri tutun.
Deprecation duyurularını düzenli takip edin.
Preview modeli kritik production dependency yaparken dikkatli olun.
Model değişikliğini normal software migration gibi ele alın.
Fallback yalnızca gerçek ihtiyaç varsa kurun.
Provider abstraction’ı ürün ihtiyaçlarından daha karmaşık hale getirmeyin.
InoviqLab teknik değerlendirmesi
Bu bölüm InoviqLab değerlendirmesidir; OpenAI, Anthropic veya Google’ın resmî mimari önerisi değildir.
AI entegrasyonlarında sık yapılan iki uç hata bulunuyor.
Hata 1 — Tam vendor lock-in
Provider SDK
↓
bütün uygulama
↓
provider-specific model
↓
provider-specific tool
↓
provider-specific state
Bu durumda küçük bir API migration büyük proje haline gelebilir.
Hata 2 — Gereksiz multi-provider mimari
Daha ürün yeni çıkmadan:
OpenAI adapter
Anthropic adapter
Gemini adapter
Local model adapter
Router
Fallback
Cost engine
yazmak da gereksiz mühendislik olabilir.
Doğru seviye product riskine göre seçilmelidir.
En dengeli varsayılan: tek provider + temiz sınır
Çoğu SaaS uygulaması için başlangıçta:
Primary provider
+
Central AI service
+
Model config
+
Prompt registry
+
Eval suite
yeterince güçlüdür.
İkinci provider ancak:
- uptime,
- maliyet,
- müşteri gereksinimi,
model availability
gerektiriyorsa eklenebilir.
En değerli yatırım multi-provider kodu değil eval suite olabilir
Birçok ekip:
“İkinci provider ekleyelim.”
diye düşünür.
Ama model değiştiğinde:

- Yeni model gerçekten doğru çalışıyor mu?

sorusunu cevaplayacak test sistemi yoktur.
Bu durumda abstraction olmasına rağmen migration hâlâ risklidir.
Bu nedenle öncelik çoğu zaman:
Eval
>
Second provider
olmalıdır.
Çünkü asıl bağımlılık bazen API değil davranıştır
Uygulamanız teknik olarak provider adapter kullanabilir.
Ama prompt:
Model X'in tam davranışına
aşırı optimize edilmiş olabilir.
Yeni modelde:
- daha uzun cevap,
- farklı tool seçimi,
başka formatting
oluşabilir.
Bu yüzden gerçek vendor resilience:
Architecture
+
Evaluation
birlikte gerektirir.
Deprecation takibi teknik borç değil normal bakım olmalı
AI ürününde model lifecycle takip etmek:
- framework update,
- database upgrade,
API version maintenance
gibi normal operasyon işidir.
Anthropic modellerin deprecated olduğunda replacement’a retirement tarihinden önce geçilmesini ve yeni modellerin gerçek uygulama görevleri üzerinde önceden test edilmesini öneriyor. (Claude Platform)
OpenAI ve Google da deprecation/shutdown takvimlerini açık biçimde yayınlıyor. (OpenAI Developers)
Dolayısıyla bu iş:
“Model bir gün bozulursa bakarız.”
seviyesinde bırakılmamalıdır.

## Sonuç

Bir AI modelinin veya API’nin kapatılması:
olağanüstü bir edge case
değildir.
2026’nın yalnızca Ağustos ayında bile:
- OpenAI bazı model snapshot’larını kapattı,
- Anthropic Claude Opus 4.1’i retired durumuna geçirdi,
Google bazı embedding ve image modellerini shutdown etti. (OpenAI Developers)
Bu nedenle AI mimarisinin hedefi:
Asla provider'a bağımlı olmamak
- değil;
Değişiklik maliyetini kontrol altında tutmak
olmalıdır.
Çoğu uygulama için güçlü temel:
Business Logic
↓
AI Service
↓
Provider Adapter
↓
Model Config
ile başlar.
Buna:
- prompt versioning,
- model inventory,
- eval suite,
- telemetry,
- feature flag,
gerektiğinde fallback
eklenebilir.
En önemli prensip ise:
Modeli değiştirilebilir yapmak tek başına yeterli değildir; yeni modelin ürününüzde hâlâ doğru çalıştığını ölçebilmeniz gerekir.