Concevoir l’architecture de production
Choisissez un projet de synthèse, esquissez l’architecture complète, notamment le pipeline RAG, la couche d’agent, la mise en cache, l’observabilité et l’API, puis documentez les choix de conception et les compromis.
Concevoir l’architecture de production est une leçon AI Engineering Academy gratuite sur CoddyKit. Ceci est la leçon 1 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage AI Engineering Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours AI Engineering Academy comprend 4 leçons au total.
Choisir un projet de synthèse
Le projet de synthèse rassemble tout ce qui a été abordé dans le parcours : RAG, agents, diffusion en continu, mise en cache, observabilité et sécurité. Un bon projet de synthèse est suffisamment complexe sur le plan fonctionnel — il nécessite au moins trois composants d'IA distincts — tout en étant assez limité pour être livré en quelques jours plutôt qu'en quelques mois. Parmi les exemples classiques figurent un assistant de questions-réponses sur des documents, de qualité production, un agent de recherche autonome avec supervision humaine, ou une pipeline d'extraction de données d'entreprise.
Identifier les composants du système
Commencez par dresser la liste des composants distincts nécessaires à votre système. Un projet d'ingénierie de l'IA destiné à la production comprend généralement : une couche d'ingestion (chargement des documents, segmentation, création des représentations vectorielles et indexation du magasin vectoriel), une couche de recherche (recherche hybride et reclassement), une couche d'agent (appels de fonctions et exécution d'outils), une couche d'API (backend FastAPI et points de terminaison de diffusion en continu), ainsi qu'une couche d'observabilité (traçage, indicateurs et alertes). Esquissez le flux de données entre ces composants avant d'écrire du code.
# 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
]Choisir la pile technologique appropriée
Choisissez les technologies en fonction de la familiarité de votre équipe et des exigences réelles du système, plutôt que de leur nouveauté. Une pile par défaut raisonnable comprend : FastAPI pour la couche d'API, pgvector pour le stockage vectoriel (qui réutilise l'infrastructure PostgreSQL existante), LangChain LCEL pour la composition de la pipeline, Redis pour la mise en cache sémantique et l'état de la limitation de débit, LangSmith pour le traçage et PostgreSQL pour les données utilisateur et les résultats d'évaluation. N'ajoutez des composants que lorsque les options plus simples ne répondent pas aux exigences.
# 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'),
}Dessiner le diagramme d'architecture
Documentez l'architecture du système sous la forme d'un diagramme de flux de données montrant chaque composant, les données qui circulent entre eux et le sens de circulation. Incluez à la fois le chemin d'ingestion (hors ligne : documents → segments → représentations vectorielles → magasin vectoriel) et le chemin de requête (en ligne : requête utilisateur → vérification du cache → recherche → reclassement → LLM → réponse diffusée en continu). Ce diagramme constitue votre repère principal pour l'implémentation et aide les nouveaux membres de l'équipe à comprendre instantanément le système.
# 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)Définir tôt les contrats d'API
Définissez les points de terminaison de votre API ainsi que leurs schémas de requête et de réponse dans FastAPI avant d'implémenter la logique du backend. Cela crée un contrat entre l'API et les éventuels consommateurs frontend et permet le développement en parallèle. Documentez chaque point de terminaison avec des descriptions OpenAPI. Au minimum, définissez des points de terminaison pour : l'ingestion de documents, le dialogue et les requêtes, l'historique des conversations, les résultats d'évaluation et l'état de santé du système.
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 lessonEstimer et budgétiser les coûts
Estimez le coût mensuel de l'API de votre système avant d'écrire la moindre ligne de code backend. Calculez : nombre quotidien prévu d'utilisateurs actifs × requêtes par utilisateur × nombre moyen de jetons par requête. Pour un système comptant 100 DAU, 10 requêtes par jour et 3 000 jetons par requête au tarif de GPT-4o, cela représente 3 millions de jetons par jour, soit environ 45 $ par jour ou 1 350 $ par mois. Cette estimation vous indique si le système est économiquement viable et quelles optimisations (mise en cache, routage des modèles) valent la peine d'être implémentées.
# 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}')Planifier la pipeline d'ingestion
Concevez la pipeline d'ingestion comme un traitement par lots hors ligne exécuté à la demande ou selon un calendrier. Définissez les types de documents pris en charge (PDF, DOCX, HTML et texte brut), la stratégie de segmentation, le modèle de représentation vectorielle et les champs de métadonnées à stocker avec chaque vecteur. Les métadonnées sont essentielles pour la recherche filtrée : sans elles, vous ne pouvez pas limiter la recherche aux documents d'une période, d'un auteur ou d'une catégorie précise.
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
}Décisions d'architecture de sécurité
Prenez les décisions de sécurité dès le départ plutôt que de les ajouter ultérieurement. Définissez : la manière dont les utilisateurs s'authentifient (JWT, clés d'API), les données accessibles à chaque utilisateur (sécurité au niveau des lignes dans les requêtes pgvector), la manière de détecter l'injection de prompt, les contrôles appliqués aux sorties et les actions nécessitant une confirmation multifacteur. Chaque décision a des conséquences sur les performances qui influencent les choix d'architecture dans l'ensemble du système.
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'
}Définir les indicateurs de réussite
Définissez la réussite de votre système avant de le construire. Un ensemble de critères de réussite concrets et mesurables maintient l'équipe concentrée et fournit des critères clairs de mise en production ou d'abandon. Incluez des indicateurs pour : la qualité (score d'évaluation sur le jeu de tests), la latence (TTFT p95 et latence totale), le coût (objectif de coût par requête) et la fiabilité (SLA de disponibilité). Publiez-les dans le README du projet afin que tous les contributeurs partagent le même objectif.
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
}Documenter les compromis d'architecture
Chaque décision d'architecture implique des compromis. Documentez-les explicitement dans un Architecture Decision Record (ADR) : la décision prise, les solutions envisagées et les raisons du choix retenu. Par exemple : « Nous avons choisi pgvector plutôt que Pinecone, car nous utilisons déjà PostgreSQL, ce qui réduit la charge opérationnelle. Compromis : l'échelle maximale est limitée à environ 10 millions de vecteurs sans partitionnement. » Les futurs membres de l'équipe vous remercieront pour cette transparence.
# 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-miniEsquisser la topologie de déploiement
Définissez le mode de déploiement de votre système avant d'écrire du code d'infrastructure. Associez chaque composant à une unité de déploiement : le backend FastAPI sous forme de conteneur Docker, la pipeline d'ingestion comme service de traitement distinct, pgvector comme instance PostgreSQL gérée et Redis comme cache géré. Précisez quels composants sont sans état (et peuvent être mis à l'échelle horizontalement) et lesquels sont avec état (et nécessitent des stratégies de mise à l'échelle soigneusement conçues). Un diagramme de déploiement vous évitera des heures de reprise ultérieure.
# 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/cacheVérification rapide
Testez votre compréhension de la conception de l'architecture des systèmes d'IA destinés à la production.
Récapitulatif de la leçon
Dans cette leçon, vous avez appris que l'inventaire des composants et les diagrammes de flux de données créent une vision architecturale partagée avant le début du codage, que les contrats d'API définis en amont permettent le développement en parallèle et rendent les exigences explicites, et que les indicateurs de réussite définis à l'avance maintiennent l'équipe alignée sur les objectifs de qualité, de latence, de coût et de fiabilité. Nous allons maintenant implémenter les fonctionnalités RAG et agent essentielles.
Questions Fréquemment Posées
La leçon « Concevoir l’architecture de production » est-elle gratuite ?
Oui — le texte complet de « Concevoir l’architecture de production » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours AI Engineering Academy, passe à CoddyKit PRO. Le cours AI Engineering Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Concevoir l’architecture de production » ?
Choisissez un projet de synthèse, esquissez l’architecture complète, notamment le pipeline RAG, la couche d’agent, la mise en cache, l’observabilité et l’API, puis documentez les choix de conception… Tu pratiques AI Engineering Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer AI Engineering Academy ?
Aucune expérience préalable n'est requise. AI Engineering Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 1 sur 4.
Combien de temps prend la leçon « Concevoir l’architecture de production » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon AI Engineering Academy ?
Oui. Chaque leçon AI Engineering Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Concevoir l’architecture de production
- Implémenter les fonctionnalités essentielles de RAG et d’agent
- Renforcement : sécurité, mise en cache et fiabilité
- Évaluation, déploiement et bilan rétrospectif