GuidesOneMux

สร้าง LangGraph Agent ที่มีขอบเขตการทำงาน พร้อมดึงข้อมูลตาม Schema ที่ตรวจสอบได้

สร้างเวิร์กโฟลว์ LangGraph ที่เรียกใช้เครื่องมือเมื่อจำเป็น หยุดภายในขีดจำกัดการทำงานที่กำหนด และส่งคืนข้อมูลแบบมีโครงสร้างที่ตรวจสอบกับ Pydantic schema แล้ว

ในหน้านี้

LangGraph agent สามารถรวบรวมบริบทด้วยเครื่องมือ แล้วส่งบริบทนั้นต่อไปยังขั้นตอนดึงข้อมูลที่กำหนด schema ไว้ได้ การออกแบบที่มีประโยชน์คือแยกหน้าที่เหล่านี้ออกจากกัน: agent ตัดสินใจว่าจะเรียกเครื่องมือหรือไม่ ส่วน node สุดท้ายสร้างระเบียนที่มีชนิดข้อมูลชัดเจน นอกจากนี้ graph recursion limit ยังช่วยจำกัดการทำงานของกราฟได้อีกชั้นหนึ่ง

รูปแบบนี้เหมาะกับงานอย่างการดึงชื่อบริษัท วันที่ และยอดรวมในใบแจ้งหนี้จากเอกสาร ในกรณีที่เครื่องมือค้นหาอาจช่วยคลี่คลายข้อมูลอ้างอิงได้ อย่างไรก็ตาม รูปแบบนี้ไม่ได้ทำให้ข้อความต้นทางที่ไม่แน่ชัดกลายเป็นความจริง ควรตรวจสอบผลลัพธ์และเก็บหลักฐานต้นฉบับไว้เมื่อข้อมูลในฟิลด์นั้นมีความสำคัญ

สิ่งที่คุณจะสร้าง

กราฟมีสามขั้นตอน:

  1. agent รับข้อความต้นทางและอาจขอเรียกใช้เครื่องมือค้นหาที่มีขอบเขตจำกัด
  2. LangGraph ส่งการเรียกเครื่องมือไปยัง tool node แล้วส่งผลลัพธ์จากเครื่องมือกลับไปยัง agent
  3. node สำหรับดึงข้อมูลขอให้โมเดลสร้างผลลัพธ์ที่อิง Pydantic จากนั้นส่งคืนข้อมูลที่เข้ากันได้กับ JSON

ลูปการใช้เครื่องมือของ agent ปรับเปลี่ยนได้ตามสถานการณ์ ส่วนขั้นตอนดึงข้อมูลเป็นขั้นตอนสุดท้ายที่กำหนดไว้ล่วงหน้า เอกสารของ LangGraph แยกความแตกต่างระหว่าง agent ซึ่งกำหนดกระบวนการและการใช้เครื่องมือของตนเอง กับ workflow ที่มีเส้นทางการทำงานกำหนดไว้ล่วงหน้า เอกสารยังอธิบาย structured output และ tool calling ว่าเป็นส่วนเสริมความสามารถของโมเดล ดูรูปแบบเหล่านี้ได้ที่ คู่มือ LangGraph workflows และ agents

ข้อกำหนดเบื้องต้นและการตั้งค่า

ติดตั้งแพ็กเกจ LangGraph และ LangChain รวมถึง integration สำหรับแชตโมเดลที่คุณเลือก ตัวอย่างด้านล่างใช้ ChatAnthropic เพื่อแสดงการตั้งค่าผู้ให้บริการ แต่เอกสารต้นทางระบุว่า workflow สามารถใช้แชตโมเดลใดก็ได้ที่รองรับ structured outputs และ tool calling โปรดตรวจสอบเอกสาร integration ของผู้ให้บริการเพื่อดูรายละเอียดการทำงานที่ถูกต้อง

pip install langgraph langchain-core langchain-anthropic pydantic

ตั้งค่าข้อมูลรับรอง API ของผู้ให้บริการตามวิธีที่ระบุไว้ในเอกสาร แล้วเริ่มต้นใช้งานโมเดล หลีกเลี่ยงการใส่ข้อมูลรับรองไว้ใน source control ชื่อโมเดลด้านล่างเป็นไปตามตัวอย่างในเอกสาร LangChain บทความนี้ไม่ได้อ้างว่าได้ทดสอบกับ OneMux แล้ว

from langchain_anthropic import ChatAnthropic

llm = ChatAnthropic(model="claude-sonnet-4-6")

