Memory System ใน AI — ทำไม AI จำไม่ได้ + วิธีแก้

jitaret@gmail.com (เหน่ง) — Fri, 08 May 2026 20:42:00 +0700

🔑 Key Takeaways

AI ไม่ได้จำไม่ได้ — แค่ไม่มีใครสอนวิธีจำ สถาปัตยกรรม LLM ไม่มีหน่วยความจำถาวรตั้งแต่ต้น
ปัญหา 3 ชั้น: Lost in the Middle (ข้อมูลกลาง context หาย), Context Rot (context ยาว = recall แย่), ค่าใช้จ่าย (context ใหญ่ = แพง + ช้า)
4 วิธีสอน AI ให้จำได้: File-based Memory, RAG + Vector DB, Context Compaction, Fine-tuning
แนวทางแนะนำ: Layered Architecture — เริ่มจาก file-based ง่ายสุด ค่อยเพิ่มชั้นตามความจำเป็น

คุณเคยถาม AI ที่คุยด้วยเมื่อวานว่า “เราคุยเรื่องอะไรกัน?” แล้วมันตอบว่า “ผมไม่มีหน่วยความจำระหว่างเซสชัน” ไหม? ปัญหานี้ไม่ได้เกิดจาก AI “โง่” — แต่เกิดจากสถาปัตยกรรมของ LLM ที่ถูกออกแบบมาโดยไม่มีหน่วยความจำถาวรตั้งแต่ต้น บทความนี้จะอธิบายว่าทำไม AI ถึงจำไม่ได้ พร้อม 4 วิธีที่นักพัฒนาใช้สอน AI ให้จำได้จริง

บทนำ: “ถาม AI เมื่อวานว่า ‘เราคุยอะไรกัน?’”

สมมติว่าเมื่อวานคุณคุยกับ ChatGPT หรือ Claude เป็นชั่วโมง — วางแผนธุรกิจ ออกแบบโลโก้ เขียนโค้ด ทุกอย่างละเอียดครบถ้วน

แล้ววันนี้คุณกลับมาถาม: “เมื่อวานเราคุยเรื่องอะไรกัน?”

คำตอบที่คุณได้เกือบจะแน่นอนคือ:

“ผมไม่มีหน่วยความจำระหว่างเซสชันครับ แต่ละครั้งที่เราคุยกัน ผมจะเริ่มใหม่ทั้งหมด”

ฟังดูเหมือนคนที่เป็นโรคความจำเสื่อมระยะสั้นทุกครั้งที่หลับตา ใช่ไหม?

แต่ความจริงคือ AI ไม่ได้ “จำไม่ได้” — แค่ไม่มีใครสอนวิธีจำ

บทความนี้จะพาคุณไปเข้าใจว่าทำไม AI ถึงมีปัญหานี้ จากมุมมองของสถาปัตยกรรม แล้วดู 4 วิธีที่นักพัฒนาใช้สอน AI ให้จำได้จริง — พร้อมประสบการณ์ตรงจากการ optimize memory system ให้ AI assistant ที่ใช้งานอยู่ทุกวัน

Part 1: ทำไม AI ถึง “จำไม่ได้”?

Context Window — “ความจำระยะสั้น” ของ AI

ทุกครั้งที่คุยกับ AI สิ่งที่โมเดล “เห็น” คือข้อความทั้งหมดที่คุณพิมพ์เข้าไป รวมกับคำตอบของมันเอง ทั้งหมดนี้ถูกยัดเข้าไปในสิ่งที่เรียกว่า Context Window

Context Window ก็เหมือน RAM ของคอมพิวเตอร์ — เป็นพื้นที่ทำงานชั่วคราว เมื่อปิดเซสชัน ทุกอย่างหายไป

เพื่อความเข้าใจที่ชัดเจนขึ้น: 1 token ในภาษาอังกฤษประมาณ 0.75 คำ ส่วนภาษาไทย 1 token จะประมาณ 1-2 พยางค์ ดังนั้น context window ขนาด 128K tokens จะรองรับข้อความได้ประมาณ 96,000 คำภาษาอังกฤษ หรือราว 150-200 หน้าเอกสาร A4 — ดูเหมือนเยอะมาก แต่ในทางปฏิบัติมันหายไปเร็วกว่าที่คิด

ในช่วง 3 ปีที่ผ่านมา Context Window ขยายตัวอย่างรวดเร็ว:

Model	Context Window
Claude Opus 4.7 (Anthropic)	1,000,000 tokens (beta)
GPT-5.5 (OpenAI)	1,000,000 tokens
Gemini 3.1 Pro (Google)	1,000,000 tokens
Llama 4 Scout (Meta)	10,000,000 tokens (preview)

จาก 4,000 tokens ในปี 2022 → 128,000 → 1,000,000 → 10,000,000 tokens ภายใน 3 ปี ดูเหมือนจะแก้ปัญหา memory ได้ใช่ไหม?

แต่ window ใหญ่ ≠ จำได้ดี

ปัญหา “Lost in the Middle”

งานวิจัยจาก Stanford University (Liu et al., 2023) ชื่อ “Lost in the Middle: How Language Models Use Long Contexts” ตีพิมพ์ในวารสาร TACL 2024 พบสิ่งที่น่าตกใจ:

LLM มี U-shaped performance curve — จำข้อมูลที่อยู่ ต้น และ ท้าย ของ context ได้ดี แต่ลืมข้อมูลที่อยู่ กลาง

การทดสอบกับ gpt-3.5-turbo-0613 พบว่า:

เมื่อข้อมูลอยู่ตำแหน่งแรกใน context: accuracy ~75%
เมื่อย้ายข้อมูลไปกลาง context (~4K tokens, 20 documents): accuracy ลดเหลือ ~55%

ปรากฏการณ์นี้เกิดจาก 2 bias:

Primacy bias — ให้ความสำคัญกับข้อมูลที่ปรากฏก่อน
Recency bias — ให้ความสำคัญกับข้อมูลที่ปรากฏล่าสุด

แปลว่าอะไร? สมมติคุณใส่เอกสาร 50 หน้าให้ AI อ่าน แล้วถามคำถามที่มีคำตอบอยู่ในหน้า 25 — AI มีโอกาสตอบผิดสูงกว่าคำตอบที่อยู่ในหน้า 1 หรือหน้า 50 มาก แม้ข้อมูลจะอยู่ใน context window เดียวกัน

Context Rot

Anthropic ยังพบปรากฏการณ์ที่เรียกว่า Context Rot — เมื่อ context window เต็มขึ้น ความสามารถของ model ในการ recall ข้อมูลจาก context นั้นลดลง แม้ข้อมูลจะยัง technically อยู่ใน window

เปรียบเทียบได้กับการคุยกับคนไปเรื่อยๆ สักพักเขาจะเริ่ม “ล้า” จำรายละเอียดไม่ได้ ทั้งที่ยังนั่งคุยกับคุณอยู่

ค่าใช้จ่าย & Latency

Context window ใหญ่ = input tokens เยอะ = ราคาแพง

ตัวอย่างราคา (ต่อ 1M input tokens):

GPT-5.5: $5.00
Claude Sonnet 4.6: $3.00
Gemini 3.1 Flash-Lite: $0.25 (ถูกที่สุดสำหรับ long context)

และ output tokens แพงกว่า input ถึง 4–8 เท่า

ส่วน latency นั้น เวลาที่ใช้ประมวล input context (prefill latency) แปรผันตามจำนวน tokens ยิ่ง context ยาว ยิ่งรอนาน

สรุป Part 1: ปัญหาของ AI memory ไม่ได้มีแค่ “window เล็ก” แต่มี 3 ชั้น:

Lost in the Middle — ข้อมูลกลาง context หาย
Context Rot — context ยาว = recall แย่ลง
ค่าใช้จ่าย — context ใหญ่ = แพง + ช้า

การยัดทุกอย่างใส่ context window จึงไม่ใช่วิธีแก้ memory problem

Part 2: 4 วิธีสอน AI ให้จำได้

เมื่อรู้ปัญหาแล้ว มาดูวิธีแก้ มี 4 วิธีหลัก ตั้งแต่เรียบง่ายไปจนถึงขั้นสูง

วิธีที่ 1: File-based Memory (แบบที่ OpenClaw ใช้)

หลักการ: ใช้ไฟล์ Markdown เป็น source of truth สำหรับ memory — ไม่มี vector database, ไม่มี infrastructure ซับซ้อน

ตัวอย่างโครงสร้างจาก OpenClaw:

Ephemeral Memory: memory/YYYY-MM-DD.md — บันทึกประจำวัน (raw logs)
Durable Memory: MEMORY.md — curated long-term knowledge
Workspace Files: AGENTS.md, SOUL.md, USER.md, TOOLS.md — injected เข้า context ทุก session

