AI Engineering Academy · Pelajaran

Merancang Arsitektur Produksi

Pilih proyek puncak, buat sketsa arsitektur lengkap yang mencakup alur kerja RAG, lapisan agen, penyimpanan tembolok, keterpantauan, dan API, lalu dokumentasikan keputusan desain serta komprominya.

Merancang Arsitektur Produksi adalah pelajaran AI Engineering Academy gratis di CoddyKit. Ini adalah pelajaran 1 dari 4. Kamu bisa membaca pelajaran lengkapnya di bawah secara gratis — lalu praktikkan langsung di browser dengan editor kode bawaan dan tutor AI 24/7. Ini adalah bagian dari jalur belajar AI Engineering Academy, dan progresmu tersinkronisasi di web dan aplikasi CoddyKit. Kursus AI Engineering Academy mencakup 4 pelajaran total.

Memilih Proyek Akhir

Proyek akhir menyatukan semua hal dari jalur pembelajaran ini: RAG, agen, streaming, caching, observabilitas, dan keamanan. Proyek akhir yang baik memiliki kompleksitas yang bermakna—memerlukan setidaknya tiga komponen AI yang berbeda—namun cakupannya cukup kecil untuk diselesaikan dalam hitungan hari, bukan bulan. Contoh klasiknya adalah asisten tanya jawab dokumen siap produksi, agen riset otonom dengan pengawasan manusia dalam prosesnya, atau pipeline ekstraksi data perusahaan.

Mengidentifikasi Komponen Sistem

Mulailah dengan mencantumkan komponen berbeda yang diperlukan sistem Anda. Proyek rekayasa AI produksi biasanya mencakup: lapisan pemasukan (pemuatan dokumen, pemenggalan, pembuatan embedding, pengindeksan penyimpanan vektor), lapisan pengambilan (pencarian hibrida, pemeringkatan ulang), lapisan agen (pemanggilan fungsi, eksekusi alat), lapisan API (backend FastAPI, endpoint streaming), dan lapisan observabilitas (pelacakan, metrik, peringatan). Buat sketsa aliran data di antara komponen tersebut sebelum menulis kode.

# 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
]

Memilih Tumpukan Teknologi yang Tepat

Pilih teknologi berdasarkan tingkat familiaritas tim dan persyaratan sistem yang sebenarnya, bukan berdasarkan kebaruan. Tumpukan teknologi bawaan yang masuk akal: FastAPI untuk lapisan API, pgvector untuk penyimpanan vektor (menggunakan kembali infrastruktur PostgreSQL yang sudah ada), LangChain LCEL untuk komposisi pipeline, Redis untuk caching semantik dan status pembatasan laju, LangSmith untuk pelacakan, dan PostgreSQL untuk data pengguna serta hasil evaluasi. Tambahkan komponen hanya jika opsi yang lebih sederhana tidak memenuhi persyaratan.

# 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'),
}

Menggambar Diagram Arsitektur

Dokumentasikan arsitektur sistem sebagai diagram aliran data yang menunjukkan setiap komponen, data yang mengalir di antara komponen tersebut, serta arah alirannya. Sertakan jalur pemasukan (luring: dokumen → potongan → embedding → penyimpanan vektor) dan jalur kueri (daring: kueri pengguna → pemeriksaan cache → pengambilan → pemeringkatan ulang → LLM → tanggapan streaming). Diagram ini menjadi panduan utama implementasi dan membantu anggota tim baru memahami sistem secara langsung.

# 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)

Menentukan Kontrak API Sejak Awal

Tentukan endpoint API serta skema permintaan/tanggapannya dalam FastAPI sebelum menerapkan logika backend. Hal ini menciptakan kontrak antara API dan konsumen frontend mana pun serta memungkinkan pengembangan paralel. Dokumentasikan setiap endpoint dengan deskripsi OpenAPI. Minimal, tentukan endpoint untuk: pemasukan dokumen, obrolan/kueri, riwayat percakapan, hasil evaluasi, dan kesehatan sistem.

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

Memperkirakan dan Menganggarkan Biaya

Perkirakan biaya API bulanan sistem Anda sebelum menulis satu baris pun kode backend. Hitung: jumlah pengguna aktif harian yang diperkirakan × kueri per pengguna × rata-rata token per kueri. Untuk sistem dengan 100 DAU, 10 kueri per hari, dan 3.000 token per kueri dengan harga GPT-4o, jumlahnya adalah 3 juta token per hari—kira-kira $45 per hari atau $1.350 per bulan. Perkiraan ini memberi tahu Anda apakah sistem layak secara ekonomi dan optimasi mana (caching, perutean model) yang layak diterapkan.

# 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}')

Merencanakan Pipeline Pemasukan

Rancang pipeline pemasukan sebagai proses batch luring yang berjalan sesuai permintaan atau jadwal. Tentukan jenis dokumen yang akan didukung (PDF, DOCX, HTML, teks biasa), strategi pemenggalan, model embedding, dan bidang metadata yang akan disimpan bersama setiap vektor. Metadata sangat penting untuk pengambilan terfilter—tanpanya, Anda tidak dapat membatasi pencarian pada dokumen dari rentang tanggal, penulis, atau kategori tertentu.

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
}

Keputusan Arsitektur Keamanan

