AI Engineering Academy · Ders

Üretim Mimarisi Tasarlama

1. ders / 413 adım

Üretim Mimarisi Tasarlama, CoddyKit'te ücretsiz bir AI Engineering Academy dersidir. Bu, 4 dersinin 1. dersidir. Aşağıdan dersin tamamını ücretsiz okuyabilir, sonra tarayıcıda yerleşik kod editörü ve 7/24 yapay zeka koçu ile uygulamalı olarak pratik yapabilirsin. Bu, AI Engineering Academy öğrenme yolunun bir parçasıdır ve ilerlemeniz web ve CoddyKit uygulaması arasında senkronize olur. AI Engineering Academy kursu toplamda 4 dersten oluşur.

Bitirme Projesi Seçmek

Bitirme projesi, bu öğrenim yolundaki her şeyi bir araya getirir: RAG, aracılar, akış, önbelleğe alma, gözlemlenebilirlik ve güvenlik. İyi bir bitirme projesi anlamlı ölçüde karmaşık olmalı — en az üç farklı yapay zekâ bileşeni gerektirmeli — ancak aylar yerine günler içinde yayımlanabilecek kadar sınırlı kapsamlı olmalıdır. Klasik örnekler arasında üretim kalitesinde bir belge soru-cevap asistanı, insan denetimli özerk bir araştırma aracısı veya kurumsal veri çıkarma hattı bulunur.

Sistem Bileşenlerini Belirlemek

Sisteminizin ihtiyaç duyduğu farklı bileşenleri listeleyerek başlayın. Üretim amaçlı bir yapay zekâ mühendisliği projesi genellikle şunları içerir: alma katmanı (belge yükleme, parçalara ayırma, gömme ve vektör deposu dizinleme), getirme katmanı (hibrit arama ve yeniden sıralama), aracı katmanı (işlev çağırma ve araç yürütme), API katmanı (FastAPI arka ucu ve akış uç noktaları) ve gözlemlenebilirlik katmanı (izleme, ölçümler ve uyarılar). Kod yazmadan önce aralarındaki veri akışını taslak olarak çizin.

# Component inventory for a Document QA Assistant:
COMPONENTS = [
    'document_ingestion',   # PDF/Word -> chunks -> embeddings -> pgvector
    'hybrid_retriever',     # BM25 + dense + RRF
    'reranker',             # Cohere rerank
    'qa_agent',             # GPT-4o with RAG + function calling
    'semantic_cache',       # Redis + embedding similarity
    'streaming_api',        # FastAPI StreamingResponse
    'tracing',              # LangSmith or Langfuse
    'prompt_injection_filter', # Input sanitization
    'eval_pipeline',        # Automated quality scoring
]

Doğru Teknoloji Yığınını Seçmek

Teknolojiyi yeniliğinden çok ekibinizin aşinalığına ve sistemin gerçek gereksinimlerine göre seçin. Makul bir varsayılan yığın şudur: API katmanı için FastAPI, vektör depolama için pgvector (mevcut PostgreSQL altyapısını yeniden kullanır), hat bileşimi için LangChain LCEL, anlamsal önbelleğe alma ve hız sınırı durumu için Redis, izleme için LangSmith ve kullanıcı verileri ile değerlendirme sonuçları için PostgreSQL. Daha basit seçenekler gereksinimleri karşılamadığında bileşen ekleyin.

# Technology decisions and their rationale
STACK = {
    'api':           ('FastAPI',    'Async support, OpenAPI docs, streaming easy'),
    'vector_store':  ('pgvector',   'Already on PostgreSQL, no extra infra'),
    'llm_primary':   ('gpt-4o',     'Best quality for the use case'),
    'llm_fallback':  ('claude-3.5', 'Different provider for resilience'),
    'cache':         ('Redis',      'Sub-ms lookup, TTL support built-in'),
    'tracing':       ('LangSmith',  'Native LangChain integration'),
    'embedding':     ('text-embedding-3-small', 'Good quality, low cost'),
    'reranker':      ('Cohere',     'Best-in-class rerank API'),
}

Mimari Diyagramını Çizmek

Sistem mimarisini, her bileşeni, aralarında akan veriyi ve akış yönünü gösteren bir veri akışı diyagramı olarak belgeleyin. Hem alma yolunu (çevrimdışı: belgeler → parçalar → gömmeler → vektör deposu) hem de sorgu yolunu (çevrimiçi: kullanıcı sorgusu → önbellek denetimi → getirme → yeniden sıralama → LLM → akış yanıtı) ekleyin. Bu diyagram, uygulama sürecinde yol göstericiniz olur ve yeni ekip üyelerinin sistemi hemen anlamasına yardımcı olur.