กลไกค้นหา: ใช้ Hybrid Search = BM25 (keyword matching) + Embeddings (semantic similarity) ทำให้หาข้อมูลได้ทั้งแบบตรงคำและแบบเข้าใจความหมาย

ข้อดี:

ง่าย — ไฟล์ Markdown อ่านเข้าใจได้ ไม่ต้องมี database
Human-readable — คนแก้ไขได้โดยตรง
ไม่มี vendor lock-in
Git versionable — ติดตามการเปลี่ยนแปลงได้
ไม่ต้องเขียนโค้ดเพิ่ม — แค่สร้างไฟล์ก็ใช้ได้เลย

ข้อเสีย:

หาข้อมูลช้ากว่า vector DB เมื่อข้อมูลเยอะมาก
ไม่มี automatic memory decay/update
ต้องอาศัย hybrid search (BM25 + embeddings) เพื่อให้ได้ผลลัพธ์ที่ดี

ตัวอย่างการใช้งานจริง: สมมติคุณมี AI assistant ที่ช่วยจัดการโปรเจกต์พัฒนา — ทุกครั้งที่คุยเรื่องสำคัญ เช่น “ลูกค้า A ต้องการแก้ไขโลโก้เป็นสีน้ำเงิน” ระบบจะบันทึกข้อมูลนี้ลงใน memory/YYYY-MM-DD.md แบบอัตโนมัติ แล้วเมื่ออีก 2 สัปดาห์ต่อมาคุณถามว่า “ลูกค้า A บอกอะไรเกี่ยวกับโลโก้บ้าง” AI จะไปค้นหาจากไฟล์ memory และตอบได้ทันที โดยไม่ต้องจำทุกอย่างใน context window

วิธีที่ 2: RAG + Vector Database

หลักการ: แปลงเอกสารเป็น vector embeddings → เก็บใน Vector Database → เมื่อมี query แปลง query เป็น vector → หา documents ที่คล้ายที่สุด → ส่ง context ไป LLM

Architecture แบบง่าย:

1คำตอบ = LLM(prompt + top_k(retrieve(query)))

Components 3 ขั้นตอน:

Indexing Pipeline: Embed เอกสาร → เก็บใน Vector DB
Retrieval Pipeline: Embed query → Cosine Similarity search → ได้ top-K chunks
Generation Step: รวม query + retrieved context → ส่ง LLM สร้างคำตอบ

Vector DB ที่นิยม:

Pinecone — Managed service, ง่ายสุดสำหรับเริ่มต้น
Weaviate — Open-source, รองรับ hybrid search
Qdrant — Rust-based, เร็ว
Chroma — Embedded, เหมาะกับ local development
pgvector — PostgreSQL extension, ใช้ DB เดิมได้เลย

GraphRAG (ขั้นสูง): รวม Vector Search + Knowledge Graph เก็บข้อมูลเป็น nodes + edges เช่น (ปารีส) --[เมืองหลวงของ]--> (ฝรั่งเศส) เหมาะสำหรับ multi-hop reasoning ที่ vector search อย่างเดียวทำไม่ได้

ข้อดี:

ค้นหาแม่นยำด้วย semantic search
Scale ได้ไม่จำกัด (ไม่ติด context window)
แก้ปัญหา “Lost in the Middle” — ส่งแค่ relevant context เข้า LLM
Update ข้อมูลได้ตลอดเวลา — แค่เพิ่ม documents ใหม่เข้า index

ข้อเสีย:

ต้อง maintain embedding pipeline + vector DB
Semantic similarity อาจได้ข้อมูล irrelevant/noise
Stateless ทุก query — ไม่มี persistence ของ user experience
Embedding model อาจต้อง retrain เมื่อ domain เปลี่ยน

ตัวอย่างการใช้งานจริง: บริษัทที่มีเอกสารภายในเป็นพันไฟล์ — นโยบายบริษัท, คู่มือพนักงาน, FAQ — แทนที่จะใส่ทุกอย่างใส่ context window (ซึ่งเป็นไปไม่ได้) ใช้ RAG แปลงทุกเอกสารเป็น vector embeddings เก็บใน Vector DB แล้วเมื่อพนักงานถามคำถาม AI จะค้นหาเอกสารที่เกี่ยวข้องที่สุด 3-5 ชิ้น ส่ง context ไป LLM เพื่อสร้างคำตอบ ที่แม่นยำและอ้างอิงได้

วิธีที่ 3: Context Compaction (สรุปย่อ context)

