การตรวจสอบและลองใหม่เมื่อผลลัพธ์ไม่ถูกต้อง
สร้างชั้นตรวจสอบที่เช็กข้อมูลที่ดึงได้กับกฎทางธุรกิจ ลองใหม่โดยอัตโนมัติพร้อมคำแนะนำแก้ไขเมื่อการตรวจสอบไม่ผ่าน และบันทึกรูปแบบความล้มเหลว
การตรวจสอบและลองใหม่เมื่อผลลัพธ์ไม่ถูกต้อง เป็นบทเรียน AI Engineering Academy ฟรีบน CoddyKit นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน คุณสามารถอ่านบทเรียนทั้งหมดด้านล่างฟรี — จากนั้นลองปฏิบัติด้วยตัวคุณเองในเบราว์เซอร์พร้อมตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7 บทเรียนนี้เป็นส่วนหนึ่งของเส้นทางการเรียน AI Engineering Academy และความก้าวหน้าของคุณจะซิงค์ข้ามเว็บและแอป CoddyKit คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน
เหตุใดผลลัพธ์จาก LLM จึงต้องผ่านการตรวจสอบความถูกต้อง
แม้จะใช้ผลลัพธ์แบบมีโครงสร้างและโครงสร้าง Pydantic แล้ว การสกัดข้อมูลด้วย LLM ก็ยังอาจสร้างผลลัพธ์ที่ถูกต้องตามไวยากรณ์แต่ผิดตามความหมายได้ เช่น คะแนนความมั่นใจ 1.5 ซึ่งอยู่นอกช่วง 0–1 ราคา -99.99 สตริงวันที่ที่แยกวิเคราะห์ไม่ได้ หรือหมายเลขโทรศัพท์ที่มีตัวอักษร ทั้งหมดนี้ผ่านการแยกวิเคราะห์ JSON ได้ แต่ไม่ผ่านกฎทางธุรกิจของคุณ
การตรวจสอบความถูกต้องเป็นหน้าที่ที่แยกจากการสกัดข้อมูล การสกัดข้อมูลถามว่า “เราได้ข้อมูลที่มีโครงสร้างมาหรือไม่” ส่วนการตรวจสอบความถูกต้องถามว่า “ข้อมูลที่มีโครงสร้างนั้นถูกต้องและนำไปใช้งานได้หรือไม่” ทั้งสองชั้นจำเป็นต่อกระบวนการระดับใช้งานจริง ให้มองว่านี่เป็นตัวกรองสองขั้นตอน LLM ทำหน้าที่สกัดข้อมูล ส่วนตัวตรวจสอบของคุณทำหน้าที่ยอมรับหรือปฏิเสธ
ชั้นของการตรวจสอบความถูกต้อง
ระบบตรวจสอบผลลัพธ์ที่มีประสิทธิภาพทำงานในหลายระดับ:
- การตรวจสอบโครงสร้าง (Pydantic): ชนิดของฟิลด์ถูกต้อง มีฟิลด์ที่จำเป็นครบ และค่าแจกแจงตรงกับค่าที่อนุญาต ซึ่งผลลัพธ์แบบมีโครงสร้างจะจัดการให้โดยอัตโนมัติ
- การตรวจสอบรูปแบบ: หมายเลขโทรศัพท์ตรงกับ regex อีเมลถูกต้อง วันที่แยกวิเคราะห์ได้ และจำนวนเงินอยู่ในช่วงที่สมเหตุสมผล
- การตรวจสอบตรรกะทางธุรกิจ: ยอดรวมใบแจ้งหนี้เท่ากับผลรวมของรายการสินค้า วันที่สิ้นสุดอยู่หลังวันที่เริ่มต้น และปริมาณเป็นจำนวนเต็มบวก
- การตรวจสอบข้ามฟิลด์: ค่าของฟิลด์หนึ่งขึ้นอยู่กับค่าของอีกฟิลด์หนึ่ง เช่น เปอร์เซ็นต์ส่วนลดต้องไม่เกิน 100
- การตรวจสอบเชิงความหมาย: ชื่อบริษัทที่สกัดได้ตรงกับบริษัทที่รู้จักในฐานข้อมูลของคุณ
ตัวตรวจสอบ Pydantic สำหรับตรวจสอบรูปแบบ
ตัวตกแต่ง field_validator ของ Pydantic ช่วยให้คุณเพิ่มตรรกะการตรวจสอบแบบกำหนดเอง ซึ่งจะทำงานเมื่อสร้างอินสแตนซ์ของแบบจำลอง ใช้สิ่งนี้สำหรับการตรวจสอบระดับรูปแบบ เช่น การตรวจสอบหมายเลขโทรศัพท์และอีเมลด้วย regex การแยกวิเคราะห์วันที่ และการตรวจสอบช่วงของฟิลด์ตัวเลข
from pydantic import BaseModel, Field, field_validator
from typing import Optional
import re
from datetime import datetime
class ExtractedInvoice(BaseModel):
vendor: str
invoice_number: Optional[str]
amount: float = Field(gt=0, description='Must be positive')
currency: str = Field(min_length=3, max_length=3)
invoice_date: str
@field_validator('currency')
@classmethod
def currency_must_be_uppercase(cls, v):
return v.upper()
@field_validator('invoice_date')
@classmethod
def parse_date(cls, v):
# Try to parse common date formats
for fmt in ('%Y-%m-%d', '%d/%m/%Y', '%m/%d/%Y', '%B %d, %Y'):
try:
datetime.strptime(v, fmt)
return v
except ValueError:
continue
raise ValueError(f'Cannot parse date: {v}')
@field_validator('amount')
@classmethod
def reasonable_amount(cls, v):
if v > 10_000_000:
raise ValueError(f'Amount {v} seems unreasonably large. Flag for review.')
return round(v, 2)รูปแบบการลองใหม่พร้อมข้อเสนอแนะเพื่อแก้ไข
เมื่อการตรวจสอบความถูกต้องล้มเหลว กลยุทธ์กู้คืนที่มีประสิทธิภาพที่สุดคือ การลองใหม่พร้อมข้อเสนอแนะเพื่อแก้ไข โดยส่งข้อความข้อผิดพลาดจากการตรวจสอบกลับไปยังแบบจำลองเป็นบริบท อธิบายว่าเกิดข้อผิดพลาดอะไรขึ้น และขอให้แบบจำลองแก้ไขเฉพาะฟิลด์ที่ล้มเหลว วิธีนี้ทำให้แบบจำลองมีข้อมูลที่จำเป็นในการแก้ไขผลลัพธ์ แทนที่จะลองใหม่โดยไม่มีแนวทาง
import openai
from pydantic import BaseModel, ValidationError, Field
client = openai.OpenAI()
class PriceExtraction(BaseModel):
product: str
price_usd: float = Field(gt=0, lt=100000)
quantity: int = Field(ge=1)
def extract_with_retry(text: str, max_retries: int = 3) -> PriceExtraction:
messages = [
{'role': 'system', 'content': 'Extract product pricing information.'},
{'role': 'user', 'content': text}
]
for attempt in range(max_retries):
result = client.beta.chat.completions.parse(
model='gpt-4o-mini',
messages=messages,
response_format=PriceExtraction
)
msg = result.choices[0].message
if msg.refusal:
raise ValueError(f'Model refused: {msg.refusal}')
try:
return msg.parsed # Pydantic validates on parse
except ValidationError as e:
if attempt == max_retries - 1:
raise
# Add corrective feedback for the next attempt
messages.append({'role': 'assistant', 'content': msg.content})
messages.append({'role': 'user', 'content': f'The previous extraction failed validation: {e}\nPlease correct and try again.'})
print(f'Attempt {attempt+1} failed. Retrying with feedback...')การตรวจสอบตรรกะทางธุรกิจ
การตรวจสอบตรรกะทางธุรกิจจะตรวจสอบคุณสมบัติที่ครอบคลุมหลายฟิลด์หรือขึ้นอยู่กับแหล่งข้อมูลภายนอก model_validator ของ Pydantic จะทำงานหลังจากตัวตรวจสอบระดับฟิลด์ทั้งหมด และสามารถเข้าถึงแบบจำลองที่เติมข้อมูลครบแล้ว จึงเหมาะสำหรับการตรวจสอบข้ามฟิลด์
from pydantic import BaseModel, Field, model_validator
from typing import List
class LineItem(BaseModel):
description: str
quantity: int = Field(ge=1)
unit_price: float = Field(ge=0)
line_total: float
@model_validator(mode='after')
def check_line_total(self):
expected = round(self.quantity * self.unit_price, 2)
actual = round(self.line_total, 2)
if abs(expected - actual) > 0.02: # Allow 2-cent rounding tolerance
raise ValueError(
f'Line total {actual} does not match quantity*price={expected}'
)
return self
class Invoice(BaseModel):
line_items: List[LineItem]
subtotal: float
tax: float
total: float
@model_validator(mode='after')
def check_invoice_total(self):
expected_total = round(self.subtotal + self.tax, 2)
if abs(expected_total - round(self.total, 2)) > 0.02:
raise ValueError(
f'Invoice total {self.total} != subtotal+tax ({expected_total})'
)
return selfการบันทึกความล้มเหลวในการตรวจสอบความถูกต้อง
ความล้มเหลวในการตรวจสอบความถูกต้องทุกครั้งเป็นสัญญาณว่ากระบวนการของคุณกำลังมีปัญหาที่จุดใด ให้บันทึกความล้มเหลวแต่ละครั้งพร้อมข้อความขาเข้า หรือค่าแฮชของข้อความเพื่อความเป็นส่วนตัว ผลลัพธ์ที่สกัดได้ ข้อผิดพลาดเฉพาะจากการตรวจสอบ และหมายเลขครั้งที่ลอง นำบันทึกเหล่านี้มารวมกันเพื่อระบุรูปแบบที่เกิดขึ้นอย่างเป็นระบบ เช่น แบบจำลองกรอกฟิลด์ใดฟิลด์หนึ่งผิดอยู่เสมอหรือไม่ หรือมีเอกสารประเภทใดที่ทำให้เกิดความล้มเหลว ข้อมูลนี้ช่วยขับเคลื่อนการปรับปรุงคำสั่งอย่างตรงจุด
import logging
from pydantic import ValidationError
logger = logging.getLogger(__name__)
def extract_with_logging(text: str, doc_id: str) -> dict:
result = None
for attempt in range(3):
try:
result = run_extraction(text) # Your extraction function
logger.info('Extraction success', extra={
'doc_id': doc_id,
'attempt': attempt + 1
})
return result
except ValidationError as e:
logger.warning('Validation failure', extra={
'doc_id': doc_id,
'attempt': attempt + 1,
'errors': e.errors(),
'error_count': len(e.errors())
})
# All retries failed
logger.error('Extraction failed after max retries', extra={'doc_id': doc_id})
return {'error': 'extraction_failed', 'doc_id': doc_id}
def run_extraction(text):
pass # Placeholder for actual extraction logicคะแนนความมั่นใจและเกณฑ์
เพิ่มฟิลด์ confidence ลงในโครงสร้างการสกัดข้อมูล และกำชับให้แบบจำลองประเมินความมั่นใจในการสกัดข้อมูลแต่ละรายการตั้งแต่ 0 ถึง 1 จากนั้นใช้กฎทางธุรกิจตามระดับความมั่นใจ ผลการสกัดที่มีความมั่นใจสูงส่งตรงไปยังฐานข้อมูล ผลการสกัดที่มีความมั่นใจปานกลางจะถูกทำเครื่องหมายไว้เพื่อตรวจสอบบางส่วน และผลการสกัดที่มีความมั่นใจต่ำจะถูกส่งไปยังคิวให้มนุษย์ตรวจสอบ
แนวทางเชิงความน่าจะเป็นนี้ใช้งานได้จริงกว่าการกำหนดให้ LLM ต้องแม่นยำ 100% เพราะคุณออกแบบกระบวนการให้จัดการกับความไม่แน่นอนได้อย่างเหมาะสม แทนที่จะแสร้งทำเป็นว่าความไม่แน่นอนไม่มีอยู่
from pydantic import BaseModel, Field
from typing import Optional
class ExtractedWithConfidence(BaseModel):
value: Optional[str]
confidence: float = Field(ge=0.0, le=1.0)
reason: Optional[str] = None # Why confidence is low, if below threshold
class DocumentExtraction(BaseModel):
vendor_name: ExtractedWithConfidence
invoice_amount: ExtractedWithConfidence
due_date: ExtractedWithConfidence
def route_by_confidence(extraction: DocumentExtraction, threshold=0.85):
low_confidence_fields = []
for field_name, field_val in extraction.model_dump().items():
if isinstance(field_val, dict) and field_val.get('confidence', 1.0) < threshold:
low_confidence_fields.append(field_name)
if not low_confidence_fields:
return 'auto_approve'
elif len(low_confidence_fields) > 2:
return 'human_review'
else:
return f'spot_check: {low_confidence_fields}'กลยุทธ์สำรองเมื่อการลองใหม่ล้มเหลว
เมื่อใช้การลองใหม่ครบทุกครั้งแล้วแต่การตรวจสอบความถูกต้องยังคงล้มเหลว คุณจำเป็นต้องมีกลยุทธ์สำรอง ตัวเลือกตามลำดับความเหมาะสมมีดังนี้:
- ผลลัพธ์บางส่วน: ส่งคืนฟิลด์ที่ผ่านการตรวจสอบแล้ว และกำหนดฟิลด์ที่ล้มเหลวให้เป็นค่าว่าง
- คิวให้มนุษย์ตรวจสอบ: เพิ่มเอกสารลงในคิวเพื่อตรวจสอบด้วยตนเอง โดยเฉพาะเอกสารที่มีมูลค่าสูง
- การสกัดข้อมูลที่มีรายละเอียดน้อยลง: เปลี่ยนไปใช้โครงสร้างที่เรียบง่ายกว่าและขอฟิลด์น้อยลง โดยยอมรับโครงสร้างที่ลดลงเพื่อแลกกับความทนทาน
- การจัดเก็บข้อความดิบ: จัดเก็บข้อความต้นฉบับพร้อมข้อมูลกำกับ เพื่อประมวลผลใหม่ในภายหลังเมื่อคุณปรับปรุงกระบวนการสกัดข้อมูลแล้ว
อย่าทิ้งเอกสารโดยไม่แจ้งให้ทราบโดยเด็ดขาด ให้บันทึกความล้มเหลวทุกครั้ง และตรวจสอบให้แน่ใจว่าคุณสามารถกลับมาจัดการเอกสารนั้นได้
การตรวจสอบเชิงความหมายเทียบกับข้อมูลภายนอก
กฎการตรวจสอบความถูกต้องบางข้อจำเป็นต้องค้นหาข้อมูลภายนอก ซึ่งไม่สามารถดำเนินการภายในตัวตรวจสอบความถูกต้องของ Pydantic ได้ ตัวอย่างเช่น การตรวจสอบว่าชื่อบริษัทที่ดึงออกมาปรากฏอยู่ใน CRM ของคุณหรือไม่ หรือ SKU ของผลิตภัณฑ์ที่ดึงออกมามีอยู่ในคลังสินค้าของคุณหรือไม่ การตรวจสอบเหล่านี้ควรอยู่ในขั้นตอนตรวจสอบความถูกต้องหลังการดึงข้อมูล ซึ่งทำงานหลังจากการตรวจสอบความถูกต้องของ Pydantic ผ่านแล้ว
from typing import Optional
# Simulated external data source
KNOWN_VENDORS = {'acme corp', 'techsupplies inc', 'globex corporation'}
def validate_against_crm(extraction: dict) -> dict:
vendor = extraction.get('vendor', '').lower()
warnings = []
if vendor and vendor not in KNOWN_VENDORS:
warnings.append({
'field': 'vendor',
'issue': f'Vendor "{vendor}" not found in CRM',
'severity': 'warning'
})
# Optionally suggest closest match
# from difflib import get_close_matches
# matches = get_close_matches(vendor, KNOWN_VENDORS, n=1, cutoff=0.8)
# if matches: warnings[-1]['suggestion'] = matches[0]
return {
'extraction': extraction,
'warnings': warnings,
'requires_review': len(warnings) > 0
}
print('Semantic validation pattern defined')การทดสอบกระบวนการตรวจสอบความถูกต้องของคุณ
ตรรกะการตรวจสอบความถูกต้องของคุณจำเป็นต้องมีชุดการทดสอบของตนเอง แยกจากการทดสอบการดึงข้อมูล ให้เขียนการทดสอบหน่วยที่ป้อนผลลัพธ์ที่ทราบว่าไม่ถูกต้องเข้าสู่ตัวตรวจสอบความถูกต้อง แล้วตรวจสอบว่าเกิดข้อผิดพลาดที่ถูกต้อง ทดสอบกรณีขอบเขตด้วย ได้แก่ จำนวนเงินที่อยู่ตรงค่าขอบเขต วันที่ในรูปแบบที่ไม่พบโดยทั่วไป ช่องข้อมูลที่มีช่องว่างที่ไม่คาดคิด และช่องข้อมูลที่เป็นสตริงตัวเลขแทนที่จะเป็นตัวเลข
ชุดการทดสอบการตรวจสอบความถูกต้องนี้ทำงานโดยไม่เรียก API ใด ๆ จึงทำงานได้รวดเร็วและมีค่าใช้จ่ายต่ำเมื่อเรียกใช้ทุกครั้งที่มีการเปลี่ยนแปลงโค้ด นอกจากนี้ยังเป็นเอกสารอธิบายกฎการตรวจสอบความถูกต้องที่ดีที่สุดด้วย เพราะกรณีทดสอบจะแสดงข้อกำหนดด้านรูปแบบและข้อจำกัดทางธุรกิจทุกข้อที่กระบวนการของคุณบังคับใช้ไว้อย่างชัดเจน
from pydantic import ValidationError
def test_extraction_validation():
# Test cases: (input_data, should_pass)
test_cases = [
({'vendor': 'ACME', 'amount': 150.00, 'currency': 'USD', 'invoice_date': '2025-01-15'}, True),
({'vendor': 'ACME', 'amount': -50.00, 'currency': 'USD', 'invoice_date': '2025-01-15'}, False), # negative
({'vendor': 'ACME', 'amount': 150.00, 'currency': 'EURO', 'invoice_date': '2025-01-15'}, False), # 4-char
({'vendor': 'ACME', 'amount': 150.00, 'currency': 'USD', 'invoice_date': 'yesterday'}, False), # bad date
]
passed = failed = 0
for data, should_pass in test_cases:
try:
# ExtractedInvoice(**data) # Your Pydantic model
if should_pass:
passed += 1
else:
print(f'MISSED: Should have failed for {data}')
failed += 1
except (ValidationError, ValueError):
if not should_pass:
passed += 1
else:
print(f'UNEXPECTED FAIL for {data}')
failed += 1
print(f'Tests: {passed} passed, {failed} failed')
test_extraction_validation()การวิเคราะห์ความล้มเหลวของรูปแบบและการปรับแต่งพรอมต์
หลังจากเรียกใช้กระบวนการดึงข้อมูลกับเอกสารจริงตัวอย่างและตรวจสอบความล้มเหลวในการตรวจสอบความถูกต้องแล้ว คุณมีแนวโน้มจะพบว่าความล้มเหลว 80% มีสาเหตุหลักร่วมกันอยู่เพียงไม่กี่ประการ สาเหตุที่พบบ่อย ได้แก่ โมเดลจัดรูปแบบวันที่จากภูมิภาคใดภูมิภาคหนึ่งผิดอย่างสม่ำเสมอ ระบุจำนวนภาษีสลับกับยอดรวม หรือสร้างหมายเลขโทรศัพท์ที่ไม่มีขีดกลาง ทั้งที่ตัวตรวจสอบความถูกต้องของคุณคาดว่าจะมีขีดกลาง
สำหรับรูปแบบความล้มเหลวที่เกิดซ้ำแต่ละแบบ ให้ปรับปรุงพรอมต์การดึงข้อมูลด้วยตัวอย่างและข้อจำกัดที่เฉพาะเจาะจงเพื่อป้องกันข้อผิดพลาดนั้น หลังจากปรับปรุงแล้ว ให้เรียกใช้ชุดการทดสอบทั้งหมดอีกครั้ง เพื่อยืนยันว่าการแก้ไขช่วยเพิ่มความแม่นยำโดยไม่ทำให้กรณีอื่นถดถอย วงจรการปรับพรอมต์แล้วประเมินผลแบบวนซ้ำนี้คือวิธีที่กระบวนการดึงข้อมูลระดับใช้งานจริงบรรลุความแม่นยำมากกว่า 95% กับข้อมูลในโลกจริง
ตรวจสอบความเข้าใจอย่างรวดเร็ว
ทดสอบความเข้าใจแนวคิดวิศวกรรม AI จากบทเรียนนี้
สรุปบทเรียน
ในบทเรียนนี้ คุณได้เรียนรู้ว่า การตรวจสอบความถูกต้องทำงานอยู่หลายระดับ ได้แก่ ระดับโครงสร้าง ระดับรูปแบบ ระดับตรรกะทางธุรกิจ และระดับความหมาย ซึ่งแต่ละระดับต้องใช้แนวทางการนำไปใช้ที่แตกต่างกัน การลองใหม่พร้อมข้อเสนอแนะเพื่อแก้ไขจะมอบบริบทข้อผิดพลาดที่เฉพาะเจาะจงให้โมเดล เพื่อให้โมเดลแก้ไขผลลัพธ์ได้อย่างมีประสิทธิภาพ และ คะแนนความมั่นใจช่วยให้กำหนดเส้นทางตามความน่าจะเป็น เพื่ออนุมัติอัตโนมัติ ตรวจสอบแบบสุ่ม หรือส่งเข้าคิวให้มนุษย์ตรวจสอบ โดยอิงจากความแน่นอนของการดึงข้อมูล ขณะนี้คุณเรียนจบหลักสูตรผลลัพธ์แบบมีโครงสร้างและโหมด JSON แล้ว ต่อไปเราจะสำรวจเวกเตอร์ฝังความหมาย ซึ่งเป็นพื้นฐานของระบบ RAG ทุกระบบ
คำถามที่พบบ่อย
บทเรียน “การตรวจสอบและลองใหม่เมื่อผลลัพธ์ไม่ถูกต้อง” ฟรีหรือไม่
ใช่ — ข้อความเต็มของ “การตรวจสอบและลองใหม่เมื่อผลลัพธ์ไม่ถูกต้อง” ฟรีให้อ่านที่นี่บนเว็บ เพื่อปฏิบัติแบบโต้ตอบ (ตัวแก้ไขโค้ดในตัวและติวเตอร์ AI ตลอด 24/7) และปลดล็อคส่วนที่เหลือของคอร์ส AI Engineering Academy ให้อัปเกรดเป็น CoddyKit PRO คอร์ส AI Engineering Academy มีบทเรียนทั้งหมด 4 บทเรียน
คุณจะเรียนรู้อะไรในบทเรียน “การตรวจสอบและลองใหม่เมื่อผลลัพธ์ไม่ถูกต้อง”
สร้างชั้นตรวจสอบที่เช็กข้อมูลที่ดึงได้กับกฎทางธุรกิจ ลองใหม่โดยอัตโนมัติพร้อมคำแนะนำแก้ไขเมื่อการตรวจสอบไม่ผ่าน และบันทึกรูปแบบความล้มเหลว คุณปฏิบัติ AI Engineering Academy ด้วยโค้ดที่ใช้งานได้จริงที่คุณเรียกใช้โดยตรงในเบราว์เซอร์ และติวเตอร์ AI ตลอด 24/7 ตอบคำถามของคุณขณะที่คุณไปผ่านบทเรียน
คุณต้องมีประสบการณ์ก่อนที่จะเริ่มเรียน AI Engineering Academy หรือไม่
ไม่จำเป็นต้องมีประสบการณ์มาก่อน AI Engineering Academy บน CoddyKit ออกแบบมาสำหรับผู้เริ่มต้นไปจนถึงผู้เรียนขั้นสูง คุณสามารถเริ่มต้นที่นี่หรือเริ่มจากตัวแรกและเรียนด้วยความเร็วของคุณเอง นี่คือบทเรียนที่ 4 จากทั้งหมด 4 บทเรียน
บทเรียน “การตรวจสอบและลองใหม่เมื่อผลลัพธ์ไม่ถูกต้อง” ใช้เวลานานแค่ไหน
บทเรียน CoddyKit ส่วนใหญ่ใช้เวลาประมาณ 5–10 นาที แต่ละบทเรียนจึงสั้นและเป็นแบบโต้ตอบ คุณสามารถก้าวหน้าอย่างต่อเนื่องและกลับมาเรียนต่อจากตรงที่เพิ่งหยุดบนเว็บและแอปได้เลย
ฉันเขียนและรันโค้ดในบทเรียน AI Engineering Academy นี้ได้ไหม
ได้ บทเรียน AI Engineering Academy ทุกบทมีตัวแก้ไขโค้ดในตัว คุณจึงเขียนและรันโค้ดจริงได้เลยในเบราว์เซอร์ และได้รับข้อเสนอแนะจาก AI ในทันที — ไม่ต้องติดตั้งในเครื่องของคุณ
บทเรียนทั้งหมดในหลักสูตรนี้
- โหมด JSON และ response_format
- ผลลัพธ์แบบมีโครงสร้างด้วย Pydantic
- การดึงข้อมูลจากข้อความไร้โครงสร้าง
- การตรวจสอบและลองใหม่เมื่อผลลัพธ์ไม่ถูกต้อง