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