Sigorta Poliçelerinde Bilgiye Ulaşma Süreçleri
Bir kullanıcı, elli sayfadan oluşan bir sigorta poliçesiyle ilgili olarak şu soruyu yöneltiyor: “prim nedir?”. Bu noktada devreye giren analiz aracı, daha önce oluşturulan ve belgenin yapısını tanımlayan profil bilgilerine başvuruyor:
doc_type: insurance_policy(belge türü: sigorta poliçesi)n_pages: 47(sayfa sayısı: 47)toc_df(içindekiler tablosu), “Genel Bilgiler”, “Kapsamlar”, “İstisnalar”, “Ekler” gibi bölümleri listeler. Ancak, “Prim” adında bir bölüm bulunmamaktadır.
Standart bir yaklaşım kullanılarak, analiz aracı kelime anlamı tabanlı bir tarama yapar ve belgenin tamamını inceler. Bu tarama sonucunda, “prim” kelimesini içeren istisna maddeleri, standart ek madde metinleri ve birkaç rastlantısal referans tespit edilir. Ancak, gerçek prim tablosu, “Genel Bilgiler” bölümünde, 3. sayfada yer almaktadır. Kullanıcının sorusu, bu bilgiyi doğrudan belirtmemektedir.
Ancak, daha gelişmiş bir sistem farklı bir yaklaşım benimser. Bu sistemdeki analiz aracı, “prim” kelimesinin içindekiler tablosunda karşılık gelen bir bölüm bulunmadığını tespit eder. Ardından, sistemi durdurur ve kullanıcıya doğrudan bir soru yöneltir:
“Bu poliçede ‘Prim’ adında bir bölüm göremiyorum. Hangi bölümde aramanızı öneririm?”
section_hint veya benzeri bir alana yerleştirir ve sistemin çalışması devam eder.
Bu basit etkileşim, belirsizliği ortadan kaldırır ve bilgiye erişim sürecini daraltır. Bu yaklaşım, özellikle karmaşık belgelerde, kullanıcıların ihtiyaç duyduğu bilgilere daha hızlı ve doğru bir şekilde ulaşmasını sağlar. Bu durum, sigorta sektöründe olduğu gibi, büyük miktarda belgeyle çalışan diğer sektörlerde de önemli avantajlar sunmaktadır.
Daha kapsamlı bir mekanizma (aday değerlerin açık listesi, önerilen varsayılan değer, denetim izi, böylece cevap önbelleğe alınabilir ve bir dahaki sefere sessizce uygulanabilir) Article 6bis‘de detaylı olarak açıklanmaktadır. Bu örnek, en basit versiyonuna odaklanmaktadır: bir soru giriliyor, bir cevap alınıyor ve tek bir büyük dil modeli (LLM) kullanılıyor.
Enterprise Document Intelligence, kurumsal RAG (Retrieval-Augmented Generation) sistemlerini dört temel üzerine inşa eder: belge ayrıştırma, soru ayrıştırma, veri erişimi ve içerik üretimi. Bu makale, özellikle üretim kalitesinin “LLM etrafındaki döngüler” olarak tanımlanan disiplinde elde edildiği “döngü mühendisliği” perspektifinden bakarak, bu dört temelden ikincisi olan “soru ayrıştırma” sürecini yeniden ele almaktadır. Bu bağlamda, soru ayrıştırmanın nasıl yapılandırıldığına dair daha derin bir anlayış sunmak için, makalede yer alan 6A (tez), 6B (ayrıştırma) ve 6C (yönlendirme) gibi kaynaklara atıfta bulunulmaktadır. Ayrıca, kullanıcıların belirsiz sorular sorduğu durumlarda kullanılan “açıklama döngüsü” mekaniğinin nasıl çalıştığını anlatan Article 6bis, bu sürecin neden “döngü mühendisliği” ilkesine uygun olduğunu açıklamaktadır.
📓 Bölüm 3’teki üç örnek de dağıtılan notebook üzerinde çalışmaktadır. Açıklama döngüsünü kendiniz deneyin: arXiv veri kümesi ve bir broker sözleşmesini kullanarak, LLM’nin “ne eksik?” sorusunun belge profiline göre nasıl değiştiğini gözlemleyin. Kaynak koduna buradan ulaşabilirsiniz: doc-intel/notebooks-vol1.
1. İstemden bağlama ve döngü mühendisliğine
Bu çerçeve, son on sekiz ay içinde iki kez değişti.
İstem mühendisliği (2023): Kullanıcı işi yapar. Doğru istemi yazmayı öğrenin, birkaç örnek ekleyin, “adım adım düşün” ifadesini kullanın. LLM, durum bilgisi olmayan bir kehanet makinesidir. Kalite, kelime seçimleriyle ilgili bir sorundur.
Bağlam Mühendisliği (2025 Ortası)
Bağlam mühendisliği kavramı, mühendisin yaptığı işi tanımlar. Tobi Lütke ve Andrej Karpathy tarafından yeniden adlandırılan bu uygulama, “bir sonraki adım için bağlam penceresini doğru bilgilerle doldurma sanatıdır.” Burada önemli olan, istemin (prompt) sadece birçok seçenekten birisi olduğudur. Bu kavramın daha detaylı açıklamasını, “Soru ayrıştırması için bağlam mühendisliği” başlıklı makalede bulabilirsiniz.
Döngü Mühendisliği (2026)
Döngü mühendisliği ise, LLM çağrıları etrafında tasarlanan döngüleri ifade eder. LangChain bu durumu basitçe şöyle açıklar: “Yapay zeka ajanlarının potansiyeli, onlara inşa ettiğiniz döngülerdedir.” MindStudio ise bunu, “bir hedefe ulaşılana kadar tekrarlayan yinelemeli döngülerde çalışan yapay zeka sistemleri tasarlama” disiplini olarak tanımlar ve bu sayede geri bildirim boşluğunu kapatır. Bu yaklaşım, özellikle “Yapay Zekanın Yaratıcı Potansiyelini Ortaya Çıkaran Döngü Mühendisliği” gibi eserlerde daha detaylı incelenmiştir.
Bu üç kavram birbiriyle yarışan değil, birbirini tamamlayan unsurlardır. İstem mühendisliği, tek bir çağrının ne okuyacağını şekillendirirken, bağlam mühendisliği bu çağrıya hangi bilgilerin gireceğini belirler ve döngü mühendisliği ise bu çağrıyı sınırlı bir yineleme içinde kullanır.
Döngüler farklı boyutlarda olabilir. Büyük bir döngü, ajan tabanlı RAG (planla, uygula, gözlemle, yeniden planla, birçok aşama) iken, küçük bir döngü tek bir soru-cevap-devam turudur. Bu makale, özellikle soru ayrıştırması üzerine kurulu en küçük ve kullanışlı döngüye odaklanmaktadır.
2. Döngü, Sabit Bir Şemayı Doldurur
Döngüyü başlatmadan önce, doldurulacak alanların adlarını belirleyin.
Soru ayrıştırması, tüm seride kullanılan ve geri alma ve oluşturma süreçleri tarafından deterministik olarak tüketilen sabit bir dizi türlendirilmiş alana yazılır. 1. ciltte aşağıdaki alanlar bulunmaktadır:
keywords: İçerik isim öbekleri, bilgi erişim algılayıcıları için kullanılır.intent: Sınırlı bir enum (factual,listing,section_retrieval,open_scoped,open_corpus_wide).retrieval.section_hint:toc_df‘yi filtrelemek için kullanılan bölüm adı veya numarası.retrieval.layout_hint: Cevabın belirli bir düzen içinde bulunduğu durumlarda (örneğin, tablo, grafik veya sözlük) kullanılır.structural_hints.pages_hint: Kullanıcının sorusunda belirttiği sayfa listesi.- (
sheets_hint/slides_hint, Vol.2 formatları için kullanılmıştır, burada kullanılmamıştır.)
Bu isimler, makale ile sınırlı değildir. docintel.question modülünde bulunur ve tüm sonraki bileşenler (bilgi erişim algılayıcıları, dağıtıcı, üretim şema arama) bunları okur. Bir alan eklemek, tüm işlem hattını değiştirir. Bu bir tasarım kararıdır, JSON ayarlaması değildir.
Bu döngünün tek görevi, ayrıştırıcının kendi başına dolduramadığı bu alanlardan birini doldurmaktır. Yeni bir alan oluşturmaz.
Akış, altı adım ve bir geri dönüş oku:
Kodda, giriş bölümünde yer alan premium sorudaki akış:
İki parse_question(...) çağrısı arasında değişen şeylere dikkat edin: sadece eksik olan alandır. ParsedQuestion‘ın diğer tüm alanları olduğu yerde kalır. Sonundaki dispatch(parsed), döngü olmaksızın çalışacakmış gibi aynı şemaya karşı çalışan tam olarak aynı çağrıdır.
Her alan zorunlu değildir: Bir GÖSTERİLMEZ YOKSA, bir section_hint yoktur ve bu sorun değil, başka bir alan (örneğin, pages_hint) aramayı kapsar. Mühendislik çalışması, belge profilini göz önünde bulundurarak hangi alana soru sorulacağını ve kullanıcının bağlamı için soruyu nasıl ifade edeceğimizi seçmektir.
3. Üç Durum, Eksik Üç Alan
Aşağıdaki her durumda, ayrıştırıcının ham sorudan tek başına dolduramadığı tek alan belirtilmektedir; bu eksikliği işaret eden belge profili ve alanı tamamlayan düz soru yer almaktadır. Üçünde de aynı şema kullanılmıştır, yeni bir alan icat edilmemiştir.
3.1 Eksik section_hint: Konu İçindekiler’de Yok
Sigorta analistini düşünün; daha önce hiç görmediği bir poliçeyi açıyor. Kırk yedi sayfa, dört İçindekiler girdisi, ilk bakışta hiçbir şey dikkat çekmiyor. Normalde on dakika boyunca kaydırarak cevaplayacağı soruyu yazıyor:
“İlk çeyrek için prim ne kadar?”
Ayrıştırıcı, bu soruyu dosya hakkında zaten bildiği bilgilerle birlikte okuyor:
doc_type: sigorta_poliçesin_pages: 47toc_dfşu etiketleri gösteriyor: Genel Bilgiler, Kapsamlar, İstisnalar, Ekler. Hiçbirinde “Prim” kelimesi geçmiyor.
İlk çalıştırmada, parse_question(...) şunları dolduruyor:
keywordsolarak["prim"]dönüyor.intentolarakgerçekleştirilebilir(factual) dönüyor; çünkü cevap tek bir sayı, özet veya liste değil.retrieval.section_hintdoldurulamıyor.
İşte bu, işlem hattını durduran şey. Kullanıcının konusu, herhangi bir İçindekiler etiketiyle eşleşmiyor ve ayrıştırıcı yeni bir etiket uydurmuyor. Elde edilen bilgilerin tamamı değilse bile, kısmi bir satırı geri getirme yerine, bekletiyor ve soruyor.
Analiste şu soru yöneltiliyor:
Politika Belgelerindeki Bilgi Çıkarım Süreci
Bir kullanıcı, bir politika belgesinde belirli bir bilgiye ulaşmak istediğinde aşağıdaki gibi bir soru sorabilir:
“Bu politikada ‘Premium’ bölümü var mı? Eğer varsa, nerede bulunuyor?”
Kullanıcı, soruyu doğrudan sisteme yazarak bu süreci başlatır. Kullanıcının aceleyle hareket ettiği durumlarda “General Info” ifadesini kullanabilirken, emin olmadığı durumlarda “The general one” veya daha dikkatli bir şekilde “Try general information” ifadesini tercih edebilir. Önemli olan, kullanıcının yazdığı kelimelerin anlamı değil, sistemin bu ifadeleri doğru bir şekilde yorumlayabilmesidir. Sistemdeki yapay zeka modeli (LLM), ilk soruyu analiz ettikten sonra, kullanıcı tarafından girilen ifadeyi (örneğin “General Info”) section_hint alanına yazarak işlemi tamamlar. Bu sayede, sistem diğer alanlardaki bilgileri ilk analizde belirlenen yerlerde tutar ve sadece ilgili bölümdeki bilgilere odaklanır.
Bu noktadan sonra süreç deterministik bir şekilde ilerler. section_filter_active alanı etkinleşir ve sistem, toc_df (bu politikada sayfa 3) içindeki yalnızca “General Information” bölümündeki bilgilere odaklanır. Bu sayede, yapay zeka modeli, ilgili bilgiye ulaşmak için gereksiz olan yüzlerce sayfayı taramak yerine, doğrudan alakalı metni analiz eder ve kullanıcıya saniyeler içinde sonucu verir.
3.2 pages_hint Alanının Eksikliği: Çoklu Konumlu Bilgiler
Farklı bir senaryoda, bir avukat asistanından günün sonunda dosyalanması gereken bir sözleşmeyi incelemesini ister:
“Müvekkilin adı nedir?”
Sistemdeki belge profili, bu belgenin 47 sayfalık bir contract olduğunu doğrular. İçindekiler tablosu (TOC), numaralandırılmış maddeler listeler ancak “Parties” başlığına sahip bir bölüm içermez. İlk analizde:
keywordsalanı["client name"]olarak geri döner.intentalanıfactualolarak belirlenir.structural_hints.pages_hintalanı iseNoneolarak kalır.
Buradaki en büyük sorun, pages_hint alanının eksikliğidir. Bir sözleşmede, müvekkilin adı genellikle üç farklı yerde bulunur:
- kapak sayfasında;
- her sayfanın üst kısmındaki başlıkta;
- imza bloğunda.
Sinema ve Dizi Dünyasından Güncel Gelişmeler
İçerik arama sürecinde, sayfa numarası ipucunun verilmemesi durumunda, sistemin tüm belgeyi taraması ve “müşteri” kelimesinin geçtiği her yeri dahil etmesi gerekir. Doğru bölüm genellikle 1. sayfada bulunur. Ancak, bu durumda sinyal-gürültü oranı düşer ve içerik üretimi başlamadan önce sorunlar ortaya çıkar.
Sistem, kullanıcının sorusuna şu şekilde yanıt verir:
“Sözleşmeler genellikle birkaç yerde ‘müşterinin’ adını taşır (ön kapak, başlık, imzalayanlar). Hangi bölümü incelememi istersiniz?”
Müşavir, “ön kapak”, “1. sayfa” veya “ilk sayfa” gibi ifadeler kullanır. Tam ifade önemli değildir. İkinci analizde, LLM (Large Language Model – Büyük Dil Modeli), kullanıcının pages_hint: [1] alanına yazdığı varyantı dikkate alır. keywords (anahtar kelimeler) ve intent (amaç) aynı kalır. pages_hint_active etkinleşir, sistem sadece 1. sayfayı okur ve LLM, bu temiz içerikle bir sonuç üretir.
3.3 Eksik pages_hint: Uzun belgelerde içindekiler tablosu yok
Bir araştırmacı, kurum içi bir risk raporunu açar ve asistana şu soruyu yöneltir:
“Risk bölümünü özetleyin.”
Belge profili, bu belgenin bir research_paper (araştırma raporu) olduğunu belirtir. Raporun otuz iki sayfası vardır ve toc_df (içindekiler tablosu veri çerçevesi) boş durumdadır. Görsel olarak raporda bölüm başlıkları bulunmaktadır, ancak ayrıştırma modülü bunları temiz bir şekilde çıkaramamıştır (karmaşık stil düzenlemeleri, tutarsız numaralandırma vb.). Bu durum, section_hint‘in devreye girmesini engeller. İçindekiler tablosu bulunmadığı için bağlanacak bir bölüm başlığı yoktur.
Ancak bu durum, pages_hint‘i etkilemez. Araştırmacı, risk tartışmasının raporda yaklaşık olarak nerede bulunduğunu biliyor olabilir ve sistemin arama alanını daraltmak için yaklaşık bir sayfa aralığı yeterlidir. Bu, ayrıştırma modülünün kullanıcıya sorabileceği faydalı bir soru sağlar:
“Bu raporda temiz bir içindekiler tablosu bulunmamaktadır. Risk bölümünün hangi sayfalarda olduğunu yaklaşık olarak biliyor musunuz?”
Kullanıcının verdiği iki farklı yanıt, sistemin farklı yollara gitmesine neden olur:
- “No idea” seçeneği,
pages_hint: Nonedeğerini koruyor. Bu durumda sistem, tüm belgeyi taramak zorunda kalıyor. Arama işlemi, otuz iki sayfalık belgeyi tamamen okuyor ve üretme aşaması, mümkün olan en geniş bağlamı kullanıyor. Bu işlem maliyetli olsa da, kullanıcıya ne olacağının söylendiği unutulmamalı. - “Around the middle” seçeneği ise ikinci analizde
pages_hint: [11, 12, 13, ..., 22]değerine dönüştürülüyor. Bu durumdapages_hint_activedevreye giriyor. Arama işlemi, belgenin sadece üçte birini okuyor ve üretme aşaması daha kısa, daha ilgili bir bağlam kullanıyor. Özet daha hızlı elde ediliyor ve kullanılan LLM maliyeti, tüm belgeyi taramanın üçte biri seviyesine düşüyor.
Burada bahsedilen yapı, daha küçük bir veri kümesi üzerinde çalışan aynı temel zinciri temsil ediyor.
Üç farklı seçeneğin de ortak noktalarına dikkat edin. Döngünün dokunduğu her alan (section_hint, pages_hint) zaten şema üzerinde tanımlıydı. Döngünün katkısı, belgenin profilini göz önünde bulundurarak hangi alanı sorgulanacağını seçmek.
4. Bu döngünün nereye yerleştirildiği ve neden bu, bağımsız bir RAG (Retrieval-Augmented Generation) sistemi olmadığı
Bu döngü, soru analizinin içinde yer alıyor. Boru hattının geri kalanı, bu döngüyü hiç görmüyor: Arama işlemi sadece, soru analizinin tam güvenilirliğe sahip bir ParsedQuestion ürettikten sonra başlıyor; bu, ilk geçişte veya bir açıklama turundan sonra olabilir.
Arama ve üretme aşamaları, tek bir arayüzle çalışıyor: Doldurulmuş bir ParsedQuestion. Boru hattının bir tur gerektirip gerektirmemesinin farkında değiller. Bu döngü küçük, mühendislik ürünü ve tamamen soru işleme aşamasının içinde yer alıyor.
Bu konumlandırma aynı zamanda, bu küçük döngünün bağımsız bir işlem gibi görünmesine rağmen, aslında neden bağımsız bir sistem olmadığına dair bir açıklamadır:
- Tek bir döngü, birden fazla değil. Döngü yalnızca bir kez çalışır, kullanıcı seçim yapar ve işlem hattı devam eder. Döngü içinde planlama, yeniden planlama veya kendi kendini eleştirme gibi işlemler yapılmaz.
- Mühendisler tarafından tasarlanmış, LLM’ler tarafından planlanmamış. Aday değerleri, hedef alan, yedek varsayılanlar: tüm bunlar, doküman profiline göre yazılmış kod yollarıdır. LLM yalnızca “soru_kullanıcıya” metnini oluşturur ve önerilen varsayılan değeri seçer. Bu kadar.
- Gerçek verilere dayalı. Döngü yalnızca ayrıştırıcının adını koyabileceği boşluklarda çalışır (konu, içindokuüman tablosunda yoksa, çok konumlu bir konuysa veya içindokuüman tablosunda yoksa). Açık uçlu “biraz düşünmem gerekiyor” gibi introspeksiyonlar yapılmaz. Zylos Research‘in bahsettiği, yerleşik kendi kendini düzeltme yaklaşımıyla uyumludur: modelin kendisini sorgulamak yerine, yürütme sonuçlarına dayanır.
- Sınırlı gecikme süresi. Büyük bir yapay zeka döngüsü onlarca saniye sürebilir. Bu döngü ise yalnızca bir tur etkileşim ve bir LLM çağrısı ekler; ardından ya işlem devam eder ya da kontrol kullanıcıya devredilir.
Bu ayrımın önemi şudur: Çünkü sektördeki yapay zeka döngüsü mühendisliği genellikle çok aşamalı yapay zeka durumunu varsayar. Tek bir doküman içindeki süreçlerde, işe yarayan en küçük döngü budur.
5. Kapsam Dışı Konular
Bu makalede kasıtlı olarak ele alınmayan üç konu bulunmaktadır.
- Çok aşamalı, ajan tabanlı döngüler. Bu türde bir sistemin, kendi içinde planlama ve yeniden planlama yaparak birçok büyük dil modeli (LLM) çağrısı yapması, Volume 4’ün alanına girer; burada araçlarla entegre edilmiş ajan mimarileri söz konusudur.
- Üretimden sonra doğrulama/değerlendirme döngüleri. Cevabın üretilip ardından eleştirildiği (örneğin, Article 8C‘deki şema doğrulama ve tekrar mekanizması) yapılar, farklı bir altyapı üzerine inşa edilmiş kendi döngüleridir. Farklı bir hedef kitleye hitap ederler.
- Çoklu belge/korpus kapsamlı işlemler. “Hangi bölüm?” sorusu yerine “Hangi belge?” sorusunun sorulması,
CorpusContextproblemidir ve Volume 2’nin konusudur.
Her bir yapı, farklı bir döngü, farklı bir kapsam ve farklı bir hedef kitle için tasarlanmıştır; ancak aynı terminolojiyi farklı ölçeklerde kullanır. Bu durum, aslında “Yaratıcı Döngüler” olarak adlandırabileceğimiz bir kavramı ortaya çıkarıyor; tıpkı erken dönem sinemada Edwin S. Porter’ın “The Great Train Robbery” filminde kullandığı tekniklerle izleyiciyi şaşırtıp meraklandırması gibi.
6. Kaynaklar ve İleri Okumalar
Döngü mühendisliği kavramı, 2026 yılında birçok farklı kaynaktan aynı anda ortaya çıktı ve bağlam mühendisliğinin terminolojisini belirlemesinin ardından aynı terim üzerine odaklandı. Bu durum, aslında “Yaratıcı Döngüler” olarak adlandırabileceğimiz bir kavramı ortaya çıkarıyor; tıpkı erken dönem sinemada Edwin S. Porter’ın “The Great Train Robbery” filminde kullandığı tekniklerle izleyiciyi şaşırtıp meraklandırması gibi.
Sektördeki temel referans noktaları:
- Sydney Runkle (LangChain), “Döngü Mühendisliğinin Sanatı”: blog yazısı, Haziran 2026.
- MindStudio, “Döngü Mühendisliği Nedir? Yapay Zeka Kodlama Ajanları İçin Yeni Bir Yaklaşım”: blog yazısı, Haziran 2026.
- mem0, “Yapay Zeka Ajanları İçin Döngü Mühendisliği: Bellek Odaklı Tasarım”: blog yazısı.
Döngülerin inşa edildiği temel altyapı:
- Anthropic, “Building Effective AI Agents”: araştırma yazısı. Bu çalışmada, değerlendirici-optimize edici ve yansıtma gibi temel yaklaşımların yanı sıra, sonuçları belirgin şekilde iyileştiren durumlarda döngülerin eklenmesi gerektiği prensibi (temperance rule) vurgulanmaktadır. Bu yaklaşım, özellikle karmaşık problem çözme senaryolarında yapay zekanın daha verimli çalışmasını sağlamayı amaçlamaktadır.
- Yao ve ark., “ReAct: Synergizing Reasoning and Acting in Language Models”: arXiv 2210.03629. Bu makalede, akıl yürütme ve eylem süreçlerini bir araya getiren temel “akıl-eyle-gözlem” döngüsü tanıtılmıştır. Bu konsept, yapay zekanın daha bilinçli ve etkili kararlar almasına olanak tanır; bu da onu, örneğin erken dönem sinematik deneyimlerdeki montaj tekniklerinin yapay zeka alanındaki karşılığı olarak düşünebiliriz.
- Madaan ve ark., “Self-Refine: Iterative Refinement with Self-Feedback”: arXiv 2303.17651. Bu çalışmada, üretme → kendi kendine geri bildirim sağlama → iyileştirme döngüsü kullanılarak yapay zekanın performansının artırılması hedeflenmektedir.
Bu makalede bahsedilen çalışmaların temelini oluşturan kavramlar şu şekildedir:
- RAG kullanıcıları belirsiz sorular sorduğunda (Makale 6bis). Bu makalede, “açıklama isteği”, “varsayılan açıklama” ve “soru-öğrenme” önbelleği mekanizmaları kullanılarak belirsiz soruların nasıl netleştirileceği anlatılmaktadır.
- RAG için bağlam mühendisliği (Makale 7bis). Bu makalede, her RAG yanıtının arkasındaki dört farklı girdi türü çerçevesinde bağlam mühendisliği kavramı ele alınmaktadır ve bu yaklaşım, bu yazıda bahsedilen döngü mühendisliğine doğru bir uzantıdır.
Kaynak: Towards-Data-Science