วิธีแก้ไขปัญหาลืมความจำของ LangChain Agent ในการสนทนาที่ยาวนาน

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

คู่มือนี้ปฏิบัติตามเอกสารทางการของ LangChain ตามที่ตรวจสอบเมื่อ 11 กันยายน 2026 เอกสารปัจจุบันแนะนำให้ใช้ langchain.agents.create_agent สำหรับ agent ใหม่ และอธิบายว่า LangGraph persistence คือระบบความจำพื้นฐาน ตัวอย่างเก่าที่อิงจาก ConversationChain, ConversationBufferMemory หรือ initialize_agent อาจยังคงปรากฏในเนื้อหาเก่า แต่คู่มือการย้ายระบบของ LangChain v1 ได้ย้าย chains เก่าและฟังก์ชันที่เลิกใช้แล้วไปยัง langchain-classic ดูที่ คู่มือการย้ายระบบ LangChain v1 อย่างเป็นทางการ

“การลืมความจำ” ใน LangChain หมายถึงอะไรจริงๆ

ก่อนจะเปลี่ยนโค้ด ให้แยกแยะปัญหาสามประการที่มักดูเหมือนเหมือนกันจากมุมมองของผู้ใช้

เอกสาร ความจำระยะสั้นของ LangChain กำหนดให้ความจำระยะสั้นคือสถานะภายในเธรดเดียว เอกสาร ความจำระยะยาวของ LangChain กำหนดให้ความจำระยะยาวคือข้อมูลที่คงอยู่ข้ามการสนทนาและเซสชันที่แตกต่างกัน

สิ่งที่คุณต้องการก่อนเริ่มต้น

คุณต้องมีแอปพลิเคชัน LangChain/LangGraph เวอร์ชันปัจจุบัน, การเชื่อมต่อโมเดล และสถานที่สำหรับเก็บสถานะอย่างถาวร สำหรับการทดลองในเครื่อง InMemorySaver เพียงพอ สำหรับการผลิต ให้ใช้ checkpointer ที่เชื่อมต่อกับฐานข้อมูล เอกสารทางการของ LangChain แสดงตัวอย่าง PostgreSQL ผ่านแพ็กเกจแยกชื่อ langgraph-checkpoint-postgres

รักษาตัวระบุสี่ประการให้ชัดเจน:

• Conversation หรือ Chat ID: ตัวระบุที่แอปพลิเคชันของคุณเปิดเผยต่อผู้ใช้
• thread_id: คีย์การคงอยู่ของ LangGraph ที่ใช้เพื่อเรียกคืนสถานะของเธรดหนึ่ง
• User ID: ตัวระบุถาวรที่ใช้สำหรับกำหนดขอบเขต (namespace) ของความจำระยะยาว
• Memory key: คีย์สำหรับรายการถาวรหนึ่งรายการภายใน namespace ของ store

ค่าเหล่านี้ไม่ควรเป็นค่าเดียวกันโดยอัตโนมัติ ผู้ใช้หนึ่งคนอาจมีหลายเธรด และเธรดหนึ่งอาจมีข้อเท็จจริงหลายข้อ

ขั้นตอนที่ 1: ทำซ้ำความล้มเหลวด้วยการทดสอบสองคำขอ

เริ่มด้วยการทดสอบที่เล็กที่สุดเท่าที่จะเป็นไปได้ ขอให้ agent จำรายละเอียดเฉพาะตัว จากนั้นเรียกใช้อีกครั้งและถามหารายละเอียดนั้น อย่าทดสอบความจำด้วยการเรียก invoke() เพียงครั้งเดียว เพราะโมเดลสามารถเห็นทุกอย่างในคำขอนั้นแม้ว่าการคงอยู่จะเสียหาย

config = {"configurable": {"thread_id": "debug-thread-001"}}

agent.invoke(
    {"messages": [{"role": "user", "content": "Remember that my project codename is Juniper."}]},
    config,
)

