AI Engineering Academy · Lektion

Design af produktionsarkitekturen

Vælg et afsluttende projekt, skitser den fulde arkitektur inklusive RAG-pipeline, agentlag, caching, observability og API, og dokumentér derefter designbeslutningerne og afvejningerne.

Lektion 1 af 413 trin

Design af produktionsarkitekturen er en gratis AI Engineering Academy-lektion på CoddyKit. Dette er lektion 1 af 4. Du kan læse hele lektionen gratis nedenfor — og derefter øve dig praktisk i browseren med en indbygget kodeeditor og en AI-vejleder, der er tilgængelig døgnet rundt. Den er en del af læringsforløbet i AI Engineering Academy, og dine fremskridt synkroniseres på tværs af nettet og CoddyKit-appen. AI Engineering Academy-kurset indeholder 4 lektioner i alt.

Valg af et afsluttende projekt

Det afsluttende projekt samler alt fra sporet: RAG, agenter, streaming, caching, observerbarhed og sikkerhed. Et godt afsluttende projekt er meningsfuldt komplekst — det skal kræve mindst tre forskellige AI-komponenter — men samtidig være afgrænset nok til at kunne lanceres på dage frem for måneder. Klassiske eksempler er en dokumentbaseret spørgsmål-og-svar-assistent i produktionskvalitet, en autonom researchagent med menneskelig kontrol eller en pipeline til dataudtræk i en virksomhed.

Identifikation af systemkomponenter

Start med at opliste de forskellige komponenter, som dit system har brug for. Et AI-teknikprojekt til produktion omfatter typisk: et indlæsningslag (indlæsning af dokumenter, opdeling i tekststykker, embedding og indeksering i et vektorlager), et søgelag (hybridsøgning og genrangering), et agentlag (funktionskald og udførelse af værktøjer), et API-lag (FastAPI-backend og streaming-endpoints) samt et observerbarhedslag (sporing, målinger og alarmer). Tegn dataflowet mellem dem, før du skriver 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
]

Valg af den rigtige teknologistak

Vælg teknologi ud fra dit teams kendskab og systemets faktiske krav i stedet for nyhedsværdi. En fornuftig standardstak er: FastAPI til API-laget, pgvector til vektorlageret (genbruger den eksisterende PostgreSQL-infrastruktur), LangChain LCEL til sammensætning af pipelines, Redis til semantisk caching og tilstand for hastighedsbegrænsning, LangSmith til sporing og PostgreSQL til brugerdata og evalueringsresultater. Tilføj kun komponenter, når enklere muligheder ikke opfylder kravene.

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

Tegning af arkitekturdiagrammet

Dokumentér systemarkitekturen som et dataflowdiagram, der viser hver komponent, de data der flyder mellem dem, og flowets retning. Medtag både indlæsningsvejen (offline: dokumenter → tekststykker → embeddings → vektorlager) og forespørgselsvejen (online: brugerforespørgsel → cachekontrol → søgning → genrangering → LLM → streamet svar). Dette diagram er din ledestjerne under implementeringen og hjælper nye teammedlemmer med straks at forstå systemet.

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

Definition af API-kontrakter tidligt

Definér dine API-endpoints og deres skemaer for anmodninger og svar i FastAPI, før du implementerer backendlogikken. Det skaber en kontrakt mellem API'et og eventuelle frontendforbrugere og muliggør parallel udvikling. Dokumentér hvert endpoint med OpenAPI-beskrivelser. Som minimum skal du definere endpoints til: dokumentindlæsning, chat/forespørgsler, samtalehistorik, evalueringsresultater og systemtilstand.

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

Estimering og budgettering af omkostninger

Estimér systemets månedlige API-omkostninger, før du skriver en eneste linje backendkode. Beregn: forventede dagligt aktive brugere × forespørgsler pr. bruger × gennemsnitligt antal tokens pr. forespørgsel. For et system med 100 DAU, 10 forespørgsler om dagen og 3.000 tokens pr. forespørgsel til GPT-4o-priser svarer det til 3 millioner tokens om dagen — cirka 45 USD om dagen eller 1.350 USD om måneden. Estimatet fortæller dig, om systemet er økonomisk bæredygtigt, og hvilke optimeringer (caching og modelrouting) der er værd at implementere.

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

Planlægning af indlæsningspipelinjen

Design indlæsningspipelinjen som en offline-batchproces, der kører efter behov eller efter en tidsplan. Definér, hvilke dokumenttyper du vil understøtte (PDF, DOCX, HTML og almindelig tekst), strategien for opdeling i tekststykker, embedding-modellen og de metadatafelter, der skal gemmes sammen med hver vektor. Metadata er afgørende for filtreret søgning — uden dem kan du ikke begrænse søgningen til dokumenter fra et bestemt datointerval, en bestemt forfatter eller en bestemt kategori.

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
}

Beslutninger om sikkerhedsarkitektur

