Yapay zekâ entegrasyonu nasıl yapılır?

Yapay zekâ entegrasyonu, bir modeli API ile yazılımınıza bağlayıp cevaplarını kurallar ve insan onayıyla denetlemektir. Özel Beşiktaş Erkan Ulu Ortaokulu'nda Mayıs 2026'dan beri ödevler böyle değerlendiriliyor.

Bu rehberdeki adımlar, kullanımda olan kendi projelerimizden çıktı: Erkan Ulu'da kullanılan ödev platformu ve optik form okuma sistemi, öğretmenlerin Mac'inde çalışan Otocropper ve yapay zekâ özelliği olan üç mobil uygulamamız. Her adımda neye karar vermeniz gerektiğini ve bu projelerde nasıl karar verdiğimizi anlatıyoruz. Hizmetin kapsamını görmek isterseniz yapay zekâ entegrasyonu hizmeti sayfamıza bakabilirsiniz.

1. İşi seçin

Entegrasyon bir modelle değil, bir işle başlar. “Yapay zekâ ekleyelim” yerine “her gün gelen belgelerdeki üç alanı sisteme aktaralım” gibi tek ve ölçülebilir bir iş tanımlayın. İlk proje için uygun bir iş dört soruya “evet” cevabı verir:

• Tekrar ediyor mu? Her gün ya da her hafta aynı biçimde yapılan bir işte modelin katkısı ölçülebilir.
• Gerçek örnekler var mı? Modelin işleyeceği belge, fotoğraf ya da kayıtlardan örnekler; bulanık, eğik ve eksik olanlar dahil.
• Doğru sonuç tarif edilebiliyor mu? Bir cevap anahtarı, bir kontrol listesi ya da bir uzmanın onayı gibi.
• Sonucu biri kontrol edebiliyor mu? Modelin emin olmadığı durumda kararı kimin vereceği belli olmalı.

Ödev platformunda seçilen iş netti: öğrencinin el yazısıyla çözdüğü her soruyu, öğretmenin cevap anahtarına bakarak doğru, yanlış ya da kısmen doğru diye işaretlemek ve nedenini açıklamak. Doğru sonucun tanımı cevap anahtarındaydı; sonucu kontrol edecek kişi de belliydi: öğretmen. İş seçilirken neyin kapsam dışında kalacağı da yazılmalıdır. İlk sürümde birden fazla işi aynı anda otomatikleştirmek, hangisinin işe yaradığını ölçmeyi zorlaştırır.

2. Modeli ve API'yi seçin

Model seçimi iki soruya dayanır: iş hangi tür girdiyle çalışıyor (metin, fotoğraf, ses) ve veri nerede işlenebilir. Modelin nerede çalışacağına göre üç yol vardır:

İkinci yolda sık kullanılan araçlardan biri vLLM'dir: büyük dil modellerini çalıştırıp sunmaya yarayan açık kaynaklı bir kütüphanedir ve OpenAI uyumlu bir API sunucusu içerir. Böylece kendi sunucunuzdaki modeli de yazılımınızdan bir sağlayıcı API'si gibi çağırabilirsiniz.

Aynı projede birden fazla model kullanmak olağandır; her adımın modeli, o adımın kendi testine göre seçilir. Cevabın sizin belgelerinize dayanması gerekiyorsa önce RAG yöntemine bakın: soruyla ilgili belge bölümleri bulunur ve model cevabını bu bölümlere dayanarak yazar. Testler hâlâ yetersiz kalıyorsa fine-tuning (ince ayar) gündeme gelir. İki yöntemi ayrı rehberlerde anlattık: RAG nasıl çalışır? ve ince ayar ne zaman gerekir?

3. İnsan onayını tasarlayın

Model yanılabilir; önemli olan, yanıldığında ne olacağıdır. Bu yüzden onay adımı sonradan eklenen bir ekran değil, ilk tasarımın parçasıdır. Proje başında şu dört soruyu yazılı olarak cevaplayın:

• Kim onaylar? Ödev platformunda da optik form okumada da bu kişi öğretmendir.
• Neye bakarak onaylar? Modelin kararı, gerekçesi ve dayandığı girdi aynı ekranda görünmelidir.
• Karar nasıl değişir? Ödev platformunda öğretmen yapay zekânın kararlarını panelden inceler; değiştirdiği karar geçerli olur.
• Emin olunamayan durumda ne olur? Optik form okumada güven puanı düşük kalan okuma tahmin edilmez, öğretmenin inceleme listesine düşer.

Onay her zaman tek tek kararlar için olmak zorunda değildir. Ödev platformunda pilot olarak denenen ve yapay zekânın hazırladığı fen dersleri, öğrencilere ancak öğretmen inceleyip düzenledikten sonra yayınlanır. Model taslağı çıkarır, yayın kararını insan verir.

Onay adımı hızlı da olmalıdır. İnceleyen kişi her sonucu baştan kendisi üretmek zorunda kalıyorsa sistem iş yükünü azaltmaz, yalnızca yerini değiştirir. Hangi sonuçların doğrudan kaydedileceğine, hangilerinin insana gideceğine ölçüm sonuçlarına bakarak karar verilir.

4. Ölçün

Bir modelin işe yarayıp yaramadığını demo değil ölçüm gösterir. Güvenilir bir ölçüm için üç şey gerekir:

• Eğitimde kullanılmamış veri. Modelin hiç görmediği örnekler en baştan ayrılır ve geliştirme boyunca bu örneklere dokunulmaz.
• Doğru sonucun yazılı tanımı. Hangi çıktının doğru, hangisinin kısmen doğru sayılacağı geliştirme başlamadan kararlaştırılır.
• Uygun ölçütler. Duyarlılık, bulunması gerekenlerin ne kadarının bulunduğunu; kesinlik, bulunanların ne kadarının gerçekten doğru olduğunu gösterir.

Otocropper böyle ölçüldü. Uygulama, taranmış soru bankalarındaki her soruyu ayrı bir görsel olarak kaydediyor. Soruları bulan model, eğitimde hiç kullanılmamış 238 sayfalık bir kitapta test edildi; bir tahmin ancak referans kutuyla kesişim/birleşim oranı (IoU) en az 0,9 olduğunda doğru sayıldı. Sonuç %97,1 duyarlılık ve %96,9 kesinlikti; 238 test sayfasının 222'sinde hiçbir düzeltme gerekmedi. Eşikler ve kurallar, test kitabına geçmeden önce ayrı bir doğrulama bölümünde seçildi ve sonra sabitlendi.

Ölçüm yayından sonra da sürer. Otocropper, 1.0.2 sürümünden önce okuldan gelen 20 PDF dosyasında (4.813 sayfa) denendi; 8 ile 14 Eylül 2026 arasında beş sürüm yayınlandı ve son ikisi öğretmenlerin bildirdiği sorunlar üzerine hazırlandı. Yayından sonra bildirilen hataları da test verisine eklemenizi öneririz.

5. Güvenlik, hata yönetimi ve maliyet

Bir model API'sini çağırmak birkaç satır koddur; aynı çağrının her gün, her kullanıcı için güvenle çalışması ayrı bir iştir. Yayından önce dört konuyu planlayın.

API anahtarı sunucuda kalır

Sağlayıcının API anahtarı tarayıcıda çalışan koda ya da mobil uygulama paketine konmaz; bu dosyalar kullanıcının cihazına indiği için içlerindeki bir anahtarın okunabileceğini varsayın. İstemci kendi sunucunuza bağlanır, sunucu kullanıcıyı doğrular, isteği kontrol eder ve modeli o çağırır. Anahtar ortam değişkeninde ya da bir gizli bilgi yöneticisinde durur, kod deposuna yazılmaz.

Geçici hatalar ve yeniden deneme