result = agent.invoke(
    {"messages": [{"role": "user", "content": "What is my project codename?"}]},
    config,
)

หากคำขอที่สองลืม “Juniper” ให้ตรวจสอบการตั้งค่า checkpointer และ thread_id จริงก่อนจะเปลี่ยน prompt

ขั้นตอนที่ 2: เพิ่ม Checkpointer สำหรับความจำในเธรดเดียวกัน

Checkpointer เก็บภาพรวม (snapshots) ของสถานะกราฟของ agent อย่างถาวร LangGraph ใช้มันสำหรับความจำระยะสั้น, การกู้คืนจากการหยุดชะงัก, กระบวนการที่มีมนุษย์ร่วม (human-in-the-loop) และความทนทานต่อความผิดพลาด คู่มือการคงอยู่ปัจจุบันอธิบายว่า checkpointers มีขอบเขตจำกัดในเธรด และระบุว่าแอปพลิเคชันเข้าถึงสถานะโดยส่ง thread_id ดูที่ คู่มือการคงอยู่ของ LangGraph อย่างเป็นทางการ

from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

checkpointer = InMemorySaver()

agent = create_agent(
    model="your-provider:your-model",
    tools=[],
    checkpointer=checkpointer,
)

config = {"configurable": {"thread_id": "customer-42:case-7"}}

InMemorySaver เหมาะอย่างยิ่งสำหรับการยืนยันว่าการเชื่อมต่อเธรดของคุณทำงานได้ แต่เก็บ checkpoints ไว้ใน RAM LangGraph เตือนอย่างชัดเจนว่า MemorySaver/InMemorySaver ไม่คงอยู่ข้ามการรีสตาร์ทกระบวนการ

ขั้นตอนที่ 3: ใช้ thread_id เดิมสำหรับการสนทนาเดียวกัน

บั๊กในระดับแอปพลิเคชันที่พบบ่อยที่สุดคือการสร้าง thread_id ใหม่ในทุกคำขอ HTTP ฐานข้อมูลอาจทำงานได้อย่างสมบูรณ์แบบ ในขณะที่ทุกคำขอเริ่มเธรด LangGraph ที่แตกต่างกัน

ตัวอย่างเช่น สมมติว่าส่วนหน้าของระบบของคุณมี chat ID เป็น chat_8bf4 ให้แมปค่าดังกล่าวไปยังเธรด LangGraph อย่างแน่นอน (deterministically) และใช้มันซ้ำสำหรับทุกการสนทนาในแชทนั้น แชทใหม่ควรได้รับ thread ID ใหม่

อย่าใช้ thread_id ถาวรเพียงค่าเดียวสำหรับแชททั้งหมดที่เป็นของผู้ใช้เดียวกัน สิ่งนั้นจะรวมการสนทนาที่ไม่เกี่ยวข้องกันให้เป็นสตรีมสถานะเดียว หากคุณใช้ PostgreSQL คำแนะนำการแก้ไขปัญหาปัจจุบันของ LangGraph ยังระบุว่า thread_id ควรยาวไม่เกิน 255 อักขระ; UUID หรือ hash ที่แน่นอน (deterministic hash) ปลอดภัยกว่าอ็อบเจกต์ที่ serialized ขนาดใหญ่

ขั้นตอนที่ 4: แทนที่การเก็บข้อมูลในหน่วยความจำก่อนเข้าสู่การผลิต

เมื่อการทดสอบสองคำขอผ่าน ให้ทดสอบการรีสตาร์ทกระบวนการ บันทึกข้อเท็จจริง หยุดแอปพลิเคชัน เริ่มใหม่อีกครั้ง จากนั้นถามหาข้อเท็จจริงนั้นด้วย thread ID เดิม หากคุณยังคงใช้ InMemorySaver การลืมคือพฤติกรรมที่คาดหวัง

เอกสารความจำระยะสั้นอย่างเป็นทางการแสดงการตั้งค่าการผลิตที่ใช้ PostgreSQL ผ่าน PostgresSaver:

from langchain.agents import create_agent
from langgraph.checkpoint.postgres import PostgresSaver

DB_URI = "postgresql://user:password@db-host/app"

with PostgresSaver.from_conn_string(DB_URI) as checkpointer:
    checkpointer.setup()
    agent = create_agent(
        model="your-provider:your-model",
        tools=[],
        checkpointer=checkpointer,
    )

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

ขั้นตอนที่ 5: จัดการประวัติที่ยาวนานแทนที่จะส่งทุกอย่างตลอดไป

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

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

ใช้การสรุปความเมื่อรายละเอียดเก่ายังคงสำคัญ

SummarizationMiddleware เป็นตัวเลือกในตัวปัจจุบันสำหรับแทนที่ประวัติเก่าด้วยสรุปความที่กระชับในขณะที่ยังคงเก็บข้อความล่าสุด ตัวกระตุ้น (trigger) สามารถอิงจากจำนวน token, จำนวนข้อความ หรือสัดส่วนของ context ของโมเดล

from langchain.agents import create_agent
from langchain.agents.middleware import SummarizationMiddleware

agent = create_agent(
    model="your-provider:your-model",
    tools=[],
    checkpointer=checkpointer,
    middleware=[
        SummarizationMiddleware(
            model="your-provider:summary-model",
            trigger=("fraction", 0.8),
            keep=("fraction", 0.3),
        )
    ],
)

ตัวเลขข้างต้นเป็นตัวอย่างนโยบาย ไม่ใช่การตั้งค่าสากล เลือกเกณฑ์หลังจากวัด prompt, ผลลัพธ์จากเครื่องมือ, ขีดจำกัด context ของโมเดล, ความหน่วง และคุณภาพของสรุปความของคุณเอง ดูที่ เอกสาร middleware ในตัวของ LangChain สำหรับตัวเลือก trigger และ keep ที่รองรับในปัจจุบัน

อย่าตัดแต่งข้อความจากเครื่องมืออย่างสุ่มสี่สุ่มห้า

หากคุณใช้การลบหรือตัดแต่งที่กำหนดเอง ให้รักษาลำดับข้อความที่ถูกต้อง LangChain เตือนว่าผู้ให้บริการหลายรายต้องการให้ข้อความ assistant ที่มี tool calls ถูกตามด้วยข้อความผลลัพธ์ของเครื่องมือที่สอดคล้องกัน การลบหนึ่งในครึ่งของคู่นั้นอาจทำให้เกิดข้อผิดพลาดจากผู้ให้บริการหรือพฤติกรรมของโมเดลที่น่าสับสน

ขั้นตอนที่ 6: ย้ายข้อเท็จจริงถาวรไปยัง Store ระยะยาว

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

รายการใน store ระยะยาวคือเอกสาร JSON ที่จัดเรียงโดย namespace และ key namespace ที่ใช้งานจริงมักมีตัวระบุผู้ใช้หรือองค์กร:

namespace = ("users", user_id, "preferences")
store.put(
    namespace,
    "response_style",
    {"value": "concise", "source": "explicit_user_request"},
)

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

ใช้ store ที่เชื่อมต่อกับฐานข้อมูลในการผลิต

คู่มือความจำระยะยาวอย่างเป็นทางการแสดงทั้ง InMemoryStore และ PostgresStore และระบุอย่างชัดเจนว่าควรแทนที่การดำเนินการในหน่วยความจำด้วย store ที่เชื่อมต่อกับฐานข้อมูลสำหรับการผลิต นอกจากนี้ยังระบุการเชื่อมต่อ store นอกเหนือจาก PostgreSQL ให้ใช้ backend ที่เหมาะสมกับการใช้งานและข้อกำหนดในการดำเนินงานของคุณ แทนที่จะเลือกฐานข้อมูลเวกเตอร์เพียงเพราะมีคำว่า “memory” เข้ามาเกี่ยวข้อง