Buat keputusan keamanan sejak awal, bukan dengan menambahkannya belakangan. Tentukan: cara pengguna melakukan autentikasi (JWT, kunci API), data yang dapat diambil oleh setiap pengguna (keamanan tingkat baris dalam kueri pgvector), cara mendeteksi injeksi prompt, pemeriksaan keluaran yang diterapkan, dan tindakan yang memerlukan konfirmasi multifaktor. Setiap keputusan memiliki implikasi kinerja yang memengaruhi pilihan arsitektur di seluruh sistem.

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'
}

Menentukan Metrik Keberhasilan

Tentukan seperti apa keberhasilan sistem Anda sebelum membangunnya. Serangkaian kriteria keberhasilan yang konkret dan terukur menjaga fokus pengembangan serta memberi Anda kriteria jelas untuk melanjutkan atau tidak melanjutkan penerapan. Sertakan metrik untuk: kualitas (skor evaluasi pada set pengujian), latensi (TTFT p95 dan total), biaya (sasaran biaya per kueri), serta keandalan (SLA waktu aktif). Cantumkan semua ini di README proyek agar semua kontributor memiliki sasaran yang sama.

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
}

Mendokumentasikan Pertukaran dalam Arsitektur

Setiap keputusan arsitektur melibatkan pertukaran. Dokumentasikan hal tersebut secara eksplisit dalam Architecture Decision Record (ADR): keputusan yang dibuat, alternatif yang dipertimbangkan, dan alasan opsi tersebut dipilih. Contohnya: “Memilih pgvector daripada Pinecone karena kami sudah menjalankan PostgreSQL, sehingga mengurangi beban operasional. Pertukarannya: skala maksimum terbatas hingga sekitar 10 juta vektor tanpa sharding.” Anggota tim di masa mendatang akan berterima kasih atas transparansi ini.

# 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

Membuat Sketsa Topologi Penerapan

Tentukan cara sistem Anda akan diterapkan sebelum menulis kode infrastruktur apa pun. Petakan setiap komponen ke unit penerapan: backend FastAPI sebagai kontainer Docker, pipeline pemasukan sebagai layanan pekerja terpisah, pgvector sebagai instans PostgreSQL terkelola, dan Redis sebagai cache terkelola. Tentukan komponen mana yang tanpa status (dapat diskalakan secara horizontal) dan mana yang memiliki status (memerlukan strategi penskalaan yang cermat). Diagram penerapan menghemat waktu pengerjaan ulang nantinya.

# 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

Pemeriksaan Singkat

Uji pemahaman Anda tentang rancangan arsitektur sistem AI produksi.

Rangkuman Pelajaran

Dalam pelajaran ini, Anda mempelajari bahwa inventaris komponen dan diagram aliran data menciptakan visi arsitektur bersama sebelum pengodean dimulai, kontrak API yang ditentukan sejak awal memungkinkan pengembangan paralel dan memperjelas persyaratan, serta metrik keberhasilan yang ditentukan sebelumnya menjaga keselarasan tim terhadap sasaran kualitas, latensi, biaya, dan keandalan. Selanjutnya, kita akan menerapkan fitur inti RAG dan agen.

Pertanyaan yang Sering Diajukan

Apakah pelajaran “Merancang Arsitektur Produksi” gratis?

Ya — teks lengkap “Merancang Arsitektur Produksi” gratis dibaca di sini di web. Untuk praktiknya secara interaktif (editor kode bawaan dan tutor AI 24/7) dan buka sisa kursus AI Engineering Academy, upgrade ke CoddyKit PRO. Kursus AI Engineering Academy mencakup 4 pelajaran total.

Apa yang akan aku pelajari di “Merancang Arsitektur Produksi”?

Pilih proyek puncak, buat sketsa arsitektur lengkap yang mencakup alur kerja RAG, lapisan agen, penyimpanan tembolok, keterpantauan, dan API, lalu dokumentasikan keputusan desain serta komprominya. Kamu berlatih AI Engineering Academy dengan kode praktik yang langsung kamu jalankan di browser, dan tutor AI 24/7 menjawab pertanyaanmu saat kamu mengerjakan pelajaran ini.

Apakah aku perlu pengalaman untuk memulai AI Engineering Academy?

Tidak diperlukan pengalaman sebelumnya. AI Engineering Academy di CoddyKit dirancang untuk pemula hingga pelajar tingkat lanjut, jadi kamu bisa memulai di sini atau dari awal dan belajar sesuai kecepatan kamu sendiri. Ini adalah pelajaran 1 dari 4.

Berapa lama pelajaran “Merancang Arsitektur Produksi” memakan waktu?

Sebagian besar pelajaran CoddyKit memakan waktu sekitar 5–10 menit. Setiap pelajaran ringkas dan interaktif, jadi kamu membuat kemajuan stabil dan melanjutkan dari tempat kamu tinggalkan di web dan aplikasi.

Bisakah aku menulis dan menjalankan kode dalam pelajaran AI Engineering Academy ini?

Ya. Setiap pelajaran AI Engineering Academy menyertakan editor kode bawaan, jadi kamu menulis dan menjalankan kode nyata langsung di browser dan mendapatkan umpan balik AI instan — tidak diperlukan penyiapan lokal.

Semua pelajaran dalam kursus ini

Merancang Arsitektur Produksi
Menerapkan Fitur Inti RAG dan Agen
Memperkuat Sistem: Keamanan, Penyimpanan Tembolok, dan Keandalan
Evaluasi, Penerapan, dan Retrospektif

← Kembali ke AI Engineering Academy