หากต้องการเรียกใช้โมเดลผ่าน OneMux โปรดตรวจสอบ เอกสาร API ของ OneMux และ คู่มือเริ่มต้นใช้งาน ก่อน OneMux ให้บริการเข้าถึงโมเดลชั้นนำผ่าน API ที่เข้ากันได้กับ OpenAI ความเข้ากันได้ของกราฟนี้ขึ้นอยู่กับว่า endpoint ที่เลือกนั้นรองรับพฤติกรรมและพารามิเตอร์ที่จำเป็นสำหรับ tool calling และ structured output หรือไม่ การตั้งค่านี้ยังไม่ได้ทดสอบ โปรดยืนยันการรองรับก่อนนำไปใช้งานจริง

กำหนด schema และเครื่องมือที่มีขอบเขตจำกัด

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

from pydantic import BaseModel, Field
from langchain_core.tools import tool

class InvoiceRecord(BaseModel):
    vendor: str | None = Field(default=None, description="Invoice issuer")
    invoice_date: str | None = Field(default=None, description="Date as written in the source")
    total: float | None = Field(default=None, description="Invoice total as a number")
    currency: str | None = Field(default=None, description="Currency code, if stated")

@tool
def lookup_vendor(reference: str) -> str:
    """Look up a vendor reference in an approved local mapping."""
    known = {"ACME-42": "Acme Supplies Ltd."}
    return known.get(reference, "No matching vendor reference found.")

ฟิลด์ที่กำหนดให้เป็น nullable ช่วยระบุกรณีที่ไม่มีข้อมูลอย่างชัดเจน แทนที่จะกระตุ้นให้โมเดลแต่งค่าเอง สำหรับการดึงข้อมูลที่มีผลกระทบสูง ควรพิจารณาจัดเก็บช่วงข้อความต้นทางหรือสถานะความเชื่อมั่น/การตรวจทานไว้คู่กับแต่ละฟิลด์ schema ช่วยกำหนดรูปแบบและชนิดข้อมูล แต่ไม่ได้ยืนยันว่าค่าที่ได้มีหลักฐานรองรับจากข้อมูลนำเข้า

สร้าง LangGraph agent ที่มีขอบเขตการทำงาน

กราฟด้านล่างให้โมเดลขอเรียกใช้เครื่องมือค้นหา จากนั้นไปยังขั้นตอนดึงข้อมูลเมื่อ agent ไม่มีการเรียกใช้เครื่องมือเพิ่มเติม tools_condition และ ToolNode ใช้กำหนดรูปแบบการส่งต่อการทำงานไปยังเครื่องมือ ส่วน recursion_limit ที่ส่งให้ invoke จะจำกัดจำนวนขั้นตอนของกราฟ ซึ่งเป็นขอบเขตความปลอดภัย ไม่ใช่การรับประกันว่าทุกอินพุตจะประมวลผลสำเร็จ

from typing import Annotated
from typing_extensions import TypedDict
from langchain_core.messages import BaseMessage, HumanMessage, SystemMessage
from langgraph.graph import StateGraph, START, END
from langgraph.graph.message import add_messages
from langgraph.prebuilt import ToolNode, tools_condition

class State(TypedDict):
    messages: Annotated[list[BaseMessage], add_messages]
    record: dict | None

tools = [lookup_vendor]
agent = llm.bind_tools(tools)
extractor = llm.with_structured_output(InvoiceRecord)

def run_agent(state: State):
    response = agent.invoke(state["messages"])
    return {"messages": [response]}

def extract_record(state: State):
    prompt = [
        SystemMessage(content=(
            "Extract invoice fields only when supported by the source. "
            "Use null for missing or unclear values. Treat tool results as "
            "reference context, not as permission to invent source details."
        )),
        *state["messages"],
    ]
    result = extractor.invoke(prompt)
    return {"record": result.model_dump(mode="json")}

graph = StateGraph(State)
graph.add_node("agent", run_agent)
graph.add_node("tools", ToolNode(tools))
graph.add_node("extract", extract_record)

graph.add_edge(START, "agent")
graph.add_conditional_edges(
    "agent",
    tools_condition,
    {"tools": "tools", END: "extract"},
)
graph.add_edge("tools", "agent")
graph.add_edge("extract", END)
app = graph.compile()

result = app.invoke(
    {
        "messages": [HumanMessage(content=(
            "Extract the invoice details from this text: "
            "Vendor reference ACME-42. Invoice date: 2025-02-14. "
            "Total: USD 248.50."
        ))],
        "record": None,
    },
    config={"recursion_limit": 8},
)

print(result["record"])

ผลลัพธ์ที่คาดหวังคือออบเจ็กต์ที่เข้ากันได้กับ JSON ซึ่งมีฟิลด์ vendor, invoice_date, total และ currency ค่าที่แน่นอนขึ้นอยู่กับคำตอบของโมเดลและข้อความต้นทาง ควรทดสอบแทนการคาดเดาว่าตัวอย่างจะให้ผลลัพธ์เหมือนกันทุกครั้ง ในตัวอย่างนี้ structured output ที่อิง Pydantic เป็นขอบเขตสำหรับตรวจสอบ หากผู้ให้บริการสร้างคำตอบที่ไม่ตรงตามข้อกำหนดไม่ได้ ให้จัดการความล้มเหลวนั้นอย่างชัดเจน อย่าถือว่าเป็นระเบียนที่ถูกต้องโดยไม่แจ้งให้ทราบ