Ağ kesintisi, sağlayıcıdaki geçici bir arıza ya da kullanım sınırı yüzünden bazı çağrılar başarısız olur. Geçici hatalarda istek, aralar giderek uzatılarak birkaç kez yeniden denenir; hatalı biçimlenmiş bir istek ise yeniden denenmez, düzeltilir. Her çağrıya bir zaman aşımı konur ve model cevap vermediğinde kullanıcıya ne gösterileceği önceden belirlenir.

Uzun süren işler kullanıcıyı bekletmeden arka planda yürütülür. Optik form okumada her kâğıt grubu bir iş kuyruğuna girer, başarısız okumalar tekrar denenir ve öğretmen bu sırada ilerlemeyi ekranda görür.

Kullanım sınırları

Sağlayıcılar, belirli bir sürede yapılabilecek istek ve işlenebilecek token sayısını sınırlar (token, modelin metni böldüğü küçük parçalardır). Anthropic'in Claude API'sinde sınırlar dakikadaki istek, dakikadaki girdi token'ı ve dakikadaki çıktı token'ı olarak ölçülür; sınır aşıldığında API 429 hatası döndürür ve yanıtta retry-after başlığı varsa o kadar saniye beklenmesi istenir. Google'ın Gemini API'sinde sınırlar dakikadaki istek, dakikadaki girdi token'ı ve günlük istek sayısıyla ölçülür ve API anahtarına değil projeye uygulanır; aynı projede yeni anahtar açmak sınırı artırmaz.

Bu yüzden yoğun saatlerdeki çağrı sayısını önceden hesaplayın, istekleri bir kuyrukla sıraya koyun ve 429 hatasını bir arıza gibi değil, beklenen bir durum gibi ele alın.

Maliyeti izlemek

Barındırılan modellerde ödeme kullanıma göre yapılır. Claude modellerinde girdi ve çıktı token'ları ayrı ayrı, milyon token başına fiyatlanır; Anthropic'in fiyat tablosundaki her modelde çıktı token'ı girdi token'ından pahalıdır. Maliyeti kontrol altında tutmak için:

• Her model çağrısını, hangi özellik için yapıldığıyla birlikte kaydedin.
• Her adım için, kendi örneklerinizle yapılan testi geçen en düşük maliyetli modeli kullanın.
• Cevap uzunluğuna bir üst sınır koyun.
• Sonucu hemen gerekmeyen toplu işleri, sağlayıcının toplu işlem seçeneğiyle çalıştırın: Anthropic'in Batch API'si girdi ve çıktı token'larında %50 indirim uygular.

Bazı sağlayıcılarda bir harcama sınırı da vardır. Anthropic'te kullanım kademesinin (tier) aylık harcama tavanına ulaşıldığında, daha önce bir artış talep edilmediyse API kullanımı bir sonraki ayın ilk gününe kadar durur; istekler 429 hatası alır ve yeniden denemek sonuç vermez. Kendi belirlediğiniz bir harcama sınırına ulaşıldığında ise API 400 hatası döndürür. Kullanım büyüdükçe bu sınırları izlemek, beklenmedik bir kesintiyi önler.

Veri nereye gider, sorumluluk kimde kalır?

Bu sorunun cevabını projenin mimarisi belirler ve cevap proje başlamadan yazılı olarak verilmelidir. Projelerimizde iki farklı örnek var:

• Sağlayıcı API'siyle: MUST ve 1in46'daki asistanlar Claude modellerini sağlayıcının API'si üzerinden kullanır.
• Cihazda: Otocropper modeli, OCR'ı ve Python'u uygulamanın içinde taşır; öğretmenlerin Mac'inde tamamen çevrim dışı çalışır ve internet bağlantısı gerektirmez.

Kişisel verilerin veri sorumlusu sizseniz, sorumluluk sizde kalır. 6698 sayılı Kişisel Verilerin Korunması Kanunu'nun 12. maddesinin ikinci fıkrası şöyledir: “Veri sorumlusu, kişisel verilerin kendi adına başka bir gerçek veya tüzel kişi tarafından işlenmesi hâlinde, birinci fıkrada belirtilen tedbirlerin alınması hususunda bu kişilerle birlikte müştereken sorumludur.” Bir yapay zekâ entegrasyonunda verinizi sizin adınıza işleyebilecek taraflar arasında model sağlayıcısı, barındırma şirketi ve yazılımı geliştiren firma bulunabilir; hangisinin hangi rolde olduğunu sözleşmeden önce netleştirin.

