0Pricing
AI Engineering Academy · درس

تصميم بنية الإنتاج

اختر مشروعًا ختاميًا، وارسم مخططًا للبنية الكاملة التي تشمل خط أنابيب RAG وطبقة الوكيل والتخزين المؤقت وقابلية المراقبة وواجهة API، ثم وثّق قرارات التصميم والمفاضلات.

تصميم بنية الإنتاج درس مجاني في AI Engineering Academy على CoddyKit. هذا هو الدرس 1 من أصل 4. يمكنك قراءة الدرس كاملاً أدناه مجاناً — ثم تمرن عليه مباشرة في المتصفح باستخدام محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7. هذا الدرس جزء من مسار التعلم في AI Engineering Academy، وتقدمك يتزامن عبر الويب وتطبيق CoddyKit. تتضمن دورة AI Engineering Academy 4 دروس في المجموع.

اختيار مشروع ختامي

يجمع المشروع الختامي كل ما تعلمتموه في المسار: RAG والوكلاء والبث والتخزين المؤقت وقابلية الرصد والأمان. ويكون المشروع الختامي الجيد معقدًا بصورة جوهرية، بحيث يتطلب ثلاثة مكونات متميزة من الذكاء الاصطناعي على الأقل، لكنه يظل محدود النطاق بما يكفي لإطلاقه خلال أيام لا أشهر. ومن الأمثلة التقليدية: مساعد أسئلة وأجوبة للمستندات بجودة إنتاجية، أو وكيل بحث مستقل مع إشراف بشري ضمن الحلقة، أو مسار لاستخراج البيانات المؤسسية.

تحديد مكونات النظام

ابدؤوا بسرد المكونات المتميزة التي يحتاج إليها نظامكم. يتضمن مشروع هندسة الذكاء الاصطناعي المخصص للإنتاج عادةً: طبقة الإدخال (تحميل المستندات وتقسيمها وإنشاء التضمينات وفهرستها في مخزن المتجهات)، وطبقة الاسترجاع (البحث الهجين وإعادة الترتيب)، وطبقة الوكيل (استدعاء الدوال وتنفيذ الأدوات)، وطبقة API (الواجهة الخلفية FastAPI ونقاط نهاية البث)، وطبقة قابلية الرصد (التتبع والمقاييس والتنبيهات). ارسموا تدفق البيانات بينها قبل كتابة التعليمات البرمجية.

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

اختيار الحزمة التقنية المناسبة

اختاروا التقنية بناءً على إلمام فريقكم بها ومتطلبات النظام الفعلية، لا بناءً على حداثتها. ومن الحزم التقنية الافتراضية المعقولة: FastAPI لطبقة API، وpgvector لتخزين المتجهات (إذ يعيد استخدام البنية الحالية لـ PostgreSQL)، وLangChain LCEL لتركيب مسارات التنفيذ، وRedis للتخزين المؤقت الدلالي وحالة تحديد معدل الطلبات، وLangSmith للتتبع، وPostgreSQL لبيانات المستخدمين ونتائج التقييم. أضيفوا المكونات فقط عندما لا تفي الخيارات الأبسط بالمتطلبات.

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

رسم مخطط البنية

وثّقوا بنية النظام في صورة مخطط لتدفق البيانات يوضح كل مكون، والبيانات التي تتدفق بينها، واتجاه التدفق. أدرجوا كلًا من مسار الإدخال (دون اتصال: المستندات → المقاطع → التضمينات → مخزن المتجهات) ومسار الاستعلام (عبر الاتصال: استعلام المستخدم → التحقق من ذاكرة التخزين المؤقت → الاسترجاع → إعادة الترتيب → LLM → استجابة متدفقة). يمثّل هذا المخطط مرجعكم الأساسي أثناء التنفيذ، ويساعد أعضاء الفريق الجدد على فهم النظام فورًا.

# 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 مبكرًا