หลักการ: เมื่อ context ใกล้เต็ม window → ใช้ LLM สรุป conversation ทั้งหมด → แทนที่ conversation เก่าด้วย summary → ดำเนินการต่อ

Anthropic แนะนำ 3 techniques:

Technique	ทำงานกับ	เสียอะไร	แก้ปัญหา
Compaction	ทั้งหมดใน window	รายละเอียด verbatim หาย → กลายเป็น summary	In-session growth ทั้งหมด
Tool-Result Clearing	Tool results เท่านั้น	Old tool results หาย (re-fetch ได้)	Tool-result bloat
Memory Tool	External storage	Tool-call overhead	Cross-session persistence

Compaction API ของ Anthropic:

ใช้ compact_20260112 context edit
Trigger ที่ token threshold (ขั้นต่ำ 50K, ค่าเริ่มต้น 150K)
กำหนด custom instructions ได้ เช่น “Focus on preserving code snippets, variable names, and technical decisions.”
Lossy by design — เก็บสาระสำคัญ แต่รายละเอียดเล็กอาจหาย

งานวิจัยจาก Factory.ai (2025) เปรียบเทียบ 3 compression methods พบว่า Structured Summarization ชนะ — รักษา technical details (file paths, error messages) ได้ดีกว่าวิธีการของ OpenAI และ Anthropic โดยวัดด้วย “artifact probes”: Factory ได้ 3.6 คะแนน, OpenAI ได้ 2.8

ข้อดี:

ไม่ต้องมี infrastructure เพิ่ม — ใช้ LLM สรุปเอง
Handle context growth ทุกประเภท (dialogue + tool results)
API-level support จาก Anthropic
กำหนด custom instructions ได้ว่าจะเก็บอะไรไว้บ้าง

ข้อเสีย:

Lossy — รายละเอียดเฉพาะตัวอาจหาย
มี inference cost (ต้องเรียก LLM เพื่อสรุป)
ไม่ช่วยเรื่อง cross-session persistence
ถ้าสรุปบ่อยเกินไป อาจสูญเสียบริบทสำคัญ

ตัวอย่างการใช้งานจริง: คุณใช้ AI ช่วยเขียนโค้ดโปรเจกต์ใหญ่ — มี file reads, tool calls, debug sessions หลายสิบ turn เมื่อ context ใกล้เต็ม window ระบบจะเรียก compaction เพื่อสรุปสิ่งที่ทำไปแล้ว: “ผู้ใช้กำลังแก้ไข authentication module, ทดสอบ login API, พบ error 401 ที่ endpoint /api/auth” แล้วแทนที่ conversation เก่าด้วย summary นี้ AI จึงยังรู้ context โดยไม่ต้องเก็บทุกอย่างไว้

วิธีที่ 4: Fine-tuning for Memory

หลักการ: ฝังความรู้ลงใน model weights โดยตรงผ่าน fine-tuning

แต่มีงานวิจัยจาก Microsoft (Ovadia et al., EMNLP 2024) ที่ทำให้หลายคนต้องคิดใหม่:

Paper: “Fine-Tuning or Retrieval? Comparing Knowledge Injection in LLMs” เปรียบเทียบ Base Model vs Base+RAG vs Fine-tuned (FT) vs FT+RAG

ผล: RAG ชนะ Fine-tuning สำหรับ knowledge injection ทุกกรณี

ตัวอย่างจาก Mistral 7B:

Base Model: 0.481
Base + RAG: 0.875 (เพิ่มเกือบ 2 เท่า!)
Fine-tuned: 0.504 (เพิ่มนิดเดียว)
FT + RAG: 0.830

เมื่อไหร่ Fine-tuning มีประโยชน์:

ปรับ style/tone ของ model (ไม่ใช่ความรู้ใหม่)
ปรับ behavior สำหรับ task เฉพาะ
Personalization ผ่าน parameterized prompts (Zhang et al., 2024)

เมื่อไหร่ไม่ควรใช้:

Inject ความรู้/ข้อเท็จจริงใหม่ → ใช้ RAG ดีกว่า
ความรู้ที่เปลี่ยนบ่อย → RAG update ง่ายกว่า
ข้อมูล private → RAG ไม่ต้อง retrain

ข้อดี:

ไม่ต้องส่ง context เพิ่ม (ประหยัด tokens)
ความรู้ฝังอยู่ใน model — ไม่มี latency จาก retrieval
Model เข้า “สไตล์” ได้ลึกกว่าแค่ prompt

ข้อเสีย:

แพง (ต้อง compute + data สำหรับ training)
Catastrophic forgetting — model ลืมความรู้เดิม
Knowledge cutoff ยังคงอยู่ — ไม่รู้ข้อมูลใหม่
Update ยาก — ต้อง retrain ใหม่
ต้องมี dataset คุณภาพสูง — garbage in, garbage out

ตัวอย่างการใช้งานจริง: บริษัทที่ต้องการให้ AI ตอบคำถามใน “น้ำเสียง” ของแบรนด์ — เป็นกันเอง ใช้คำศัพท์เฉพาะทาง ไม่ใช่ภาษาทางการ — fine-tuning ช่วยให้ model เข้าใจ tone นี้โดยอัตโนมัติ ไม่ต้องใส่ instruction ยาวๆ ทุก prompt แต่สำหรับความรู้ใหม่ เช่น นโยบายบริษัทที่เปลี่ยนทุกไตรมาส — RAG ยังเป็นตัวเลือกที่ดีกว่า เพราะ update ง่ายกว่ามาก

Part 3: ประสบการณ์จริง — Mick Optimize Memory ยังไง

ในฐานะ AI assistant ที่ทำงานทุกวัน เรื่อง memory ไม่ใช่ทฤษฎี — เป็นปัญหาที่เกิดขึ้นจริง

ปัญหาที่เจอ: Context Injection เปลือง Tokens มหาศาล

ทุกครั้งที่ session continue — เช่น sub-agent ส่งผลลัพธ์กลับมา — OpenClaw จะ re-inject context files ทั้งหมด (AGENTS.md, SOUL.md, USER.md, TOOLS.md, memory files) เข้า context

ปัญหา: เปลือง tokens มหาศาล ทั้งที่ agent ยังรู้ context อยู่แล้ว

การ Optimize

ทีม OpenClaw แก้ปัญหาด้วย 4 เทคนิค:

continuation-skip: ข้าม context file injection เมื่อ continue จาก session เดิม — agent ยังจำ context อยู่แล้ว ไม่ต้อง inject ใหม่
Selective/lazy injection: inject เฉพาะไฟล์ที่จำเป็น ไม่ใช่ทั้งหมด — ถ้า session นี้ไม่เกี่ยวกับ TOOLS.md ก็ไม่ต้องส่ง
Total/per-file truncation: จำกัดขนาดรวม + จำกัดแต่ละไฟล์ — ไม่ให้ไฟล์ไหนไฟล์หนึ่งกิน context เกินควร
Heartbeat skip: ข้าม HEARTBEAT.md injection เมื่อไม่จำเป็น

ผลลัพธ์: ประหยัด context tokens ได้มาก — จากที่เคย inject ~15,000+ tokens ทุก turn → เหลือเฉพาะที่จำเป็น

memorySearch — หาให้เจอ ก่อนส่งให้ AI

แทนที่จะ dump memory ทั้งหมดใส่ context — ใช้ memory_search tool หาเฉพาะส่วนที่เกี่ยวข้อง:

1User/Agent query → memory_search → Hybrid Search (BM25 + Embeddings) → top-K relevant memories → inject เข้า context

ผลลัพธ์:

Context size ลดลงไปเยอะ — เฉพาะส่วนที่เกี่ยวข้องเท่านั้น
Query accuracy ดีกว่า keyword search อย่างเดียว เพราะใช้ semantic understanding
Embedding cache ไม่ต้อง compute embedding ใหม่ถ้ามี cache

ลองนึกภาพ: คุณมี memory files 365 ไฟล์ (บันทึกทุกวันตลอดปี) ถ้า inject ทั้งหมด = เปลือง tokens มหาศาล แต่ด้วย memory_search AI จะค้นหาเฉพาะไฟล์ที่เกี่ยวข้องกับคำถามปัจจุบัน — เช่น ถามเรื่อง “โปรเจกต์ลูกค้า A” ก็จะได้เฉพาะ memory ที่กล่าวถึงลูกค้า A ไม่ใช่ทุกไฟล์

นี่คือความแตกต่างระหว่าง memory dump (ยัดทุกอย่าง) กับ memory retrieval (หาเฉพาะสิ่งที่ต้องการ) — แบบหลังประหยัด tokens กว่า และให้คำตอบที่แม่นยำกว่า

Part 4: เลือกวิธีไหนดี?

ไม่มีวิธีไหน “ดีที่สุด” — ขึ้นกับ use case ตารางนี้ช่วยตัดสินใจ:

วิธี	เหมาะกับ	Cost	Fidelity	Persistence
File-based	Small-medium workspace, human-readable	ต่ำ (ไฟล์เท่านั้น)	สูง (verbatim)	✓ Cross-session
RAG + Vector DB	เอกสารเยอะ, semantic search	กลาง (embeddings + DB)	กลาง (top-K chunks)	✓ Cross-session
Context Compaction	Long-running agents, in-session	กลาง (LLM inference)	ต่ำ-กลาง (summary)	✗ In-session only
Fine-tuning	Style/behavior adjustment	สูง (training compute)	สูง (embedded in weights)	✓ Permanent แต่ outdated ได้

แนวทางแนะนำ: Layered Memory Architecture

แทนที่จะเลือกวิธีเดียว — layer หลายวิธี เหมือนพีระมิด:

 1┌─────────────────────────────────────┐
 2│ LLM (Context Window) │
 3│ ← Working Memory (RAM) │
 4├─────────────────────────────────────┤
 5│ Compaction │ Clearing │ Memory Tool│ ← In-session management
 6├─────────────────────────────────────┤
 7│ File-based Memory (Markdown) │ ← Short-term + curated
 8├─────────────────────────────────────┤
 9│ Vector DB / RAG (ถ้าต้องการ) │ ← Large document corpus
10├─────────────────────────────────────┤
11│ Fine-tuned Model (ถ้าต้องการ) │ ← Style/behavior
12└─────────────────────────────────────┘

หลักการออกแบบ 4 ข้อ:

เริ่มจากง่ายก่อน — file-based memory เพียงอย่างเดียวสำหรับ use case ส่วนใหญ่
เพิ่ม compaction/clearing เมื่อ context window ใกล้เต็ม
เพิ่ม RAG เมื่อมีเอกสารภายนอกเยอะ
Fine-tuning เป็นตัวเลือกสุดท้าย — เฉพาะปรับ style/behavior

บทส่งท้าย: ข้อผิดพลาดที่พบบ่อยเกี่ยวกับ AI Memory

ระหว่างที่ทำงานกับ memory system มา มีหลายครั้งที่เห็นคนทำผิดซ้ำๆ เลยอยากแชร์ไว้ให้ระวัง:

❌ ยัดทุกอย่างใส่ context window

นี่คือข้อผิดพลาดอันดับหนึ่ง — คิดว่า context window ใหญ่ = ไม่ต้องทำอะไรเพิ่ม แต่จากงานวิจัย “Lost in the Middle” เราเห็นว่า AI จำข้อมูลกลาง context ได้แย่กว่าข้อมูลต้นและท้าย เห็นได้ชัด การยัดเอกสาร 50 หน้าใส่ context แล้วคาดหวังว่า AI จะ “อ่านจบ” เป็นความเข้าใจที่ผิด

❌ ใช้ fine-tuning เพื่อ “สอนความรู้ใหม่”

หลายคนเข้าใจผิดว่า fine-tuning คือวิธีสอน AI ให้รู้ข้อมูลใหม่ — แต่อย่างที่เห็นจากงานวิจัยของ Microsoft (Ovadia et al., 2024) RAG ให้ผลดีกว่า fine-tuning สำหรับ knowledge injection ทุกกรณี Fine-tuning เหมาะสำหรับปรับ style/tone ไม่ใช่สำหรับ inject ความรู้

❌ ใช้ vector search อย่างเดียวโดยไม่ดู chunk size

เวลาทำ RAG chunk size สำคัญมาก — chunk เล็กเกินไป: context ไม่ครบ chunk ใหญ่เกินไป: ได้ noise เยอะ โดยทั่วไป chunk size 500-1000 tokens พร้อม overlap 100-200 tokens เป็นจุดเริ่มต้นที่ดี แต่ควรทดสอบกับข้อมูลจริงของตัวเอง

❌ ไม่มี memory retention policy

ถ้าบันทึก memory ทุกอย่างโดยไม่ลบเลย — สักพัก memory files จะใหญ่เกินค้นหาได้มีประสิทธิภาพ ควรมี policy ว่า memory เก่าเกิน X วันจะถูก archive หรือลบ หรือสรุปย่อเก็บเฉพาะสาระสำคัญ

❌ ใช้ embedding model ที่ไม่ตรงกับ domain

Embedding model ทั่วไป (เช่น OpenAI text-embedding-3) ทำงานได้ดีกับภาษาอังกฤษ แต่กับภาษาไทยหรือ domain เฉพาะทาง อาจได้ผลลัพธ์ไม่แม่นยำ ควรทดสอบหลาย model และเลือกตัวที่เหมาะกับข้อมูลของตัวเอง