Teknik tarafta üç soruyu cevaplayın: modele hangi alanlar gidiyor, bu alanlardan hangisi gerçekten gerekli ve sağlayıcının sözleşmesi bu veriyle ne yapılacağını nasıl tanımlıyor? Bu bölüm hukuki danışmanlık değildir; kişisel veri işleyen bir entegrasyonu yayına almadan önce avukatınıza danışın.

Mobil uygulamaya yapay zekâ eklemek

Mobil uygulamaya yapay zekâ entegrasyonu da aynı beş adımla yapılır; telefonda üç konu ayrıca önem kazanır:

• Anahtar: Model her zaman sizin sunucunuz üzerinden çağrılır; uygulama paketinde API anahtarı bulunmaz.
• Bekleme: Cevap anında gelmeyebilir. Kullanıcıya ilerleme gösterilmeli, bağlantı koptuğunda uygulama anlaşılır bir mesajla devam etmelidir.
• Giriş biçimi: Telefonda yazmak yerine konuşmak çoğu zaman daha rahattır; 1in46'da rüyalar sesle kaydedilir.

Projelerimiz arasındaki üç mobil uygulama yapay zekâyı farklı biçimlerde kullanıyor:

• 1in46: Yorumlar, Supabase üzerinde pgvector ile aranan, klasik, kadim ve Jungcu rüya literatüründen derlenmiş yaklaşık 6.300 pasaja dayanır; bu yöntemin adı RAG'dir ve model olarak Claude kullanılır. Uygulama Mart 2026'dan beri App Store'da, Eylül 2026'dan beri Google Play'de.
• MUST: İstanbul, Miami ve New York için bir şehir rehberi. Claude ile çalışan asistan, uygulamanın kendi doğrulanmış veritabanındaki 1.800'den fazla seçilmiş mekâna dayanarak cevap verir ve cevabı kaydedilebilir, çok duraklı bir gezi planına dönüştürür.
• Mawla: Namaz vakitleri ve Kur'an uygulamasındaki sesli asistan, günlük dinî sorulara kaynak göstererek cevap verir; bu cevaplar dinî hüküm değildir. Uygulama Türkçe ve İngilizcedir.

Yapay zekâ özelliklerinin maliyeti kullanıma göre arttığı için hangi özelliğin ücretsiz, hangisinin abonelikle sunulacağına baştan karar verin. 1in46 ve Mawla'da abonelikler RevenueCat ile yönetiliyor. Uygulamanın bütününü konuşmak isterseniz mobil uygulama geliştirme sayfamıza bakın.

İlgili hizmet

Yapay zekâ danışmanlığı ve entegrasyonu: belgelerinizden cevap veren asistanlar, kendi işini kontrol eden ajanlar ve yayından önce ölçülen modeller. Hizmetin kapsamı ve nasıl çalıştığımız bu sayfada.

İlgili rehberler

• Yapay zekâ ajanı nedir? Kendi işini kontrol eden ajanlar
• RAG nedir? Belgelerinizden cevap veren yapay zekâ asistanı
• Fine-tuning (ince ayar) nedir, ne zaman gerekir?

Kaynaklar

Aşağıdaki kaynakların tümü 16.10.2026 tarihinde kontrol edildi. Projelerimize ait rakamlar ve tarihler proje kayıtlarımızdan gelir; vaka çalışması olan projelerde bağlantısı verilen sayfada da yer alır.

• 6698 sayılı Kişisel Verilerin Korunması Kanunu, md. 12 (mevzuat.gov.tr)
• Claude API: Rate limits (Anthropic belgeleri, İngilizce)
• Claude API: Pricing (Anthropic belgeleri, İngilizce)
• Gemini API: Rate limits (Google belgeleri, İngilizce)
• vLLM belgeleri (İngilizce)