# Data flow (ASCII art):
#
# INGESTION PATH (offline):
# Documents --> Loader --> Chunker --> Embedder --> pgvector
#                                             |
#                                         BM25 index
#
# QUERY PATH (online):
# User Query
#    |-> Semantic Cache (hit: return) -> miss:
#    |-> Hybrid Retriever (BM25 + dense)
#    |-> Cohere Reranker
#    |-> LangChain LCEL Chain
#    |-> GPT-4o (streaming) --> FastAPI StreamingResponse
#    |-> LangSmith (trace every step)

API Sözleşmelerini Erkenden Tanımlamak

Arka uç mantığını uygulamadan önce FastAPI'de API uç noktalarınızı ve istek/yanıt şemalarınızı tanımlayın. Bu, API ile onu kullanacak ön yüzler arasında bir sözleşme oluşturur ve paralel geliştirmeyi mümkün kılar. Her uç noktayı OpenAPI açıklamalarıyla belgeleyin. En azından şu uç noktaları tanımlayın: belge alma, sohbet/sorgu, konuşma geçmişi, değerlendirme sonuçları ve sistem durumu.

from fastapi import FastAPI
from pydantic import BaseModel

app = FastAPI(title='Document QA Assistant', version='1.0')

class QueryRequest(BaseModel):
    question: str
    conversation_id: str | None = None
    max_chunks: int = 5
    stream: bool = True

class QueryResponse(BaseModel):
    answer: str
    sources: list
    cached: bool
    latency_ms: int
    trace_id: str

@app.post('/query', response_model=QueryResponse)
async def query_endpoint(request: QueryRequest):
    pass  # implementation next lesson

Maliyetleri Tahmin Etmek ve Bütçelemek

Tek bir arka uç kodu satırı yazmadan önce sisteminizin aylık API maliyetini tahmin edin. Şunları hesaplayın: beklenen günlük etkin kullanıcı sayısı × kullanıcı başına sorgu sayısı × sorgu başına ortalama belirteç sayısı. 100 DAU, günde 10 sorgu ve sorgu başına 3.000 belirteç kullanan bir sistemde, GPT-4o fiyatlandırmasıyla bu günde 3 milyon belirteç — yaklaşık 45 ABD doları/gün veya 1.350 ABD doları/ay — demektir. Bu tahmin, sistemin ekonomik açıdan uygulanabilir olup olmadığını ve hangi iyileştirmelerin (önbelleğe alma, model yönlendirme) uygulanmaya değer olduğunu gösterir.

# Cost estimation model
DAU = 100           # daily active users
QPD = 10            # queries per user per day
TOKENS_PER_QUERY = {
    'prompt_tokens': 2000,  # system + context + question
    'completion_tokens': 500
}

PRICE_GPT4O_INPUT = 2.50 / 1_000_000   # per token
PRICE_GPT4O_OUTPUT = 10.00 / 1_000_000  # per token

daily_cost = DAU * QPD * (
    TOKENS_PER_QUERY['prompt_tokens'] * PRICE_GPT4O_INPUT +
    TOKENS_PER_QUERY['completion_tokens'] * PRICE_GPT4O_OUTPUT
)
print(f'Daily: ${daily_cost:.2f}, Monthly: ${daily_cost * 30:.2f}')

Alma Hattını Planlamak

Alma hattını isteğe bağlı olarak veya zamanlanmış biçimde çalışan çevrimdışı bir toplu işlem olarak tasarlayın. Destekleyeceğiniz belge türlerini (PDF, DOCX, HTML, düz metin), parçalara ayırma stratejisini, gömme modelini ve her vektörle birlikte saklanacak üst veri alanlarını belirleyin. Üst veriler, filtrelenmiş getirme için kritik öneme sahiptir — bunlar olmadan aramayı belirli bir tarih aralığındaki, yazardaki veya kategorideki belgelerle sınırlayamazsınız.

from dataclasses import dataclass
from typing import Optional

@dataclass
class ChunkMetadata:
    doc_id: str
    source_file: str
    page_number: Optional[int]
    section_title: Optional[str]
    created_at: str
    author: Optional[str]
    doc_type: str  # 'pdf', 'docx', 'html'