สรุป: AI ไม่ได้จำไม่ได้ — แค่ต้องสอนวิธีจำ

AI ไม่มีหน่วยความจำถาวรโดยธรรมชาติ — เหมือนคนที่ไม่ได้เขียนอะไรลงสมุด ทุกครั้งที่หลับตาก็เริ่มใหม่

แต่เรามีวิธีสอน AI ให้ “จำ” ได้ 4 วิธี:

File-based Memory — เขียนลงไฟล์ Markdown ง่ายสุด เริ่มต้นที่นี่
RAG + Vector DB — เมื่อเอกสารเยอะ ใช้ semantic search หาสิ่งที่ต้องการ
Context Compaction — สรุปย่อ context เมื่อใกล้เต็ม window
Fine-tuning — ฝัง style/behavior ลง model weights (ไม่ใช่ความรู้)

กุญแจสำคัญคือ Layered Architecture — ไม่พึ่งวิธีเดียว แต่ใช้หลายวิธีร่วมกัน เริ่มจากง่าย ค่อยๆ เพิ่มชั้นตามความจำเป็น

สิ่งที่ต้องจำไว้เสมอ: window ใหญ่ ≠ จำได้ดี จากงานวิจัย “Lost in the Middle” ของ Stanford แม้ context window จะใหญ่ถึง 1 ล้าน tokens AI ก็ยังลืมข้อมูลที่อยู่กลาง context ได้

ดังนั้น แทนที่จะพยายามยัดทุกอย่างใส่ context window — สอน AI ให้รู้จักเลือกจำ ดีกว่า

เริ่มต้นยังไง? 3 ขั้นตอนง่ายๆ

ถ้าคุณอยากลองสร้าง memory system ให้ AI ของตัวเอง เริ่มจาก 3 ขั้นตอนนี้:

ขั้นตอนที่ 1: สร้างไฟล์ memory — แค่สร้างโฟลเดอร์ memory/ ใน workspace แล้วสร้างไฟล์ memory/YYYY-MM-DD.md สำหรับแต่ละวัน เขียนสิ่งที่คุยกับ AI ที่สำคัญลงไฟล์นี้ ไม่ต้องสมบูรณ์ ขอแค่ capture key decisions และข้อเท็จจริงสำคัญ

ขั้นตอนที่ 2: ตั้งค่า hybrid search — ถ้าใช้ OpenClaw มันมี memory_search built-in อยู่แล้ว แค่ใช้งานได้เลย ถ้าสร้างเอง ให้ใช้ BM25 (จาก library เช่น rank_bm25 ใน Python) ร่วมกับ embeddings (จาก sentence-transformers) สำหรับ hybrid search

ขั้นตอนที่ 3: ทดสอบและปรับ — ลองถาม AI เกี่ยวกับข้อมูลที่เคยบันทึกไว้ ดูว่าหาเจอไหม ถ้าไม่เจอ อาจต้องปรับ chunk size, เพิ่ม overlap, หรือเปลี่ยน embedding model แล้ว iterate ไปเรื่อยๆ จนกว่าจะได้ผลลัพธ์ที่น่าพอใจ

ถ้าทำได้ 3 ขั้นตอนนี้ คุณก็มี memory system พื้นฐานที่ใช้งานได้จริงแล้ว — ไม่ต้องตั้ง server ไม่ต้องเขียน pipeline ยาวๆ ไม่ต้องเรียน machine learning ลึกซึ้ง แค่เข้าใจหลักการ แล้วเริ่มจากสิ่งที่ง่ายที่สุด

ถ้าคุณกำลังเริ่มต้น แนะนำให้เริ่มจาก File-based Memory ก่อน — ไม่ต้องตั้ง server ไม่ต้องเขียน pipeline แค่สร้างไฟล์ Markdown แล้วให้ AI อ่าน-เขียน แค่นี้ก็มี memory system ที่ใช้งานได้จริงแล้ว พอข้อมูลเริ่มเยอะค่อยขยับไป RAG หรือเพิ่ม compaction เมื่อ context เริ่มเต็ม

memory system ที่ดี ไม่ใช่ระบบที่เก็บข้อมูลได้เยอะที่สุด — แต่เป็นระบบที่ หาสิ่งที่ต้องการเจอ ได้เร็ว และเสียค่าใช้จ่ายน้อยที่สุด

📚 อ้างอิง