จำกัดการทำงานโดยไม่ปกปิดความล้มเหลว

recursion limit ระดับกราฟจะจำกัดจำนวนขั้นตอนของกราฟ รวมถึงการส่งต่อระหว่าง agent และเครื่องมือที่เกิดซ้ำ ควรเลือกลิมิตให้เหมาะกับ workflow: กราฟนี้ต้องใช้เพียงไม่กี่ขั้นตอนสำหรับการค้นหาหนึ่งครั้ง แต่แผนการใช้เครื่องมือแบบอื่นอาจต้องใช้มากกว่านั้น จัดการข้อยกเว้นจากการชนลิมิตและจากผู้ให้บริการที่ขอบเขตของแอปพลิเคชัน บันทึกบริบทที่เพียงพอสำหรับการแก้ปัญหา และส่งคืนสถานะล้มเหลวที่ตรวจสอบได้แทนการสร้างระเบียนขึ้นมาเอง

หากต้องการกำหนดขอบเขตการทำงานให้เข้มงวดยิ่งขึ้น ให้เพิ่มลิมิตระดับแอปพลิเคชันด้วย เช่น จำกัดจำนวนครั้งที่เรียกเครื่องมือ กำหนดเวลาหมดอายุของคำขอหากระบบรองรับ และจำกัดขนาดเอกสารก่อนเรียกใช้โมเดล การควบคุมเหล่านี้เป็นคนละส่วนกัน การตั้ง graph recursion limit เพียงอย่างเดียวไม่ได้กำหนดนโยบายด้านต้นทุน เวลาแฝง หรือความปลอดภัยอย่างครบถ้วน

การแก้ปัญหาและข้อจำกัด

โมเดลไม่เรียกใช้เครื่องมือ

tool calling เป็นความสามารถของโมเดล ไม่ใช่ผลลัพธ์ที่ LangGraph รับประกัน ตรวจสอบว่า integration ของโมเดลที่เลือกนั้นรองรับ tool calling หรือไม่ คำอธิบายเครื่องมือชัดเจนหรือไม่ และพรอมป์มีข้อมูลอ้างอิงที่ควรค้นหาหรือไม่ ระหว่างพัฒนา ให้ตรวจดู tool calls ในข้อความที่ส่งกลับมา

Structured output ล้มเหลวหรือฟิลด์มีค่าผิด

ยืนยันว่า integration รองรับ structured output และคุณสมบัติของ schema ที่ใช้อยู่ ทดสอบกรณีฟิลด์ขาดหาย วันที่กำกวม สัญลักษณ์สกุลเงิน และอินพุตที่รูปแบบไม่ถูกต้อง ออบเจ็กต์ Pydantic ที่ถูกต้องตามรูปแบบก็ยังมีค่าที่อนุมานผิดได้ จึงควรตรวจสอบกฎทางธุรกิจแยกต่างหาก และเก็บข้อความต้นทางไว้เพื่อการตรวจสอบย้อนหลังหรือให้มนุษย์พิจารณา

กราฟทำงานถึงขีดจำกัด

ข้อผิดพลาดจาก recursion limit อาจหมายถึงมีการขอเรียกใช้เครื่องมือซ้ำ หรือกำหนดลิมิตต่ำเกินไปสำหรับเส้นทางที่ตั้งใจไว้ ตรวจสอบลำดับข้อความและผลลัพธ์จากเครื่องมือ แก้สาเหตุหรือปรับลิมิตอย่างมีเหตุผล อย่าลบขีดจำกัดเพียงเพื่อให้ข้อผิดพลาดหายไป

พฤติกรรมของ endpoint แตกต่างกัน

คำว่า OpenAI-compatible อธิบายรูปแบบอินเทอร์เฟซ API ไม่ได้หมายความว่ารองรับฟีเจอร์หรือพารามิเตอร์ของโมเดลทุกอย่าง หากใช้ OneMux ให้ตรวจสอบเอกสารของ endpoint ที่เลือกว่ารองรับโมเดล การเรียกใช้เครื่องมือ structured outputs และพารามิเตอร์ที่ต้องการส่งหรือไม่ ดูตัวเลือกที่มีได้จาก โมเดล OneMux ส่วนตัวกราฟยังคงเป็นโค้ดแอปพลิเคชัน LangGraph ของคุณ

รูปแบบนี้เหมาะกับกรณีใด