Træf sikkerhedsbeslutninger på forhånd i stedet for at tilføje dem bagefter. Definér: hvordan brugere godkender sig (JWT og API-nøgler), hvilke data der kan hentes af den enkelte bruger (sikkerhed på rækkeniveau i pgvector-forespørgsler), hvordan prompt injection opdages, hvilken scanning af output der anvendes, og hvilke handlinger der kræver bekræftelse med flere faktorer. Hver beslutning har betydning for ydeevnen og påvirker arkitekturvalgene i hele systemet.

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

Definition af succesmålinger

Definér, hvordan succes ser ud for dit system, før du bygger det. Et sæt konkrete, målbare succeskriterier holder udviklingen fokuseret og giver dig klare kriterier for, om systemet skal lanceres. Medtag målinger for: kvalitet (evalueringsscore på testsættet), forsinkelse (p95 TTFT og samlet tid), omkostninger (mål for omkostning pr. forespørgsel) og pålidelighed (oppetids-SLA). Placér dem i projektets README, så alle bidragydere arbejder efter det samme mål.

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
}

Dokumentation af arkitekturafvejninger

Alle arkitekturbeslutninger indebærer afvejninger. Dokumentér dem tydeligt i en Architecture Decision Record (ADR): hvilken beslutning der blev truffet, hvilke alternativer der blev overvejet, og hvorfor denne mulighed blev valgt. For eksempel: »Vi valgte pgvector frem for Pinecone, fordi vi allerede kører PostgreSQL, hvilket reducerer den operationelle byrde. Afvejning: Den maksimale skala er begrænset til cirka 10 millioner vektorer uden sharding.« Fremtidige teammedlemmer vil sætte pris på denne gennemsigtighed.

# 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

Skitsering af deploymenttopologien

Definér, hvordan dit system skal deployeres, før du skriver infrastrukturkode. Knyt hver komponent til en deploymentenhed: FastAPI-backenden som en Docker-container, indlæsningspipelinjen som en separat workertjeneste, pgvector som en administreret PostgreSQL-instans og Redis som en administreret cache. Angiv, hvilke komponenter der er tilstandsløse (og kan skaleres horisontalt), og hvilke der er tilstandsfulde (og kræver omhyggelige skaleringsstrategier). Et deploymentdiagram sparer dig for timevis af omarbejde senere.

# 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

Hurtigt tjek

Test din forståelse af design af AI-systemarkitektur til produktion.

Besvar den i den interaktive lektion

Opsummering af lektionen

I denne lektion lærte du, at komponentoversigter og dataflowdiagrammer skaber en fælles arkitektonisk vision, før kodningen begynder, at API-kontrakter defineret på forhånd muliggør parallel udvikling og tydeliggør kravene, og at succesmålinger defineret på forhånd holder teamet samstemt om mål for kvalitet, forsinkelse, omkostninger og pålidelighed. Næste gang implementerer vi de centrale RAG- og agentfunktioner.

Gratis at komme i gang

Lær Python med en AI-underviser — gratis

Skriv og kør rigtig kode i din browser, få øjeblikkelig hjælp fra en AI-underviser døgnet rundt, og fortsæt, hvor du slap, på web eller i appen.

Kurser: 30
Lektioner: 120

Start gratis Se hele kurset

Ofte stillede spørgsmål

Er lektionen “Design af produktionsarkitekturen” gratis?

Ja — hele teksten til “Design af produktionsarkitekturen” kan læses gratis her på nettet. Hvis du vil øve dig interaktivt med en indbygget kodeeditor og en AI-vejleder døgnet rundt og få adgang til resten af AI Engineering Academy-kurset, skal du opgradere til CoddyKit PRO. AI Engineering Academy-kurset indeholder 4 lektioner i alt.

Hvad lærer jeg i “Design af produktionsarkitekturen”?

Vælg et afsluttende projekt, skitser den fulde arkitektur inklusive RAG-pipeline, agentlag, caching, observability og API, og dokumentér derefter designbeslutningerne og afvejningerne. Du øver dig i AI Engineering Academy med praktisk kode, som du kører direkte i browseren, og en AI-vejleder døgnet rundt besvarer dine spørgsmål, mens du arbejder dig gennem lektionen.

Skal jeg have erfaring for at begynde på AI Engineering Academy?

Der kræves ingen tidligere erfaring. AI Engineering Academy på CoddyKit er tilrettelagt for både begyndere og øvede, så du kan starte her eller fra begyndelsen og lære i dit eget tempo. Dette er lektion 1 af 4.

Hvor lang tid tager lektionen “Design af produktionsarkitekturen”?

De fleste CoddyKit-lektioner tager cirka 5–10 minutter. Hver lektion er kort og interaktiv, så du gør løbende fremskridt og kan fortsætte, hvor du slap – på både web og app.

Kan jeg skrive og køre kode i denne AI Engineering Academy-lektion?

Ja. Alle AI Engineering Academy-lektioner har en indbygget kodeeditor, så du kan skrive og køre rigtig kode direkte i din browser og få øjeblikkelig feedback fra AI – uden lokal opsætning.

Alle lektioner i dette kursus

Design af produktionsarkitekturen
Implementering af centrale RAG- og agentfunktioner
Hærdning: sikkerhed, caching og pålidelighed
Evaluering, deployment og retrospektiv

← Tilbage til AI Engineering Academy