0Pricing
AI Engineering Academy · บทเรียน

การออกแบบสถาปัตยกรรมสำหรับใช้งานจริง

เลือกโครงการสรุปผล ร่างสถาปัตยกรรมทั้งหมดซึ่งรวมถึงกระบวนการ RAG, ชั้นเอเจนต์ การแคช การสังเกตการณ์ระบบ และเอพีไอ จากนั้นบันทึกเหตุผลในการออกแบบและข้อแลกเปลี่ยนต่าง ๆ

การออกแบบสถาปัตยกรรมสำหรับใช้งานจริง เป็นบทเรียน AI Engineering Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AI Engineering Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน

การเลือกโครงงานสรุปยอด

โครงงานสรุปยอดจะเชื่อมโยงทุกสิ่งที่เรียนมาในเส้นทางนี้เข้าด้วยกัน ได้แก่ RAG เอเจนต์ การสตรีม การแคช การสังเกตการณ์ระบบ และความปลอดภัย โครงงานสรุปยอดที่ดีควรมี ความซับซ้อนอย่างมีความหมาย โดยต้องใช้ส่วนประกอบ AI ที่แตกต่างกันอย่างน้อยสามส่วน แต่ยังมีขอบเขตเล็กพอที่จะพัฒนาให้เสร็จและนำไปใช้งานได้ภายในไม่กี่วันแทนที่จะเป็นหลายเดือน ตัวอย่างคลาสสิก ได้แก่ ผู้ช่วยตอบคำถามจากเอกสารระดับพร้อมใช้งานจริง เอเจนต์วิจัยอัตโนมัติที่มีมนุษย์กำกับดูแลอยู่ในวงจร หรือกระบวนการดึงข้อมูลระดับองค์กร

การระบุส่วนประกอบของระบบ

เริ่มจากการลิสต์ส่วนประกอบที่แตกต่างกันซึ่งระบบของคุณต้องใช้ โครงงานวิศวกรรม AI สำหรับใช้งานจริงโดยทั่วไปประกอบด้วย: ชั้นนำเข้าข้อมูล (การโหลดเอกสาร การแบ่งส่วน การสร้างเวกเตอร์ฝัง และการทำดัชนีในคลังเวกเตอร์) ชั้นค้นคืน (การค้นหาแบบผสมและการจัดอันดับใหม่) ชั้นเอเจนต์ (การเรียกใช้ฟังก์ชันและการดำเนินการกับเครื่องมือ) ชั้น 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, พีจีเวกเตอร์ สำหรับจัดเก็บเวกเตอร์ (นำโครงสร้างพื้นฐาน PostgreSQL ที่มีอยู่แล้วกลับมาใช้), LangChain LCEL สำหรับการประกอบกระบวนการ, รีดิส สำหรับการแคชเชิงความหมายและสถานะจำกัดอัตรา, 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 รายเดือนของระบบก่อนเขียนโค้ดแบ็กเอนด์แม้แต่บรรทัดเดียว คำนวณจาก: จำนวนผู้ใช้ที่ใช้งานในแต่ละวันโดยประมาณ × จำนวนคำค้นต่อผู้ใช้ × จำนวนโทเค็นเฉลี่ยต่อคำค้น สำหรับระบบที่มี DAU 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) ผู้ใช้แต่ละคนสามารถค้นคืนข้อมูลใดได้บ้าง (การรักษาความปลอดภัยระดับแถวในคำค้นพีจีเวกเตอร์) จะตรวจจับการแทรกคำสั่งในพรอมต์อย่างไร จะใช้การสแกนผลลัพธ์แบบใด และการดำเนินการใดต้องยืนยันหลายปัจจัย การตัดสินใจแต่ละข้อมีผลต่อประสิทธิภาพ ซึ่งจะส่งผลต่อตัวเลือกด้านสถาปัตยกรรมตลอดทั้งระบบ

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

การกำหนดตัวชี้วัดความสำเร็จ