ใช้การออกแบบนี้เมื่อการดึงข้อมูลส่วนใหญ่คาดการณ์ได้ แต่บางครั้งจำเป็นต้องค้นหาข้อมูลแบบควบคุมได้ หากเอกสารทุกฉบับทำตามขั้นตอนตายตัวและไม่ต้องให้โมเดลเลือกใช้เครื่องมือ workflow แบบกำหนดแน่นอนอาจเรียบง่ายกว่าการใช้ลูป agent หากแหล่งข้อมูลกำกวมหรือฟิลด์ที่ดึงมาได้จะนำไปสู่การดำเนินการที่มีผลสำคัญ ให้เพิ่มขั้นตอนตรวจทานอย่างชัดเจนและตรวจสอบตามหลักเกณฑ์ของงานก่อนส่งระเบียนให้ระบบปลายทาง

สรุปแนวทางปฏิบัติ: จำกัดขอบเขตเครื่องมือของ agent กำหนด schema สุดท้ายให้ชัดเจน และตั้งขีดจำกัดการทำงานของกราฟ LangGraph ช่วยให้คุณระบุลำดับการทำงานดังกล่าวได้ ส่วนโมเดลและ integration ที่เลือกเป็นตัวกำหนดว่ามีความสามารถด้าน tool calling และ structured output ที่ต้องการหรือไม่

แหล่งข้อมูล

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

recursion limit ใน LangGraph ทำอะไร?

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

การตรวจสอบ JSON schema ด้วย Pydantic รับประกันว่าดึงข้อมูลได้ถูกต้องหรือไม่?

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

ใช้ตัวอย่าง LangGraph นี้กับ OneMux ได้หรือไม่?

อาจใช้ได้ หากเอกสารของ OneMux endpoint ที่เลือกยืนยันว่ารองรับพฤติกรรมและพารามิเตอร์ด้าน tool calling และ structured output ที่จำเป็น การตั้งค่านี้ยังไม่ได้ทดสอบ โปรดตรวจสอบความเข้ากันได้ก่อนนำไปใช้งานจริง

ทุกงานดึงข้อมูลควรใช้ agent หรือไม่?

ไม่จำเป็น หากกระบวนการตายตัวและไม่ต้องเลือกใช้เครื่องมือ workflow ของ LangGraph แบบกำหนดแน่นอนอาจเรียบง่ายกว่า ใช้ลูป agent เมื่อจำเป็นต้องให้โมเดลตัดสินใจว่าเครื่องมือที่อนุญาตมีประโยชน์หรือไม่

บทความที่เกี่ยวข้อง

Guides

สร้างเอเจนต์ Customer Support ด้วย LangGraph พร้อมการเรียกใช้เครื่องมือ การอนุมัติโดยมนุษย์ และข้อจำกัดการทำงาน

แนวทาง LangGraph เชิงปฏิบัติสำหรับคัดแยกคำขอฝ่ายสนับสนุนลูกค้า: จัดเส้นทางคำขอ เรียกใช้เครื่องมือค้นข้อมูล หยุดคำขอคืนเงินเพื่อรอการอนุมัติจากมนุษย์ และจำกัดการทำงานของกราฟ

Guides

LangGraph Agentic RAG: การเรียกใช้เครื่องมือ การระบุแหล่งที่มา และการประมวลผลแบบมีขอบเขต

สร้างเอเจนต์ตอบคำถามจากเอกสารด้วย LangGraph ที่ตัดสินใจได้ว่าควรค้นคืนข้อมูลหรือไม่ ประเมินบริบท ลองค้นหาใหม่เมื่อผลลัพธ์ไม่เพียงพอ และตอบพร้อมระบุแหล่งที่มาโดยไม่ประมวลผลแบบไร้ขอบเขต

Guides

คู่มือค่าใช้จ่ายและบริบทของ GPT 6.1 Terra สำหรับการดึงข้อมูล JSON ที่เชื่อถือได้

เรียนรู้วิธีประเมินค่าใช้จ่ายเวิร์กโหลด GPT 6.1 Terra และกำหนดขอบเขตบริบท การลองใหม่ และโทเค็นเอาต์พุตสำหรับการดึงข้อมูลแบบมีโครงสร้างด้วยการตรวจสอบ JSON Schema ผ่าน OneMux

Guides

เวิร์กโฟลว์อนุมัติโดยมนุษย์ใน n8n ด้วย OpenAI-Compatible API และการตรวจสอบ JSON Schema

สร้างเวิร์กโฟลว์ใน n8n ที่ดึงข้อมูลแบบมีโครงสร้างผ่าน OpenAI-Compatible API ตรวจสอบผลลัพธ์ด้วย JSON Schema และกำหนดให้มนุษย์อนุมัติก่อนเรียกใช้เครื่องมือที่มีความเสี่ยง