# Ingestion config
INGESTION_CONFIG = {
    'chunk_size': 800,
    'chunk_overlap': 100,
    'embedding_model': 'text-embedding-3-small',
    'embedding_dimensions': 1536,
    'batch_size': 100,  # chunks per embedding API call
}

Güvenlik Mimarisi Kararları

Güvenlik kararlarını sonradan eklemek yerine en başta alın. Şunları belirleyin: kullanıcıların nasıl kimlik doğrulayacağı (JWT, API anahtarları), kullanıcı başına hangi verilerin getirilebileceği (pgvector sorgularında satır düzeyi güvenlik), istem enjeksiyonunun nasıl algılanacağı, hangi çıktı taramasının uygulanacağı ve hangi eylemlerin çok faktörlü onay gerektireceği. Her kararın, sistem genelindeki mimari seçimlerini etkileyen performans sonuçları vardır.

SECURITY_DECISIONS = {
    'auth': 'JWT with 24h expiry',
    'data_isolation': 'tenant_id column in all vector metadata, filter on every query',
    'injection_detection': 'rule-based pre-filter + LLM secondary check for complex inputs',
    'output_scanning': 'check for PII, system prompt leakage patterns',
    'destructive_actions': 'require confirmation token for delete operations',
    'rate_limiting': '20 queries/minute per user, 429 with Retry-After header',
    'key_storage': 'AWS Secrets Manager, rotated every 90 days'
}

Başarı Ölçütlerini Tanımlamak