เพิ่มการค้นหาเชิงความหมายเมื่อคุณต้องการการเรียกคืนแบบคลุมเครือ

LangGraph stores สามารถกำหนดค่าด้วยดัชนีเพื่อให้ store.search() สามารถดึงรายการตามความคล้ายคลึงเชิงความหมาย สิ่งนี้มีประโยชน์เมื่อคุณมีความจำจำนวนมากและไม่ทราบคีย์ที่แน่นอน สำหรับความชอบที่มีโครงสร้างจำนวนน้อย การค้นหาโดยตรงผ่าน namespace/key มักจะง่ายและแน่นอนกว่า

ขั้นตอนที่ 7: ทำให้เส้นทางอ่านและเขียนความจำชัดเจน

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

from dataclasses import dataclass
from langchain.tools import tool, ToolRuntime

@dataclass
class Context:
    user_id: str

@tool
def get_response_style(runtime: ToolRuntime[Context]) -> str:
    store = runtime.store
    if store is None:
        return "No memory store configured"

    namespace = ("users", runtime.context.user_id, "preferences")
    item = store.get(namespace, "response_style")
    return item.value["value"] if item else "default"

คุณยังสามารถสร้าง prompt แบบไดนามิกหรือ middleware ที่อ่านสถานะและความจำถาวรก่อนการเรียกโมเดล กฎการออกแบบที่สำคัญคือเส้นทางสำหรับการดึงข้อมูลควรสังเกตได้และทดสอบได้ “ข้อมูลมีอยู่ที่ไหนสักแห่งในฐานข้อมูล” ไม่เพียงพอ

ขั้นตอนที่ 8: ทดสอบขอบเขตความจำสี่ประการแยกกัน

ชุดทดสอบความจำที่เชื่อถือได้ควรครอบคลุมมากกว่า “โมเดลจำชื่อของฉันได้หนึ่งครั้ง” ใช้กรณีอย่างน้อยสี่กรณีเหล่านี้:

จากนั้นเพิ่มการทดสอบการสนทนายาวที่เกินเกณฑ์การสรุปความของคุณ ยืนยันว่าข้อเท็จจริงถาวรที่สำคัญยังคงอยู่, ลำดับการเรียกเครื่องมือล่าสุดยังคงถูกต้อง และขนาด prompt อยู่ภายในงบประมาณ context ที่คุณตั้งเป้าไว้

สถาปัตยกรรมการผลิตขั้นต่ำ

สำหรับแอปพลิเคชัน agent หลายตัว การออกแบบที่แข็งแกร่งมีลักษณะดังนี้:

1. API รับ user_id, conversation_id และข้อความใหม่ของผู้ใช้
2. แอปพลิเคชันแมป conversation_id ไปยัง LangGraph thread_id ที่เสถียร
3. Checkpointer ถาวรเรียกคืนสถานะของเธรด
4. Store ระยะยาวดึงเฉพาะข้อเท็จจริงถาวรของผู้ใช้หรือแอปพลิเคชันที่จำเป็นสำหรับคำขอ
5. การสรุปความหรือการตัดแต่งรักษาประวัติที่ส่งให้โมเดลให้อยู่ในงบประมาณ context ที่วัดได้
6. Agent รันเครื่องมือและโมเดล
7. Checkpointer บันทึกสถานะเธรดที่อัปเดต
8. เฉพาะข้อเท็จจริงที่อนุมัติแล้วเท่านั้นที่ถูกเขียนไปยัง store ระยะยาว

หากคุณใช้งานผ่าน LangGraph Agent Server คู่มือการคงอยู่ปัจจุบันระบุว่าเซิร์ฟเวอร์จัดการโครงสร้างพื้นฐานการคงอยู่โดยอัตโนมัติ ดังนั้นอย่าทำซ้ำชั้นนั้นโดยไม่ตรวจสอบโมเดลการใช้งาน

ข้อผิดพลาดทั่วไปที่ทำให้ความจำดูเหมือนเสียหาย

