ບົດສອນ Pydantic AI: ສ້າງ LLM Agent ດ້ວຍວິທີຄວາມປອດໄພຂອງ Type, ຕັ້ງແຕ່ໂປຣແກຣມທຳອິດຈົນເຖິງຂຶ້ນລະບົບຕົວຈິງ
ຜູ້ທີ່ເຄີຍເຮັດແອັບພລິເຄຊັນ LLM ທຸກຄົນຮູ້ດີວ່າ: ສິ່ງທີ່ເຈັບປວດທີ່ສຸດບໍ່ແມ່ນການເຊື່ອມຕໍ່ API, ແຕ່ແມ່ນການທີ່ໂມເດວສົ່ງຜົນສົ່ງຄືນມາແຕ່ລະຄັ້ງບໍ່ຄືກັນ. Pydantic AI ໄດ້ນໍາເອົາການກວດສອບ Type ຂອງ Pydantic ເຂົ້າສູ່ການພັດທະນາ Agent, ເຮັດໃຫ້ຜົນລັບມີໂຄງສ້າງ ແລະ ເຄື່ອງມືສາມາດຖືກກວດສອບແບບ Static ໄດ້. ບົດຄວາມນີ້ຈະພາທ່ານໄປຕັ້ງແຕ່ການຕິດຕັ້ງ, ຂຽນລະຫັດ ຈົນເຖິງລະດັບສູງ, ພ້ອມທັງແບ່ງປັນປະສົບການທີ່ຂ້ອຍເຄີຍຜິດພາດມາແລ້ວ.
ຄຳນຳ: ເປັນຫຍັງຜົນລັບທີ່ໂມເດວສົ່ງຄືນຈຶ່ງບໍ່ຄືກັນໃນແຕ່ລະຄັ້ງ
ຖ້າທ່ານເຄີຍເຊື່ອມຕໍ່ API ຂອງ LLM, ທ່ານກໍຄົງຈະຄຸ້ນເຄີຍກັບພາບນີ້: ທ່ານສັ່ງໃຫ້ໂມເດວ “ສົ່ງ JSON ມາ, ໂດຍໃນນั้นຕ້ອງມີ name ແລະ score”, 9 ครั้งທຳກິດແມ່ນປົກກະຕິດີ, ແຕ່ຄັ້ງທີ 10 ມັນດັນໃສ່ປະໂຫຍກ “ໄດ້ເລີຍ, ນີ້ແມ່ນຜົນລັບ:” ໄວ້ທາງໜ້າ JSON, ເຮັດໃຫ້ json.loads() ຂອງທ່ານພັງລົງທັນທີ. ຈາກນັ້ນ ທ່ານກໍເລີ່ມຂຽນ Regular Expression ມາກວາດສະຕຣິງ, ຕາມດ້ວຍຂຽນ if ເພື່ອກວດສອບວ່າຟີລ໌ມີຢູ່ຫຼືບໍ່—ສຸດທ້າຍ ໂຄດຂອງ “ແອັບພລິເຄຊັນ AI” ຂອງທ່ານ 70% ແມ່ນໝົດໄປกับการຕໍ່ສູ້ກັບຜົນລັບທີ່ບໍ່ສະຖຽນຂອງໂມເດວ.
ຂ້ອຍເອງເຄີຍຮັກສາລະບົບຈັດໝວດໝູ່ພາຍໃນ, ພຽງແຕ່ການຈັດການກັບການທີ່ໂມເດວ-ບໍ່ໃຫ້ຟີລ໌ໃດໜຶ່ງມາເປັນບາງຄັ້ງຄາວ ເຮັດໃຫ້ຂ້ອຍຕ້ອງໄດ້ເຮັດວຽກລ່ວງເວລາເຖິງ 3 ມື້. ຕໍ່ມາເມື່ອປ່ຽນມາໃຊ້ Pydantic AI, ໂຄດປ້ອງກັນເຫຼົ່ານັ້ນເກືອບຖືກລຶບອອກໝົດ, ເພາະວ່າເລື່ອງການກວດສອບ (Validation) ນັ້ນ ທາງເຟຣມເວີກ (Framework) ເປັນຜູ້ຮັບຜິດຊອບໃຫ້ທ່ານໂດຍກົງ. ບົດຄວາມນີ້ຈະອະທິບາຍຢ່າງລະອຽດວ່າວິທີໃຊ້ມันເປັນແນວໃດ.
Pydantic AI ແມ່ນຫຍັງ
Pydantic AI ແມ່ນ Python Agent Framework ຈາກທີມງານ Pydantic. ຊື່ Pydantic ທ່ານອາດຈະເຄີຍເຫັນມາຈາກບ່ອນອື່ນ—OpenAI, Anthropic, Google SDK ຢ່າງເປັນທາງການ, ລວມເຖິງ LangChain, LlamaIndex, ພື້ນຖານການກວດສອບຂໍ້ມູນສ່ວນຫຼາຍແມ່ນອາໄສມັນ. ເວົ້າອີກຢ່າງໜຶ່ງ, ເລື່ອງການກວດສອບນີ້, ພວກເຂົາແມ່ນຜູ້ທີ່ມີຄວາມພ້ອມທີ່ສຸດໃນລະບົບນິເວດນີ້.
ປັດຊະຍາການອອກແບບຂອງມັນແມ່ນຄ້າຍຄືກັບ FastAPI: ໃຊ້ Type Hints ຂອງ Python ເພື່ອ ກຳນົດພຶດຕິກຳໃຫ້ຊັດເຈນ, ສ່ວນທີ່ເຫຼືອແມ່ນມອບໃຫ້ເຟຣມເວີກຈັດການ. ຫຼັກໆມີພຽງແຕ່ບໍ່ລວງແນວຄິດຄື—Agent (ຕົວແທນ), Tools (ເຄື່ອງມື), Dependencies (ການສັກນຳເຂົ້າ), Structured Output (ຜົນລັບທີ່ມີໂຄງສ້າງ). ທ່ານບໍ່ຈຳເປັນຕ້ອງໄປຈື່ຫຍໍ້ຄລາສ໌ນາມທຳທີ່ມັນຄິດຄືນມາເອງ, ການຂຽນແມ່ນ Python ທຳມະດາ, ແຕ່ IDE ຈະຊ່ວຍ Autocomplete ໃຫ້ທ່ານ, ແລະ Type Checker (ເຊັ່ນ Pyright, mypy) ສາມາດກວດຈັບຂໍ້ຜິດພາດກ່ອນທີ່ທ່ານຈະລັນໂຄດເສຍອີກ.
ມັນເປັນ Model-agnostic, ໝາຍຄວາມວ່າບໍ່ໄດ້ຜູກຕິດກັບຜູ້ໃຫ້ບໍລິການໂມເດວໃດໜຶ່ງໂດຍສະເພາະ. ບໍ່ວ່າจะเป็น OpenAI, Anthropic, Google, Groq, Cohere, Mistral, Ollama ແລະອື່ນໆອີກຫຼາຍກວ່າສິບເຈົ້າແມ່ນຮອງຮັບໝົດ, ຖ້າຢາກປ່ຽນໂມເດວປົກກະຕິແລ້ວແມ່ນປ່ຽນພຽງສະຕຣິງດຽວ. ຖ້າຢາກເຂົ້າໃຈວ່າ Agent ແຕກຕ່າງຈາກການເອີ້ນ API ທຳມະດາແນວໃດ, ສາມາດເບິ່ງ AI Agent ຕ່າງຈາກຫຍໍ້ຫຍັງ ກ່ອນໄດ້.
ນຳໄປໃຊ້ເຮັດຫຍໍ້ຫຍັງໄດ້ແດ່
ເວົ້າແບບກົງໄປກົງມາ, ທຸກສະຖານະການທີ່ “ຕ້ອງການໃຫ້ໂມເດວສົ່ງຜົນລັບທີ່ເຊື່ອຖືໄດ້” ຖືວ່າເໝາະສົມທັງໝົດ:
- ການສະກັດໂຄງສ້າງຂໍ້ມູນ (Structured Extraction): ເອົາຈົດໝາຍຮ້ອງຮຽນຂອງລູກຄ້າໂຍນເຂົ້າໄປ, ແລ້ວສັ່ງໃຫ້ມັນຖອກອອກມາເປັນ
ອາລົມ (Sentiment),ໝວດໝູ່ (Category),ຄວາມຮີບດ່ວນ (Urgency)3 ຟີລ໌, ພ້ອມທັງຮັບປະກັນວ່າ Type ຖືກຕ້ອງ. - ການຈັດໝວດໝູ່ ແລະ ຕິດປ້າຍ (Classification & Labelling): ເອກະສານຈຳນວນຫຼາຍທີ່ຕ້ອງຕິດປ້າຍ, ຜົນລັບຖືກຈຳກັດໄວ້ພາຍໃນ Enum ທີ່ທ່ານກຳນົດ, ຖ້າໂມເດວຕອບມົ້ວແມ່ນຈະຖືກຂັດຂວາງ.
- Tool-using Agent: ໃຫ້ໂມເດວສາມາດເອີ້ນຟັງຊັນຂອງທ່ານໄດ້—ກວດສອບຖານຂໍ້ມູນ, ເອີ້ນ Weather API, ຄິດໄລ່ເລກ, ເຟຣມເວີກຈະເປັນຜູ້ແປງ Type ຂອງຟັງຊັນໃຫ້ເປັນຄຳອະທິບາຍເຄື່ອງມືທີ່ໂມເດວສາມາດເຂົ້າໃຈໄດ້.
- RAG Q&A: ຮ່ວມມືກັບ Vector Retrieval, ເຮັດລະບົບຖາມ-ຕອບທີ່ມີຫຼັກຖານອ້າງອີງ, ສ່ວນນີ້ສາມາດອ້າງອີງ ຄູ່ມືການປະຕິບັດ RAG ຂອງພວກເຮົາໄດ້.
ເມື່ອທຽບກັບເຟຣມເວີກໃຫຍ່ທີ່ຮວມທຸກຢ່າງແບບ LangChain, Pydantic AI ຕັ້ງໃຈອອກແບບມາໃຫ້ມີຄວາມເບົາບາງ. ຖ້າທ່ານພຽງແຕ່ຕ້ອງການເຮັດໃຫ້ຜົນລັບຂອງໂມເດວເຊື່ອຖືໄດ້, ແລະບໍ່ຢາກຈື່ຈຳລະບົບນິເວດທັງໝົດພຽງເພື່ອຟັງຊັນນ້ອຍໆ, ເສັ້ນໂຄ້ງການຮຽນຮູ້ຂອງມັນຈະເປັນມິດຕໍ່ຜູ້ໃຊ້ຫຼາຍກວ່າ.
ວິທີໃຊ້: ເລີ່ມຕົ້ນໃຊ້ງານຄັ້ງທຳອິດ
1. ການຕິດຕັ້ງ
bash
pip install pydantic-ai
ແນະນຳໃຫ້ເປີດ Virtual Environment. ເວີຊັນ Python ໃຊ້ 3.9 ຂຶ້ນໄປຈະປອດໄພກວ່າ.
2. ຕັ້ງຄ່າ API Key
ຕົວຢ່າງໃຊ້ Anthropic, ໃຫ້ຕັ້ງ Environment Variable:
bash
export ANTHROPIC_API_KEY=your_api_key
ຖ້າໃຊ້ OpenAI ກ็ໃຫ້ຕັ້ງ OPENAI_API_KEY, ແລະ ອື່ນໆ.
3. ຂຽນ Agent ຕົວທຳອິດ
python
from pydantic_ai import Agent
agent = Agent('anthropic:claude-sonnet-4-6')
result = agent.run_sync('ອະທິບາຍວ່າ Vector Database ຄືຫຍໍ້ຫຍັງໃນປະໂຫຍກດຽວ')
print(result.output)
ພາຣາມິເຕີທຳອິດແມ່ນຊື່ຂອງໂມເດວ, ຮູບແບບແມ່ນ ຜູ້ໃຫ້ບໍລິການ:ໂມເດວ. ຖ້າຢາກປ່ຽນເປັນ OpenAI ກໍປ່ຽນເປັນ 'openai:gpt-4o' ແລະ ອື່ນໆ, ໂຄດສ່ວນທີ່ເຫຼືອບໍ່ຕ້ອງແກ້—ນີ້ຄືຂໍ້ດີຂອງ Model-agnostic.
4. ເຮັດໃຫ້ຜົນລັບມີໂຄງສ້າງ
ນີ້ຄືຈຸດສຳຄັນ. ທ່ານກຳນົດ Pydantic Model ເປັນຮູບແບບຜົນລັບ:
python
from pydantic import BaseModel
from pydantic_ai import Agent
class Review(BaseModel):
sentiment: str # positive / negative / neutral
score: int # 1 ເຖິງ 5
summary: str
agent = Agent('anthropic:claude-sonnet-4-6', output_type=Review)
result = agent.run_sync('ຮ້ານນີ້ອາຫານແຊບແຕ່ລໍຖ້າເກືອບຊົ່ວໂມງໜຶ່ງ, ເກີນໄປໜ້ອຍໜຶ່ງ')
print(result.output.score) # ໄດ້ຮັບຈຳນວນເຕັມໂດຍກົງ, ບໍ່ຕ້ອງ parse ເອງ
print(result.output.sentiment) # ໄດ້ຮັບສະຕຣິງໂດຍກົງ
ຖ້າສິ່ງທີ່ໂມເດວສົ່ງຄືນບໍ່ສອດຄ້ອງກັບ Type ຂອງ Review, ເຟຣມເວີກຈະສົ່ງຂໍ້ຄວາມຜິດພາດກັບຄືນໄປຫາໂມເດວໂດຍອັດຕະໂນມັດເພື່ອໃຫ້ມັນລອງໃໝ່. ເມື່ອທ່ານໄດ້ຮັບ result.output, ມັນແມ່ນ Python Object ທີ່ຜ່ານການກວດສອບແລ້ວ, ແລະ IDE ຍັງຈະຊ່ວຍ Autocomplete ຟີລ໌ຕ່າງໆໃຫ້ທ່ານອີກດ້ວຍ.
5. ມอบ Tool ໃຫ້ Agent
python
from pydantic_ai import Agent
agent = Agent('anthropic:claude-sonnet-4-6')
@agent.tool_plain
def get_weather(city: str) -> str:
"""ກວດສອບສະພາບອາກາດປະຈຸບັນຂອງເມືອງທີ່ກຳນົດ"""
return f'{city} ຕອນນີ້ 28 ອົງສາ, ມື້ອາກາດແຈ່ມໃສ'
result = agent.run_sync('ສະພາບອາກາດທີ່ Taipei ຕອນນີ້ເປັນແນວໃດ?')
print(result.output)
Docstring ນັ້ນບໍ່ໄດ້ຂຽນໄວ້ເພື່ອຄວາມສວຍງາມ—ມັນຈະກາຍເປັນຄຳອະທິບາຍເຄື່ອງມືທີ່ໂມເດວເຫັນ. Type Hint ຂອງຟັງຊັນ (city: str) ກໍຈະຖືກແປງເປັນສະເພາະພາຣາມິເຕີທີ່ໂມເດວເຂົ້າໃຈ, ແລະພາຣາມິເຕີດັ່ງກ່າວກໍຜ່ານການກວດສອບຈາກ Pydantic ເຊັ່ນກັນ.
ເທັກນິກຂັ້ນສູງ
Dependency Injection ແມ່ນຟັງຊັນທີ່ຖືກປະເມີນຄ່າຕ່ຳທີ່ສຸດ. ທ່ານສາມາດໃຊ້ RunContext ເພື່ອສົ່ງການເຊື່ອມຕໍ່ຖານຂໍ້ມູນ, ສະຖານະຜູ້ໃຊ້, API client ຜ່ານ Type Safety ເຂົ້າໄປໃນ Agent ແລະ Tools ໄດ້:
python
from dataclasses import dataclass
from pydantic_ai import Agent, RunContext
@dataclass
class Deps:
user_id: int
db: object # ການເຊື່ອມຕໍ່ຖານຂໍ້ມູນຂອງທ່ານ
agent = Agent('anthropic:claude-sonnet-4-6', deps_type=Deps)
@agent.tool
def get_orders(ctx: RunContext[Deps]) -> str:
return f'ກວດສອບຄຳສັ່ງຊື້ຂອງຜູ້ໃຊ້ {ctx.deps.user_id}'
ເມື່ອຂຽນ Test, ໃຫ້ປ່ຽນ db ເປັນ Mock Object ກໍພໍ, ບໍ່ຕ້ອງແຕະຕ້ອງຖານຂໍ້ມູນຕົວຈິງ, ເຊິ່ງເປັນສິ່ງສຳຄັນຫຼາຍສຳລັບການຂຽນ Unit Test.
Streaming: ສຳລັບການສ້າງເອັບເຟັກການພິມແບບ Real-time, ให้ໃຊ້ agent.run_stream(), ມັນຈະກວດສອບໂຄງສ້າງຜົນລັບໄປພ້ອມໆກັບການສ້າງຂຶ້ນມາ, ເຮັດໃຫ້ປະສົບການຂອງຜູ້ໃຊ້ດີຂຶ້ນຫຼາຍ.
Observability: Pydantic AI ປະສົມປະສານຢ່າງກົມກຽວກັບ Logfire ຈາກທີມງານດຽວກັນ. ຫຼັງຈາກເຊື່ອມຕໍ່ແລ້ວ, ທຸກໆການເອີ້ນໂມເດວ, ທຸກໆການກະຕຸ້ນ Tool, ການໃຊ້ຈຳນວນ Token ໄປເທົ່າໃດ, ໃຊ້ເວລາຈັກວິນາທີ, ແມ່ນສາມາດເຫັນໄດ້ໝົດ. ສິ່ງທີ່ຍາກທີ່ສຸດໃນການ Debug ແອັບພລິເຄຊັນ LLM ແມ່ນ “ເປັນຫຍັງໂມເດວຈึงຕອບແບບນີ້”, ຖ້າມີສິ່ງນີ້ແລ້ວ ທ່ານກໍບໍ່ຈຳເປັນຕ້ອງຄາດເດົາອີກຕໍ່ໄປ. ຖ້າຢາກວາງແຜນ Agent ໃຫ້ສົມບູນຍິ່ງຂຶ້ນ, ສามารถອ່ານຮ່ວມກັບ ຄູ່ມືການພັດທະນາ AI Agent ຂອງພວກເຮົາ.
ຂໍ້ຜິດພາດທົ່ວໄປ ແລະ ຂໍ້ຄວນລະວັງ
- ຄິດວ່າການໃສ່ output_type ຈະປອດໄພ 100%: ເຟຣມເວີກຈະສັ່ງໃຫ້ໂມເດວລອງໃໝ່ເມື່ອການກວດສອບລົ້ມເຫຼວ, ແຕ່ການລອງໃໝ່ມີຂອບເຂດຈຳກັດ. ຖ້າລົ້ມເຫຼວຊ້ຳໆ ມັນຈະໂຍນ Exception ອອກມາ, ທ່ານຍັງຄົງຕ້ອງ try/except ຢູ່. ການກວດສອບ Type ຊ່ວຍຫຼຸດຜ່ອນ “ຂໍ້ມູນເປື້ອນທີ່ຫຼຸດລອດເຂົ້າໄປໃນລະບົບ”, ບໍ່ແມ່ນ “ໂມເດວຈະບໍ່ຜິດພາດເລີຍ”.
- ຂຽນ Docstring ຂອງ Tool ແບບລວກໆ: ໂມເດວອາໄສ Docstring ທັງໝົດໃນການຕັດສິນໃຈວ່າຄວນເອີ້ນ Tool ເວລາໃດ. ຖ້າຂຽນແບບບໍ່ຈະແຈ້ງ, ໂມເດວຈະເອີ້ນແບບມົ້ວໆ ຫຼື ບໍ່ເອີ້ນເລີຍ. ໃຫ້ຄິດວ່າມັນຄືຄູ່ມືການໃຊ້ງານທີ່ຂຽນໃຫ້ໂມເດວອ່ານ.
- ໃສ່ເຫດຜົນຫຼາຍເກີນໄປໃນ Tool ແຕ່ບໍ່ຈັດການ Exception: ຖ້າໂຄດໃນ Tool ເກີດຂໍ້ຜິດພາດ, ຂໍ້ຄວາມຈະຖືກສົ່ງກັບຄືນໄປຫາໂມເດວ, ເຊິ່ງໂມເດວອາດຈະວນໄປວນມາຢູ່ກັບຂໍ້ຜິດພາດນັ້ນຈົນໝົດ Token ຈຳນວນຫຼາຍ. Exception ໃດທີ່ຄວນປ້ອງກັນ ກໍໃຫ້ຂຽນປ້ອງກັນໄວ້ເອງ.
- ບໍ່ສົນໃຈຄ່າໃຊ້ຈ່າຍ (Cost): ການລອງໃໝ່ຂອງ Structured Output, ການເອີ້ນ Tool ຫຼາຍຮອບ, ການໃຊ້ Token ຈະໄວກວ່າທີ່ທ່ານຄິດ. ກ່ອນນຳຂຶ້ນລະບົບ Production ຕ້ອງເຊື່ອມຕໍ່ Observability ໃຫ້ຮຽບຮ້ອຍ ເພື່ອເບິ່ງຄ່າໃຊ້ຈ່າຍຕົວຈິງໃຫ້ຊັດເຈນ.
- ໃຊ້ມັນເປັນເຟຣມເວີກໃຫຍ່: ມັນຖືກຕັ້ງໃຈອອກແບບມາໃຫ້ເບົາບາງ. ຖ້າທ່ານຕ້ອງການການຈັດລຳດັບຫຼາຍຂັ້ນຕອນທີ່ສັບສົນ, ຫຼື ຕົວເຊື່ອມຕໍ່ສຳເລັດຮູບຈຳນວນຫຼາຍ, LlamaIndex ຫຼື ເວບໄຊທາງເລືອກອື່ນອາດຈະສະດວກກວ່າ, ຢ່າຝືນໃຊ້.
ຄວາມເຫັນຈາກ TheAI學院
ເວົ້າຕາມກົງ, ເຟຣມເວີກ Agent ໃນທ້ອງຕະຫຼາດມີຫຼາຍຈົນເຮັດໃຫ້ເກີດອາການເລືອກບໍ່ຖືກ, ແຕ່ Pydantic AI ແກ້ໄຂບັນຫາທີ່ສະເພາະເຈາະຈົງຫຼາຍ, ເຊິ່ງຜູ້ພັດທະນາ LLM ທຸກຄົນເຄີຍພົບເຈິມາແລ້ວ: ຜົນລັບທີ່ບໍ່ໜ້າເຊື່ອຖື. ມັນບໍ່ໄດ້ຕັ້ງໃຈທີ່ຈະເປັນ “ເຟຣມເວີກທີ່ແຂງແກ່ງທີ່ສຸດໃນຈັກກະວານ”, ແຕ່ມັນພຽງແຕ່ນຳເອົາເລື່ອງ “Type Safety” ທີ່ວົງການ Python ເຄີຍໃຫ້ຄວາມສຳຄັນ ມານຳໃຊ້ເຂົ້າໃນການພັດທະນາ AI ຢ່າງສະອາດ. ສຳລັບຜູ້ທີ່ຄຸ້ນເຄີຍກັບວິທີຂຽນ FastAPI ແລະ Pydantic ຢູ່ແລ້ວ, แทบจะບໍ່ມີຕົ້ນທຶນໃນການຮຽນຮູ້ເລີຍ.
ມັນຈະບໍ່ເຮັດໃຫ້ໂມເດວຂອງທ່ານສະຫຼາດຂຶ້ນ, ແຕ່ມັນຈະເຮັດໃຫ້ໂຄດຂອງທ່ານໜ້າເຊື່ອຖືຂຶ້ນ—ແລະ ສິ່ງຫຼັງນີ້ຕ່າງຫາກຄືສິ່ງທີ່ຈະຊ່ວຍຊີວິດທ່ານໄດ້ແທ້ໆ ເມື່ອຂຶ້ນລະບົບ Production ແລ້ວ.
ຖ້າທ່ານກຳລັງ
ຄຳຖາມທີ່ພົບເລື້ອຍ
Pydantic AI ຕ່າງຈາກ LangChain ແນວໃດ, ຄວນເລືອກອັນໃດ?
ຄວາມແຕກຕ່າງທີ່ໃຫຍ່ທີ່ສຸດແມ່ນ "ນ້ຳໜັກ". LangChain ຖຶກອອກແບບມາເປັນລະບົບນິເວດຂະໜາດໃຫຍ່, ມີ Connector, ການເຊື່ອມໂຍງ ແລະ ຊັ້ນ Abstract ຫຼາຍ, ເໝາະສຳລັບໂຄງການໃຫຍ່ທີ່ຕ້ອງການການຈັດການທີ່ສັບສົນ, ແຕ່ເສັ້ນທາງການຮຽນຮູ້ແມ່ນສູງຊັນ. Pydantic AI ຕັ້ງໃຈສ້າງໃຫ້ມັນບາງເບົາ, ຫຼັກໆມີພຽງແຕ່ Agent, ເຄື່ອງມື (Tools), Dependency Injection ແລະ ຜົນລັບທີ່ມີໂຄງສ້າງ, ຈຸດເດັ່ນແມ່ນຄວາມປອດໄພຂອງ Type. ຖ້າຄວາມຕ້ອງການຂອງທ່ານແມ່ນ "ເຮັດໃຫ້ຜົນລັບຂອງໂມເດວເຊື່ອຖືໄດ້, ການຂຽນລະຫັດໃກ້ຄຽງກັບ Python ພື້ນຖານ", Pydantic AI ຈະເລີ່ມຕົ້ນໄດ້ໄວກວ່າຫຼາຍ; ຖ້າທ່ານຕ້ອງການການເຊື່ອມໂຍງທີ່ພ້ອມໃຊ້ງານຈຳນວນຫຼາຍ, LangChain ຈະສະດວກກວ່າ. ທັງສອງຢ່າງນີ້ບໍ່ຂັດແຍ້ງກັນ, ໃຫ້ເລືອກຕາມຂະໜາດຂອງໂຄງການ.
ຈຳເປັນຕ້ອງໃຊ້ໂມເດວຂອງ OpenAI ບໍ? ສามารถເຊື່ອມຕໍ່ກັບໂມເດວໃນເຄື່ອງ (Local) ໄດ້ບໍ?
ບໍ່ ຈຳ ເປັນ. Pydantic AI ແມ່ນ Model-agnostic, ຮອງຮັບ OpenAI, Anthropic, Google, Groq, Mistral, Cohere, Ollama ແລະ ອື່ນໆອີກຫຼາຍສິບແຫ່ງ, ການປ່ຽນໂມເດວມັກຈະປ່ຽນພຽງແຕ່ສະຕຣິງ (String) ໂຕດຽວຕອນສ້າງ Agent. ຖ້າຕ້ອງການຣັນໂມເດວໃນເຄື່ອງແມ່ນສາມາດຜ່ານ Ollama ໄດ້, ໂດຍການຊີ້ສະຕຣິງໂມເດວໄປຫາ სერვერ ພາຍໃນເຄື່ອງ, ສ່ວນອື່ນໆຂອງໂປຣແກຣມບໍ່ຈຳເປັນຕ້ອງແກ້ໄຂ.
ຜົນລັບທີ່ມີໂຄງສ້າງສາມາດຮັບປະກັນໄດ້ແທ້ບໍວ່າໂມເດວຈະບໍ່ຕອບມົ່ວ?
ບໍ່ສາມາດຮັບປະກັນໄດ້ວ່າຕົວໂມເດວຈະບໍ່ຜິດພາດ, ແຕ່ສາມາດຮັບປະກັນໄດ້ວ່າ "ຂໍ້ມູນທີ່ບໍ່ສອດຄ້ອງກັບ Type ທີ່ທ່ານກຳນົດໄວ້ຈະບໍ່ຫຼຸດລອດເຂົ້າໄປໃນລະບົບ". ເມື່ອໂມເດວສົ່ງສິ່ງທີ່ບໍ່ຜ່ານການກວດສອບຂອງ Pydantic ມາ, ໂຄງຮ່າງ (Framework) ຈະສົ່ງຂໍ້ຄວາມຜິດພາດກັບຄືນໄປໃຫ້ມັນລອງໃໝ່ໂດຍອັດຕະໂນມັດ. ແຕ່ການລອງໃໝ່ມີຂອບເຂດຈຳກັດ, ຖ້າຜິດພາດຕໍ່ເນື່ອງມັນຈະແຈ້ງຂໍ້ຍົກເວັ້ນ (Exception) ອອກມາ, ດັ່ງນັ້ນທ່ານຈຶ່ງຍັງຕ້ອງໃຊ້ try/except ເພື່ອຈັດການກັບກໍລະນີທີ່ຮ້າຍແຮງທີ່ສຸດ. ສິ່ງທີ່ມັນຫຼຸດຜ່ອນແມ່ນຄວາມສ່ຽງຂອງຂໍ້ມູນເປື້ອນ, ບໍ່ແມ່ນບັນຫາຄວາມສະຫຼາດຂອງໂມເດວ.
ມືໃໝ່ທີ່ຍังບໍ່ເຄີຍຂຽນ Pydantic มาก่อน, ຮຽນອັນນີ້ຈະຍາກບໍ?
ຖ້າທ່ານມີພື້ນຖານ Python ແລະ Type Hints ລະດັບພື້ນຖານ, ປະຕູກ້າວເຂົ້າສູ່ແມ່ນບໍ່ສູງ. ຫົວໃຈຫຼັກຂອງ Pydantic ແມ່ນ "ການໃຊ້ Class ເພື່ອກຳນົດລັກສະນະຂອງຂໍ້ມູນ", ວິທີຂຽນແມ່ນເຂົ້າໃຈງ່າຍ. ແນະນຳໃຫ້ໃຊ້ເວລາສິບນາທີເບິ່ງວິທີທີ່ Pydantic ກຳນົດ BaseModel ກ່ອນ, ແລ້ວຄືນມາຂຽນ Agent, ມັນຈະລຽບງ່າຍຂຶ້ນຫຼາຍ. ມາດຕະຖານແນວຄວາມຄິດທີ່ແທ້ຈິງແມ່ນແນວຄິດການອອກແບບ Agent ແລະ ເຄື່ອງມື, ສามารถຮຽນຮູ້ໄປພ້ອມກັບຄູ່ມືການພັດທະນາ Agent ຂອງພວກເຮົາໄດ້.