Enterprise AI Entegrasyonu: Prototipten Üretime Giden Yol

Son birkaç yılda şirketlerin AI entegrasyonu konusunda benzer bir kafa karışıklığı yaşadığını gözlemliyorum. Yapay zekânın büyük bir dönüşüm yarattığı konusunda neredeyse herkes hemfikir. Bu dönüşümü iş süreçlerine zamanında dahil etmek de artık stratejik bir öncelik olarak görülüyor.

Bu nedenle birçok şirkette süreç benzer şekilde başlıyor: Kurum içindeki early adopter çalışanlar kişisel çabalarıyla prototipler geliştiriyor, kısa sunumlar yapıyor ve ekipler bu uygulamaları denemeye başlıyor. İlk sonuçlar genellikle etkileyici oluyor. Ancak bir süre sonra latency, isabetsiz cevaplar, kurumsal bağlama uyum sağlayamama, erişim kontrolü eksikleri ve büyüyen token maliyetleri görünür hale geliyor. Prototip, üretim sistemi olamadığı için proje yavaşlıyor veya tamamen durduruluyor.

Sorun çoğu zaman modelin yeterince güçlü olmaması değildir. Sorun, modelin etrafındaki sistemin tasarlanmamış olmasıdır.

Yapay zekâ kuruma ne kazandırabilir?

Üretken yapay zekâ, tek bir kullanıcının her talepte baştan sona okuyamayacağı büyüklükteki bilgi kaynakları üzerinde arama, ilişkilendirme, özetleme ve içerik üretme görevlerini çok kısa sürede gerçekleştirebilir. Bin sayfalık bir politika, prosedür veya teknik dokümantasyon kümesinde doğru bilgiye ulaşmak için kullanıcının tüm içeriği okuması gerekmez. İyi tasarlanmış bir sistem, ilgili bölümleri bulur, cevabı bu kaynaklara dayandırır ve kullanıcıya doğrulanabilir referanslar sunar.

Kapasite yalnızca metinle sınırlı değildir. Multimodal sistemler; metin, tablo, görsel, ses ve video gibi farklı veri türlerini aynı iş akışında değerlendirebilir. Ancak gerçek değer, yalnızca model kapasitesinden değil, bu kapasitenin doğru iş sürecine ve doğru kontrollere bağlanmasından doğar.

İlk kullanım alanı: kurumsal bilgiye erişim

Bir şirkette AI için akla gelen ilk kullanım alanlarından biri doküman işleme ve kurumsal bilgiye erişimdir. Retrieval-Augmented Generation, yani RAG, burada devreye girer. Sistem kullanıcının sorusuyla ilgili kaynak parçalarını bulur ve dil modelinin yanıtını bu içerik üzerine kurmasını sağlar.

Burada tek ve evrensel bir verimlilik oranı vermek doğru olmaz. Etki; göreve, veri kalitesine, çalışan deneyimine ve sistem tasarımına göre değişir. Bununla birlikte, 5.179 müşteri destek çalışanını kapsayan geniş ölçekli bir saha araştırmasında üretken AI destek aracı, saatte çözülen sorun sayısını ortalama yüzde 14 artırdı; daha az deneyimli çalışanlarda kazanım yüzde 34’e ulaştı.[1] Bu sonuç doğrudan her RAG projesine uygulanabilecek bir benchmark değildir. Yine de doğru bağlama yerleştirilen AI’nın bilgiye erişimi hızlandırabileceğini ve kurumsal uzmanlığın daha geniş ekipler tarafından kullanılmasını sağlayabileceğini gösterir.

RAG neden bir rabbit hole’a dönüşebilir?

Dokümanlarla chat yapabilmek kolay bir demo gibi görünür. Güvenilir bir kurumsal retrieval sistemi kurmak ise başlı başına bir engineering çalışmasıdır.

Onlarca retrieval tasarımı mümkündür: dense retrieval, sparse retrieval, hybrid search, metadata filtering, reranking, parent-child retrieval ve query expansion bunlardan yalnızca birkaçıdır. Doğru yaklaşım; veri türüne, kullanıcı sorularına, doğruluk ihtiyacına, latency hedeflerine ve altyapı bütçesine göre belirlenmelidir.

İlk kırılgan katman doküman işlemedir. Structured ve unstructured içerikler aynı yöntemle okunamaz. Yalnızca metin içeren bir PDF ile tablolar, dipnotlar, çok sütunlu sayfalar, grafikler, taranmış görseller ve karmaşık okuma sırası barındıran bir doküman aynı pipeline’dan aynı kaliteyle geçmez. PDF, göründüğünden daha zor bir formattır. Bu nedenle sisteme girecek veri tipleri, parsing stratejisi, OCR ihtiyacı, tablo çıkarımı ve chunking yöntemi önceden değerlendirilmelidir.

Docling, PDF ve diğer kurumsal dokümanları yapılarını koruyarak işlemek için kullanılabilecek araçlardan biridir. Resmî quickstart örneği, bir dokümanın dönüştürülerek Markdown biçiminde dışa aktarılmasını gösterir.[2]

from pathlib import Path
from docling.document_converter import DocumentConverter

source = Path("documents/company_policy.pdf")
converter = DocumentConverter()
result = converter.convert(source)

markdown = result.document.export_to_markdown()
print(markdown[:1500])

Bu örnek başlangıç noktasıdır. Üretimde ayrıca hata yönetimi, dosya boyutu sınırları, OCR fallback’i, tekrar eden başlık ve altbilgilerin temizlenmesi, tablo doğrulaması, checksum, versiyonlama ve gözlemlenebilirlik gerekir.

Ephemeral chat ile kalıcı kurumsal indeks aynı şey değildir

Doküman işleme pipeline’ı güvenilir hale geldikten sonra vector database ve retrieval yaşam döngüsü tasarlanır.