การสร้าง thread_id ใหม่สำหรับทุกคำขอ

สิ่งนี้สร้างสถานะการสนทนาใหม่ในทุกการสนทนา บันทึก thread ID ข้างๆ chat ID ของแอปพลิเคชันของคุณและตรวจสอบการใช้ซ้ำ

การใช้ InMemorySaver ในบริการที่มีหลาย worker หรือรีสตาร์ทได้

สถานะเฉพาะ RAM จะหายไปพร้อมกับกระบวนการและอาจไม่ถูกแชร์ข้าม worker ใช้ backend ถาวรสำหรับความต่อเนื่องในการผลิต

สมมติว่า checkpointer แก้ปัญหา context-window ได้

Checkpointer รักษาสถานะ; มันไม่รับประกันว่าบทสนทนาที่เติบโตขึ้นเรื่อยๆ จะมีประโยชน์ต่อโมเดล เพิ่มนโยบายการจัดการ context ที่ชัดเจน

ใส่ข้อเท็จจริงในอดีตทั้งหมดลงใน prompt

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

ปฏิบัติต่อสรุปความเหมือนเป็นฐานข้อมูลที่สมบูรณ์แบบ

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

ผสมขอบเขตระยะสั้นและระยะยาว

ประวัติเธรดไม่ควรกลายเป็นโปรไฟล์ผู้ใช้ทั่วโลกโดยเงียบๆ ในทางกลับกัน ความชอบของผู้ใช้ที่ตั้งใจให้ติดตามผู้ใช้ข้ามแชทไม่ควรอยู่ในเธรดเดียวเท่านั้น

คัดลอกบทเรียนความจำก่อน v1 โดยไม่ตรวจสอบ imports

หากตัวอย่างเริ่มจาก chains เก่าหรือคลาสความจำเก่า ให้เปรียบเทียบกับคู่มือการย้ายระบบ v1 และเอกสารความจำปัจจุบันก่อนใช้ในแอปพลิเคชันใหม่

รายการตรวจสอบสำหรับการดีบัก

• ยืนยันว่า agent ถูกสร้างขึ้นด้วย checkpointer
• บันทึกและเปรียบเทียบ thread_id ข้ามคำขอต่อเนื่อง
• ตรวจสอบสถานะเธรดที่เก็บไว้ก่อนจะโทษโมเดล
• รีสตาร์ทกระบวนการและทำซ้ำการทดสอบเธรดเดียวกัน
• แทนที่ InMemorySaver ด้วย checkpointer ถาวรสำหรับการผลิต
• วัดการเติบโตของข้อความ/token ในการแชทที่ยาว
• เปิดใช้งานการสรุปความหรือการตัดแต่งก่อนที่ประวัติจะมากเกินไป
• รักษาความถูกต้องของลำดับ tool-call/result เมื่อลบข้อความ
• ย้ายข้อเท็จจริงข้ามเธรดไปยัง store ระยะยาวที่มี namespace
• ทดสอบเธรดใหม่สำหรับผู้ใช้เดียวกันเพื่อยืนยันการเรียกคืนระยะยาวที่ตั้งใจ
• ทดสอบผู้ใช้ที่แตกต่างกันเพื่อยืนยันการแยกความจำ
• ติดตามว่ารายการความจำใดถูกดึงมาสำหรับแต่ละคำตอบ

บทสรุป

ปัญหาลืมความจำของ LangChain agent แทบไม่เคยแก้ไขได้ด้วย context window ที่ใหญ่ขึ้นเพียงอย่างเดียว ก่อนอื่นทำให้สถานะเธรดคงอยู่ด้วย checkpointer และ thread_id ที่เสถียร จากนั้นควบคุมประวัติที่ยาวด้วยการตัดแต่งหรือ SummarizationMiddleware สุดท้าย วางข้อเท็จจริงที่ต้องคงอยู่ข้ามการสนทนาไว้ใน store ระยะยาวที่มี namespace และดึงมันออกมาอย่างจงใจ

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