Sisteminizi oluşturmadan önce başarının neye benzediğini tanımlayın. Somut ve ölçülebilir başarı ölçütleri, geliştirmeyi odaklı tutar ve dağıtım için net devam et/etme kararları vermenizi sağlar. Şu ölçümleri ekleyin: kalite (test kümesindeki değerlendirme puanı), gecikme (p95 TTFT ve toplam süre), maliyet (sorgu başına hedef maliyet) ve güvenilirlik (çalışırlık SLA'sı). Tüm katkıda bulunanların aynı hedefi paylaşması için bunları projenin README dosyasına ekleyin.

SUCCESS_METRICS = {
    # Quality
    'min_correctness_score': 4.0,       # out of 5, LLM-as-judge
    'min_retrieval_hit_rate': 0.85,     # top-5 chunk contains answer
    # Latency
    'p95_ttft_ms': 800,                 # time to first token
    'p95_total_latency_ms': 8000,       # full response
    # Cost
    'max_cost_per_query_usd': 0.05,     # $0.05 per Q&A
    # Reliability
    'target_uptime': 0.999,             # 99.9%
    'cache_hit_rate_target': 0.25,      # 25% queries served from cache
}

Mimari Ödünleşimleri Belgelemek

Her mimari kararı ödünleşimler içerir. Bunları bir Mimari Karar Kaydı (ADR) içinde açıkça belgeleyin: hangi kararın alındığı, hangi alternatiflerin değerlendirildiği ve bu seçeneğin neden tercih edildiği. Örneğin: "Zaten PostgreSQL çalıştırdığımız ve işletim yükünü azalttığı için Pinecone yerine pgvector'ı seçtik. Ödünleşim: parçalama olmadan en yüksek ölçek yaklaşık 10 milyon vektörle sınırlıdır." Gelecekteki ekip üyeleri bu şeffaflık için size teşekkür edecektir.

# Architecture Decision Records (ADRs):
#
# ADR-001: Use pgvector for vector storage
# Decision: pgvector in existing PostgreSQL
# Alternatives: Pinecone, Weaviate, Qdrant
# Reason: No new infra, row-level security native, familiar operations
# Trade-offs: Limited to ~5M vectors before performance degrades
#
# ADR-002: GPT-4o as primary model
# Decision: gpt-4o for all user-facing queries
# Alternatives: gpt-4o-mini (cheaper), Claude (alternative)
# Reason: Highest quality for use case, Claude as fallback
# Trade-offs: $0.04/query vs $0.002 for gpt-4o-mini

Dağıtım Topolojisini Taslak Olarak Çizmek

Herhangi bir altyapı kodu yazmadan önce sisteminizin nasıl dağıtılacağını belirleyin. Her bileşeni bir dağıtım birimiyle eşleştirin: Docker kapsayıcısı olarak FastAPI arka ucu, ayrı bir çalışan hizmeti olarak alma hattı, yönetilen bir PostgreSQL örneği olarak pgvector ve yönetilen bir önbellek olarak Redis. Hangi bileşenlerin durumsuz (yatay olarak ölçeklenebilir), hangilerinin durum bilgili (dikkatli ölçekleme stratejileri gerektiren) olduğunu belirtin. Bir dağıtım diyagramı, ileride saatler sürecek yeniden çalışmayı önler.

# Deployment topology:
#
# Internet -> Load Balancer (AWS ALB)
#                |
#            FastAPI API  (stateless, 2-4 containers, auto-scale)
#                |
#         +------+------+
#         |             |
#    pgvector        Redis Cache
#  (AWS RDS Postgres) (Elasticache)
#         |
#    Ingestion Worker  (separate container, manual trigger)
#         |
#    LangSmith (external SaaS, traces only)
#
# All containers in same VPC, no public access to DB/cache

Hızlı Kontrol

Üretim amaçlı yapay zekâ sistemi mimarisi tasarımı konusundaki anlayışınızı sınayın.

İnteraktif derste cevapla

Ders Özeti

Bu derste şunları öğrendiniz: bileşen envanteri ve veri akışı diyagramları, kodlama başlamadan önce ortak bir mimari vizyon oluşturur; önceden tanımlanan API sözleşmeleri, paralel geliştirmeyi mümkün kılar ve gereksinimleri açık hâle getirir; önceden tanımlanan başarı ölçütleri ise ekibin kalite, gecikme, maliyet ve güvenilirlik hedeflerinde uyumlu kalmasını sağlar. Sırada temel RAG ve aracı özelliklerini uyguluyoruz.

Başlamak ücretsiz

Yapay zeka eğitmeniyle Python öğren — ücretsiz

Tarayıcında gerçek kod yaz ve çalıştır, 7/24 yapay zeka eğitmeninden anında yardım al; web'de ya da uygulamada kaldığın yerden devam et.

Kurslar: 30
Dersler: 120

Ücretsiz öğrenmeye başla Tüm kursu görüntüle

Sıkça Sorulan Sorular

“Üretim Mimarisi Tasarlama” dersi ücretsiz mi?

Evet — “Üretim Mimarisi Tasarlama” dersin tüm metni burada web'de ücretsiz olarak okunabilir. Etkileşimli olarak pratik yapmak (yerleşik kod editörü ve 7/24 yapay zeka koçu) ve AI Engineering Academy kursunun geri kalanını açmak için CoddyKit PRO'ya yükselt. AI Engineering Academy kursu toplamda 4 dersten oluşur.

“Üretim Mimarisi Tasarlama” dersinde ne öğreneceğim?

Bir bitirme projesi seçin, RAG hattı, aracı katmanı, önbellekleme, gözlemlenebilirlik ve API dâhil olmak üzere tüm mimarinin taslağını çıkarın; ardından tasarım kararlarını ve ödünleşimleri belgeleyi… AI Engineering Academy ile uygulamalı kodu tarayıcıda doğrudan çalıştırarak pratik yaparsın ve 7/24 yapay zeka koçu dersi çalışırken sorularını yanıtlar.

AI Engineering Academy öğrenmeye başlamak için deneyim gerekli mi?

Önceden deneyim gerekmez. CoddyKit'te AI Engineering Academy, başlangıçtan ileri seviyeye kadar yapılandırıldığı için buradan başlayabilir veya başından başlayıp kendi hızında ilerleme yapabilirsin. Bu, 4 dersinin 1. dersidir.

“Üretim Mimarisi Tasarlama” dersi ne kadar sürer?

Çoğu CoddyKit dersi yaklaşık 5–10 dakika sürer. Her biri kısa ve etkileşimli olduğu için sabit ilerleme yaparsın ve web ile uygulama arasında tam olarak bıraktığın yerden devam edebilirsin.

Bu AI Engineering Academy dersinde kod yazıp çalıştırabilir miyim?

Evet. Her AI Engineering Academy dersi yerleşik bir kod editörü içerir, bu sayede tarayıcıda gerçek kod yazıp çalıştırabilir ve anlık yapay zeka geri bildirimi alırsın — yerel kurulum gerekli değildir.

Bu kursun tüm dersleri

Üretim Mimarisi Tasarlama
Temel RAG ve Aracı Özelliklerini Uygulama
Sağlamlaştırma: Güvenlik, Önbellekleme ve Güvenilirlik
Değerlendirme, Dağıtım ve Geriye Dönük Değerlendirme

← AI Engineering Academy Sayfasına Dön