กำหนดความหมายของความสำเร็จสำหรับระบบก่อนเริ่มสร้าง เกณฑ์ความสำเร็จที่เป็นรูปธรรมและวัดผลได้จะช่วยให้การพัฒนามีจุดมุ่งหมาย และให้เกณฑ์ที่ชัดเจนสำหรับตัดสินใจว่าจะนำระบบไปใช้งานหรือไม่ ให้ครอบคลุมตัวชี้วัดด้าน: คุณภาพ (คะแนนการประเมินจากชุดทดสอบ) เวลาแฝง (TTFT และเวลารวมที่ p95) ค่าใช้จ่าย (เป้าหมายค่าใช้จ่ายต่อคำค้น) และ ความน่าเชื่อถือ (SLA ด้านเวลาพร้อมใช้งาน) เผยแพร่ข้อมูลเหล่านี้ไว้ใน 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) โดยระบุว่าตัดสินใจอะไร พิจารณาทางเลือกใดบ้าง และเหตุใดจึงเลือกตัวเลือกนี้ ตัวอย่างเช่น: 'เลือกพีจีเวกเตอร์แทน 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 กระบวนการนำเข้าข้อมูลเป็นบริการผู้ปฏิบัติงานแยกต่างหาก พีจีเวกเตอร์เป็นอินสแตนซ์ PostgreSQL ที่มีการจัดการ และรีดิสเป็นแคชที่มีการจัดการ ระบุว่าส่วนประกอบใดไม่มีสถานะ (สามารถขยายในแนวนอนได้) และส่วนประกอบใดมีสถานะ (ต้องใช้กลยุทธ์การขยายอย่างระมัดระวัง) แผนภาพการนำระบบไปใช้งานจะช่วยประหยัดเวลาที่ต้องแก้งานใหม่ในภายหลังได้หลายชั่วโมง

# 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

ตรวจสอบความเข้าใจอย่างรวดเร็ว

ทดสอบความเข้าใจของคุณเกี่ยวกับการออกแบบสถาปัตยกรรมระบบ AI สำหรับใช้งานจริง

สรุปบทเรียน

ในบทเรียนนี้ คุณได้เรียนรู้ว่า บัญชีรายการส่วนประกอบและแผนภาพการไหลของข้อมูล ช่วยสร้างวิสัยทัศน์ร่วมด้านสถาปัตยกรรมก่อนเริ่มเขียนโค้ด สัญญา API ที่กำหนดไว้ล่วงหน้า ช่วยให้พัฒนาแบบขนานได้และทำให้ข้อกำหนดชัดเจน และ ตัวชี้วัดความสำเร็จที่กำหนดไว้ล่วงหน้า ช่วยให้ทีมมีเป้าหมายร่วมด้านคุณภาพ เวลาแฝง ค่าใช้จ่าย และความน่าเชื่อถือ ต่อไปเราจะนำฟีเจอร์หลักของ RAG และเอเจนต์ไปใช้งาน

คำถามที่พบบ่อย

บทเรียน “การออกแบบสถาปัตยกรรมสำหรับใช้งานจริง” ฟรีหรือไม่

ใช่ — ข้อความเต็มของ “การออกแบบสถาปัตยกรรมสำหรับใช้งานจริง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AI Engineering Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน

คุณจะเรียนรู้อะไรในบทเรียน “การออกแบบสถาปัตยกรรมสำหรับใช้งานจริง”

เลือกโครงการสรุปผล ร่างสถาปัตยกรรมทั้งหมดซึ่งรวมถึงกระบวนการ RAG, ชั้นเอเจนต์ การแคช การสังเกตการณ์ระบบ และเอพีไอ จากนั้นบันทึกเหตุผลในการออกแบบและข้อแลกเปลี่ยนต่าง ๆ คุณปฏิบัติ AI Engineering Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน

คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AI Engineering Academy หรือไม่

ไม่จำเป็นต้องมีประสบการณ์มาก่อน AI Engineering Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 1 จากทั้งหมด 4 บทเรียน

บทเรียน “การออกแบบสถาปัตยกรรมสำหรับใช้งานจริง” ใช้เวลานานแค่ไหน

บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย

ฉันเขียนและรันโค้ดในบทเรียน AI Engineering Academy นี้ได้ไหม

ได้ บทเรียน AI Engineering Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ

บทเรียนทั้งหมดในหลักสูตรนี้

  1. การออกแบบสถาปัตยกรรมสำหรับใช้งานจริง
  2. การพัฒนาความสามารถหลักของ RAG และเอเจนต์
  3. การเสริมความแข็งแกร่ง: ความปลอดภัย การแคช และความน่าเชื่อถือ
  4. การประเมินผล การนำไปใช้งาน และการทบทวนหลังดำเนินการ
← กลับไปที่ AI Engineering Academy