Geçici bir sohbet senaryosunda kullanıcının yüklediği dosyalar yalnızca aktif oturum boyunca tutulabilir. Bu durumda in-memory bir Chroma koleksiyonu pratik bir seçenek olabilir. Kalıcılık parametresi verilmediğinde koleksiyon süreç ömrüyle sınırlı kalır.[3]

from langchain_chroma import Chroma
from langchain_huggingface import HuggingFaceEmbeddings

embeddings = HuggingFaceEmbeddings(
    model_name="sentence-transformers/all-MiniLM-L6-v2"
)

# No persist_directory: the collection lives only for this session.
vector_store = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    collection_name="session_documents",
)

retriever = vector_store.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 5, "fetch_k": 20},
)

Kalıcı bir kurumsal bilgi tabanı ise farklı gereksinimler getirir: indeks versiyonlama, tenant veya departman izolasyonu, belge bazlı yetkilendirme, metadata filtreleri, silme ve güncelleme politikaları, yedekleme ve audit kayıtları. Aşağıdaki Qdrant örneği, yerel kalıcı storage ve retrieval sırasında tenant filtresi için temel bir yapı gösterir. Qdrant; local mode, self-hosted servis ve cloud deployment seçenekleriyle kullanılabilir.[4]

from langchain_huggingface import HuggingFaceEmbeddings
from langchain_qdrant import QdrantVectorStore
from qdrant_client import QdrantClient, models
from qdrant_client.http.models import Distance, VectorParams

embeddings = HuggingFaceEmbeddings(
    model_name="sentence-transformers/all-MiniLM-L6-v2"
)
client = QdrantClient(path="./qdrant_data")
collection = "company_knowledge"

if not client.collection_exists(collection):
    client.create_collection(
        collection_name=collection,
        vectors_config=VectorParams(size=384, distance=Distance.COSINE),
    )

vector_store = QdrantVectorStore(
    client=client,
    collection_name=collection,
    embedding=embeddings,
)
vector_store.add_documents(chunks)

# Enforce tenant or department isolation during retrieval.
retriever = vector_store.as_retriever(
    search_kwargs={
        "k": 5,
        "filter": models.Filter(
            must=[
                models.FieldCondition(
                    key="metadata.tenant_id",
                    match=models.MatchValue(value="tenant-42"),
                )
            ]
        ),
    }
)

Bu kod tek başına güvenlik sınırı değildir. Kullanıcının tenant_id veya erişim filtresini istemciden serbestçe göndermesine izin verilmemeli; filtreler kimliği doğrulanmış kullanıcı ve sunucu tarafındaki authorization policy üzerinden üretilmelidir.

Retrieval’ı bir tool olarak tasarlamak

Kurumsal AI sisteminde modelin vector database’e doğrudan ve sınırsız erişmesi yerine retrieval davranışını kontrollü bir tool üzerinden sunmak daha sağlıklı bir tasarımdır. Tool; hangi indeksin aranacağını, kaç sonucun getirileceğini, hangi metadata filtrelerinin uygulanacağını ve kaynak bilgisinin nasıl döndürüleceğini belirler.

from langchain_core.tools import tool

@tool
def search_company_knowledge(query: str) -> str:
    """Search approved internal sources and return grounded context."""
    documents = retriever.invoke(query)

    if not documents:
        return "No relevant approved source was found."

    passages = []
    for doc in documents[:5]:
        source = doc.metadata.get("source", "unknown")
        page = doc.metadata.get("page", "?")
        passages.append(
            f"[Source: {source}, page: {page}]\n{doc.page_content}"
        )

    return "\n\n".join(passages)

Bu katman, retrieval sonuçlarının ölçülmesini de kolaylaştırır. Recall@k, precision, answer groundedness, source coverage, latency ve cost-per-answer gibi metrikler ayrı ayrı izlenebilir.

Retrieval’dan inference katmanına

Retrieval sistemi kurulduktan sonra ilgili içerik, bir wrapper veya AI service aracılığıyla inference engine’e bağlanır. Bu servis yalnızca prompt iletmez. Kimlik doğrulama, authorization, model routing, context assembly, token budget, caching, logging, rate limiting, content controls ve kaynak gösterimi gibi sorumlulukları da üstlenir.

Arayüz katmanında OpenWebUI gibi self-hosted bir platform kullanılabilir. OpenWebUI; Ollama, vLLM ve OpenAI-compatible API sunan servislerle bağlanabilir.[5] Böylece kullanıcı deneyimi, kurumsal AI service ve seçilen inference altyapısı birbirinden ayrıştırılabilir.

flowchart TD
    U["Employee"] --> UI["Open WebUI"]
    UI --> S["AI service<br>OpenAI-compatible API"]
    S --> R["Retrieval tool"]
    R --> V[("Vector database")]
    S --> I["Inference engine"]

Sonuç: prototip değil, sistem tasarlayın

Kurumsal AI entegrasyonunda başarı, yalnızca güçlü bir model seçmekten gelmez. Değer; dokümanların doğru işlenmesi, retrieval kalitesinin ölçülmesi, erişim sınırlarının uygulanması, inference maliyetinin yönetilmesi ve kullanıcıların güvenebileceği bir deneyimin oluşturulmasıyla ortaya çıkar.

İyi bir demo birkaç günde hazırlanabilir. Üretimde çalışan bir sistem ise veri, retrieval, güvenlik, inference ve operasyon katmanlarının birlikte tasarlanmasını gerektirir.

LMXAI, kuruluşların enterprise AI mimarilerini doküman pipeline’ından retrieval kalitesine, inference ekonomisinden güvenlik ve benimsemeye kadar uçtan uca tasarlamasına ve değerlendirmesine yardımcı olur.