حدّدوا نقاط نهاية API ومخططات الطلبات والاستجابات الخاصة بها في FastAPI قبل تنفيذ منطق الواجهة الخلفية. ينشئ ذلك عقدًا بين API وأي مستهلكين للواجهة الأمامية، ويجعل التطوير المتوازي ممكنًا. وثّقوا كل نقطة نهاية باستخدام أوصاف OpenAPI. حدّدوا، كحد أدنى، نقاط نهاية لإدخال المستندات، والمحادثة/الاستعلام، وسجل المحادثة، ونتائج التقييم، وحالة النظام.

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

تقدير التكاليف وإعداد الميزانية

قدّروا تكلفة API الشهرية لنظامكم قبل كتابة سطر واحد من التعليمات البرمجية للواجهة الخلفية. احسبوا: عدد المستخدمين النشطين يوميًا المتوقع × عدد الاستعلامات لكل مستخدم × متوسط الرموز لكل استعلام. في نظام يضم 100 مستخدم نشط يوميًا، و10 استعلامات يوميًا، و3,000 رمز لكل استعلام وفق أسعار GPT-4o، فذلك يعادل 3 ملايين رمز يوميًا، أي نحو 45 دولارًا يوميًا أو 1,350 دولارًا شهريًا. يوضح لكم هذا التقدير ما إذا كان النظام قابلًا للاستمرار اقتصاديًا، وأي تحسينات، مثل التخزين المؤقت وتوجيه النماذج، تستحق التنفيذ.

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

تخطيط مسار الإدخال

صمّموا مسار الإدخال باعتباره عملية دفعية تعمل دون اتصال، وتُشغّل عند الطلب أو وفق جدول زمني. حدّدوا أنواع المستندات التي ستدعمونها (PDF وDOCX وHTML والنص العادي)، واستراتيجية التقسيم، ونموذج التضمين، وحقول البيانات الوصفية التي ستُخزّن إلى جانب كل متجه. وتُعد البيانات الوصفية ضرورية للاسترجاع المصفّى؛ فمن دونها لا يمكنكم تقييد البحث ليقتصر على مستندات ضمن نطاق زمني أو لكاتب أو فئة محددة.

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
}

قرارات بنية الأمان

اتخذوا قرارات الأمان مقدمًا بدلًا من إضافتها لاحقًا. حدّدوا: كيفية مصادقة المستخدمين (JWT أو مفاتيح API)، والبيانات التي يمكن استرجاعها لكل مستخدم (الأمان على مستوى الصف في استعلامات pgvector)، وكيفية اكتشاف حقن التعليمات، وما الفحص المطبق على المخرجات، والإجراءات التي تتطلب تأكيدًا متعدد العوامل. لكل قرار آثار على الأداء تؤثر في خيارات البنية في مختلف أجزاء النظام.

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

تحديد مقاييس النجاح

حدّدوا شكل النجاح لنظامكم قبل بنائه. تحافظ مجموعة من معايير النجاح الملموسة والقابلة للقياس على تركيز التطوير، وتمنحكم معايير واضحة لاتخاذ قرار الإطلاق أو عدمه. أدرجوا مقاييس لـالجودة (درجة التقييم على مجموعة الاختبار)، وزمن الاستجابة (p95 لـ TTFT والزمن الإجمالي)، والتكلفة (التكلفة المستهدفة لكل استعلام)، والموثوقية (اتفاقية مستوى خدمة وقت التشغيل). انشروا هذه المقاييس في README الخاص بالمشروع حتى يشترك جميع المساهمين في الهدف نفسه.

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
}

توثيق المفاضلات المعمارية

ينطوي كل قرار معماري على مفاضلات. وثّقوها بوضوح في سجل قرار معماري (ADR): ما القرار الذي اتُّخذ، وما البدائل التي نوقشت، ولماذا اختير هذا الخيار. على سبيل المثال: «اخترنا pgvector بدلًا من Pinecone لأننا نشغّل PostgreSQL بالفعل، مما يقلل الأعباء التشغيلية. والمفاضلة هي أن الحد الأقصى للتوسع يقتصر على نحو 10 ملايين متجه دون التجزئة». سيقدّر أعضاء الفريق المستقبليون هذه الشفافية.