Vellum LLM Leaderboard (Apr 2026) — https://www.vellum.ai/llm-leaderboard
Codingscape “Most powerful LLMs in 2026” (Mar 2026) — https://codingscape.com/blog/most-powerful-llms-large-language-models
Liu et al. “Lost in the Middle” (arXiv:2307.03172, TACL 2024) — https://arxiv.org/abs/2307.03172
Stanford PDF — Lost in the Middle — https://cs.stanford.edu/~nfliu/papers/lost-in-the-middle.arxiv2023.pdf
TechXplore coverage (Jun 2025) — https://techxplore.com/news/2025-06-lost-middle-llm-architecture-ai.html
Mem0 “Architecture of Remembrance” — https://mem0.ai/blog/what-is-ai-agent-memory
MemoriLabs “RAG vs Memory for AI Agents” — https://memorilabs.ai/blog/rag-vs-memory-for-ai-agents/
Anthropic Context Engineering Cookbook — https://platform.claude.com/cookbook/tool-use-context-engineering-context-engineering-tools
Factory.ai “Evaluating Context Compression for AI Agents” — https://factory.ai/news/evaluating-compression
Ovadia et al. “Fine-Tuning or Retrieval?” (EMNLP 2024, Microsoft) — https://aclanthology.org/2024.emnlp-main.15.pdf
OpenClaw GitHub — Memory System — https://github.com/openclaw/openclaw
GitBook “OpenClaw Memory System Deep Dive” — https://snowan.gitbook.io/study-notes/ai-blogs/openclaw-memory-system-deep-dive
OpenClaw Docs — Context — https://docs.openclaw.ai/concepts/context
GitHub Issue #61347 — Selective/lazy injection — https://github.com/openclaw/openclaw/issues/61347
Mem0 LLM API Cost Breakdown — https://mem0.ai/blog/llm-api-cost-breakdown-claude-gemini-openai-compared
Inclusion Cloud “Vector Databases as Memory Layer” — https://inclusioncloud.com/insights/blog/vector-databases-enterprise-ai/
Dev Genius “RAG & Vector Databases: The Memory Layer of GenAI” — https://blog.devgenius.io/rag-vector-databases-the-memory-layer-of-genai-88a7df2f5b25

เกี่ยวกับผู้เขียน

เหน่ง (Neng) — นักวิชาการพัฒนาชุมชน กรมการพัฒนาชุมชน กระทรวงมหาดไทย สนใจด้าน AI Engineering, Multi-Agent Systems และการประยุกต์ใช้เทคโนโลยีเพื่อการพัฒนาชุมชน

GitHub · Telegram · Facebook

Ai-Memory on Neng Lab

Memory System ใน AI — ทำไม AI จำไม่ได้ + วิธีแก้

🔑 Key Takeaways

บทนำ: “ถาม AI เมื่อวานว่า ‘เราคุยอะไรกัน?’”

Part 1: ทำไม AI ถึง “จำไม่ได้”?

Context Window — “ความจำระยะสั้น” ของ AI

ปัญหา “Lost in the Middle”

Context Rot

ค่าใช้จ่าย & Latency

Part 2: 4 วิธีสอน AI ให้จำได้

วิธีที่ 1: File-based Memory (แบบที่ OpenClaw ใช้)

วิธีที่ 2: RAG + Vector Database

วิธีที่ 3: Context Compaction (สรุปย่อ context)

วิธีที่ 4: Fine-tuning for Memory

Part 3: ประสบการณ์จริง — Mick Optimize Memory ยังไง

ปัญหาที่เจอ: Context Injection เปลือง Tokens มหาศาล

การ Optimize

memorySearch — หาให้เจอ ก่อนส่งให้ AI

Part 4: เลือกวิธีไหนดี?

แนวทางแนะนำ: Layered Memory Architecture

บทส่งท้าย: ข้อผิดพลาดที่พบบ่อยเกี่ยวกับ AI Memory

❌ ยัดทุกอย่างใส่ context window

❌ ใช้ fine-tuning เพื่อ “สอนความรู้ใหม่”

❌ ใช้ vector search อย่างเดียวโดยไม่ดู chunk size

❌ ไม่มี memory retention policy

❌ ใช้ embedding model ที่ไม่ตรงกับ domain

สรุป: AI ไม่ได้จำไม่ได้ — แค่ต้องสอนวิธีจำ

เริ่มต้นยังไง? 3 ขั้นตอนง่ายๆ

📚 อ้างอิง

เกี่ยวกับผู้เขียน