# 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

رسم مخطط النشر

حدّدوا كيفية نشر نظامكم قبل كتابة أي تعليمات برمجية للبنية التحتية. اربطوا كل مكون بوحدة نشر: الواجهة الخلفية FastAPI في صورة Docker، ومسار الإدخال في خدمة عامل منفصلة، وpgvector في مثيل PostgreSQL مُدار، وRedis في ذاكرة تخزين مؤقتة مُدارة. حدّدوا المكونات عديمة الحالة (التي يمكن توسيعها أفقيًا) مقابل المكونات ذات الحالة (التي تتطلب استراتيجيات توسعة دقيقة). يوفر مخطط النشر ساعات من إعادة العمل لاحقًا.

# 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

تحقق سريع

اختبروا مدى فهمكم لتصميم بنية أنظمة الذكاء الاصطناعي المخصصة للإنتاج.

مراجعة الدرس

تعلمتم في هذا الدرس أن جرد المكونات ومخططات تدفق البيانات ينشئان رؤية معمارية مشتركة قبل بدء البرمجة، وأن عقود API المحددة مسبقًا تتيح التطوير المتوازي وتجعل المتطلبات واضحة، وأن مقاييس النجاح المحددة مسبقًا تحافظ على توافق الفريق بشأن أهداف الجودة وزمن الاستجابة والتكلفة والموثوقية. بعد ذلك، سننفذ الميزات الأساسية لـ RAG والوكيل.

الأسئلة الشائعة

هل درس «تصميم بنية الإنتاج» مجاني؟

نعم — نص درس «تصميم بنية الإنتاج» كامل متاح مجاناً هنا على الويب. لتمرينه بشكل تفاعلي (محرر أكواد مدمج ومدرس ذكاء اصطناعي متاح 24/7) وفتح باقي دورة AI Engineering Academy، انتقل إلى CoddyKit PRO. تتضمن دورة AI Engineering Academy 4 دروس في المجموع.

ماذا ستتعلم في «تصميم بنية الإنتاج»؟

اختر مشروعًا ختاميًا، وارسم مخططًا للبنية الكاملة التي تشمل خط أنابيب RAG وطبقة الوكيل والتخزين المؤقت وقابلية المراقبة وواجهة API، ثم وثّق قرارات التصميم والمفاضلات. تتمرن على AI Engineering Academy مع أكواد عملية تشغلها مباشرة في المتصفح، ومدرس ذكاء اصطناعي متاح 24/7 يجيب على أسئلتك أثناء عملك.

هل أحتاج إلى خبرة سابقة لأبدأ AI Engineering Academy؟

لا تُشترط خبرة سابقة. AI Engineering Academy على CoddyKit منظم للمبتدئين حتى المتقدمين، لذا يمكنك البدء من هنا أو من البداية والتقدم بسرعتك الخاصة. هذا هو الدرس 1 من أصل 4.

كم من الوقت يستغرق درس «تصميم بنية الإنتاج»؟

معظم دروس CoddyKit تستغرق حوالي 5–10 دقائق. كل منها موجز وتفاعلي، لذا تحرز تقدماً مستمراً وتستأنف من حيث توقفت عبر الويب والتطبيق.

هل يمكنني كتابة وتشغيل أكواد في درس AI Engineering Academy هذا؟

نعم. كل درس في AI Engineering Academy يتضمن محرر أكواد مدمج، لذا تكتب وتشغل أكواداً حقيقية مباشرة في متصفحك وتحصل على تعليقات فورية من الذكاء الاصطناعي — بدون إعداد محلي.

جميع الدروس في هذه الدورة

  1. تصميم بنية الإنتاج
  2. تنفيذ ميزات RAG والوكيل الأساسية
  3. تقوية النظام: الأمان والتخزين المؤقت والموثوقية
  4. التقييم والنشر والمراجعة اللاحقة
← العودة إلى AI Engineering Academy