ประเภทหน่วยความจำของ AI Agent และต้นทุนการจัดเก็บจริง

ประเภทของหน่วยความจำของ Agent ทั้ง 3 แบบ

ประเภทของหน่วยความจำของ Agent แบ่งออกเป็น 3 ส่วน และแต่ละส่วนส่งผลต่อฮาร์ดแวร์ที่คุณต้องจ่ายเงินแตกต่างกัน: หน่วยความจำเชิงความหมาย (semantic memory) เก็บข้อเท็จจริง, หน่วยความจำเชิงเหตุการณ์ (episodic memory) เก็บสิ่งที่เกิดขึ้น และหน่วยความจำเชิงกระบวนการ (procedural memory) เก็บวิธีการทำงาน ตารางด้านล่างนี้จะนิยามแต่ละประเภทพร้อมตัวอย่างบนเซิร์ฟเวอร์ เนื้อหาหลังจากนี้คือส่วนที่มักไม่มีการบันทึกไว้ ซึ่งก็คือต้นทุนในการจัดเก็บและต้นทุนในการสร้างใหม่ของแต่ละประเภท

[
  {
    "label": "Semantic",
    "what_it_holds": "Facts the agent should treat as currently true",
    "server_example": "The database listens on 10.8.0.4:5432 and the nightly dump runs at 03:15 UTC"
  },
  {
    "label": "Episodic",
    "what_it_holds": "A record of one past event or session",
    "server_example": "On 2026-08-11 the deploy failed because the disk was full, and rotating logs fixed it"
  },
  {
    "label": "Procedural",
    "what_it_holds": "How to carry out a task, as steps the agent can run",
    "server_example": "The restore runbook: stop the service, load the dump, run migrations, start the service"
  }
]

ชื่อเหล่านี้ยืมมาจากจิตวิทยาของมนุษย์และเป็นการนำมาใช้แบบหลวมๆ การแบ่งประเภทนี้มีประโยชน์ในทางปฏิบัติจริง เพราะหน่วยความจำทั้ง 3 แบบมีขนาดและเส้นทางการซ่อมแซมที่แตกต่างกัน ดังนั้นการนำทั้งหมดไปรวมไว้ใน vector store เดียวกันจะทำให้ประสิทธิภาพของแต่ละส่วนลดลง

Semantic memory มีขนาดเล็กและคุณอาจต้องการแก้ไขด้วยตนเอง

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

แนวทางนี้ชี้ไปที่การใช้ keyed store เช่น ตารางใน Postgres ที่มี primary key หรือไดเรกทอรีของไฟล์ markdown ขนาดเล็กที่จัดการด้วย git ทั้งสองวิธีช่วยให้คุณรัน query เพื่อดูค่าและแก้ไขข้อมูลได้โดยตรง การทำ similarity search ไม่สามารถทำเช่นนี้ได้เนื่องจากเป็นการดึงข้อมูลตามความคล้ายคลึงไม่ใช่ตามคีย์ คำสั่ง "เปลี่ยนพอร์ตฐานข้อมูล" จะกลายเป็น "ค้นหาทุกส่วนที่กล่าวถึงพอร์ตฐานข้อมูล" ซึ่งคุณไม่สามารถยืนยันได้ว่าพบข้อมูลทั้งหมดแล้ว ดังนั้นควรเก็บข้อเท็จจริงในรูปแบบที่มีคีย์กำกับ หากต้องการการเรียกคืนข้อมูลแบบกว้างๆ คุณสามารถทำ embedding ควบคู่ไปด้วยได้ แต่ต้องยึดถือข้อมูลในรูปแบบ keyed เป็นแหล่งข้อมูลหลักที่ถูกต้องเสมอ

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

เหตุใด episodic memory จึงเติบโตอย่างไม่จำกัด

Episodic memory คือบันทึก (log) และบันทึกย่อมมีขนาดเพิ่มขึ้น ทุกเซสชัน ทุกการเรียกใช้เครื่องมือ และทุกคำสั่งที่ล้มเหลวล้วนเป็นเหตุการณ์ (episode) ที่อาจถูกบันทึกได้ เอเจนต์ที่เขียนข้อมูลหนึ่งแถวต่อหนึ่งเทิร์นจะสร้างจำนวนแถวในหนึ่งเดือนมากกว่าที่ใครจะอ่านไหว และค่าใช้จ่ายไม่ได้มีแค่เรื่องพื้นที่ดิสก์เท่านั้น เพราะทุกเหตุการณ์ที่ถูกทำ embedding จะต้องเข้าไปอยู่ในดัชนีที่ระบบค้นหาต้องไล่ตรวจสอบด้วย

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

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

DELETE FROM episodes WHERE created_at < now() - interval '30 days';

ให้รันคำสั่งดังกล่าวผ่าน systemd timer จากนั้นคอยสังเกตจำนวนแถวและขนาดของตารางที่เปลี่ยนแปลงไปหลังจากนั้น นโยบายการเก็บรักษาข้อมูลที่ไม่มีการนำไปปฏิบัติจริงก็เป็นเพียงแค่ความคิดเห็นเท่านั้น

psql -d agentmem -c "SELECT count(*) FROM episodes;"
psql -d agentmem -c "SELECT pg_size_pretty(pg_total_relation_size('episodes'));"

หน่วยความจำเชิงกระบวนการควรอยู่ใน repository

หน่วยความจำเชิงกระบวนการคือวิธีการที่เอเจนต์ใช้ทำงาน เช่น shell script, ไฟล์ทักษะ หรือ runbook ที่มีขั้นตอนระบุหมายเลข สิ่งเหล่านี้คือโค้ด และโค้ดควรอยู่ในที่ที่โค้ดควรอยู่ นั่นคือใน git repository ซึ่งมีการตรวจสอบเวอร์ชัน มีการรีวิว และสามารถอ่านความแตกต่าง (diff) ได้

หากจัดเก็บ runbook ไว้เป็นส่วนย่อยๆ (chunks) ที่ฝังไว้ คุณจะได้เพียงสำเนาที่ใกล้เคียงกลับมาเท่านั้น การดึงข้อมูลจะส่งคืนเฉพาะส่วนที่ได้คะแนนสูงสุด ทำให้เอเจนต์อาจดำเนินการตามขั้นตอนที่ 2 และ 5 ในขณะที่ขั้นตอนที่ 3 ไม่ถูกดึงขึ้นมา และไม่มีการบันทึกว่าขั้นตอนเวอร์ชันใดที่ถูกนำไปใช้งาน ในขณะที่ git สามารถตอบคำถามทั้งสองข้อนี้ได้ด้วย git log นอกจากนี้ ต้นทุนในการจัดเก็บยังใกล้เคียงกับศูนย์ ซึ่งเป็นอีกเหตุผลหนึ่งที่ไม่ควรเสียค่าใช้จ่ายในราคาของ vector database สำหรับข้อมูลประเภทนี้

ต้นทุนการจัดเก็บ Embedding บนดิสก์จริง

[
  {
    "label": "bge-small-en-v1.5 (384 dims)",
    "bytes_per_vector": 1544,
    "mib_per_100k_rows": 147.2
  },
  {
    "label": "bge-base-en-v1.5 (768 dims)",
    "bytes_per_vector": 3080,
    "mib_per_100k_rows": 293.7
  },
  {
    "label": "bge-large-en-v1.5 (1024 dims)",
    "bytes_per_vector": 4104,
    "mib_per_100k_rows": 391.4
  },
  {
    "label": "text-embedding-3-small (1536 dims)",
    "bytes_per_vector": 6152,
    "mib_per_100k_rows": 586.7
  },
  {
    "label": "text-embedding-3-large (3072 dims)",
    "bytes_per_vector": 12296,
    "mib_per_100k_rows": 1172.6
  }
]

pgvector จัดเก็บ vector โดยใช้ขนาด 4 ไบต์ต่อหนึ่งมิติ บวกกับส่วนหัว (header) อีก 8 ไบต์ ดังนั้นการคำนวณนี้จึงเป็นค่าคงที่และคุณสามารถวางแผนล่วงหน้าได้ก่อนที่จะโหลดข้อมูลใดๆ เวกเตอร์ขนาด 384 มิติหนึ่งรายการมีขนาด 1544 ไบต์ ซึ่งทำให้ข้อมูล 100,000 ชิ้นใช้พื้นที่เวกเตอร์รวม 147.2 MiB หากใช้ corpus ชุดเดียวกันแต่ทำ embedding ที่ 3,072 มิติ จะใช้พื้นที่ 1172.6 MiB โดยมีขนาด 12296 ไบต์ต่อแถว ข้อความชุดเดิมแต่ใช้พื้นที่จัดเก็บเพิ่มขึ้นเกือบแปดเท่า

นั่นเป็นเพียงขนาดของคอลัมน์เวกเตอร์เท่านั้น ยังมีข้อความต้นฉบับ (chunk text), คีย์หลัก (primary key), overhead ของแถว และดัชนี (index) ที่ต้องนำมารวมด้วย ซึ่งดัชนีคือส่วนที่คนมักลืม HNSW (hierarchical navigable small world ซึ่งเป็นดัชนีกราฟที่ pgvector สร้างขึ้น) จะเก็บสำเนาของเวกเตอร์ที่เชื่อมโยงไว้ในตัวมันเอง ดังนั้นที่เก็บข้อมูลที่มีการทำดัชนีจะมีขนาดมากกว่าตัวเลขข้างต้นเกินสองเท่า ให้ใช้วิธีวัดค่าจริงแทนการคาดเดา

SELECT pg_size_pretty(pg_total_relation_size('memories')) AS total,
       pg_size_pretty(pg_relation_size('memories_embedding_idx')) AS idx;

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

NOTICE:  hnsw graph no longer fits into maintenance_work_mem after 61440 tuples
HINT:  Increase maintenance_work_mem to speed up builds.

มีสองวิธีในการลดขนาดของ corpus ชุดเดียวกัน วิธีแรกคือเลือกรุ่นโมเดลที่เล็กลง เนื่องจาก 384 มิติใช้พื้นที่เพียงหนึ่งในสี่ของ 1,536 มิติ และสำหรับการค้นหาบันทึกส่วนตัว ความแตกต่างของความแม่นยำมักจะน้อยจนยอมรับได้ วิธีที่สองคือการจัดเก็บแบบ half precision: ชนิดข้อมูล halfvec ใช้พื้นที่ 2 ไบต์ต่อมิติ บวกกับส่วนหัว 8 ไบต์เท่าเดิม ซึ่งช่วยลดขนาดของคอลัมน์และดัชนีลงได้เกือบครึ่งหนึ่ง

มีข้อจำกัดหนึ่งที่ควรทราบก่อนเลือกโมเดล ณ เดือนสิงหาคม 2026 คอลัมน์ vector สามารถทำดัชนีได้สูงสุดที่ 2,000 มิติ ดังนั้น embedding ขนาด 3,072 มิติจะสามารถบันทึกลงคอลัมน์ได้ แต่จะถูกปฏิเสธเมื่อทำการสร้างดัชนี:

ERROR:  column cannot have more than 2000 dimensions for hnsw index

halfvec รองรับการทำดัชนีได้สูงสุด 4,000 มิติ ดังนั้นวิธีแก้ไขทั่วไปคือการทำดัชนีโดยการ cast ข้อมูล:

CREATE INDEX ON memories USING hnsw ((embedding::halfvec(3072)) halfvec_cosine_ops);

เมื่อ pgvector เหนือกว่าบริการหน่วยความจำแยกต่างหาก

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

psql -V
sudo apt install postgresql-16-pgvector

CREATE EXTENSION vector;

ตัวเลขในชื่อแพ็กเกจคือเวอร์ชันหลักของ Postgres ของคุณ ซึ่งบน Ubuntu 24.04 คือ 16 ดังนั้นโปรดอ่าน psql -V ก่อนที่คุณจะพิมพ์คำสั่ง

การเก็บหน่วยความจำไว้ในฐานข้อมูลนั้นช่วยให้คุณสำรองข้อมูลหน่วยความจำและข้อมูลแอปพลิเคชันได้พร้อมกันในคราวเดียว มี connection pool เดียว และรองรับ transaction: ข้อมูลข้อเท็จจริงและแถวที่อธิบายข้อมูลนั้นจะ commit พร้อมกันหรือล้มเหลวพร้อมกัน บริการแยกต่างหากไม่สามารถรับประกันสิ่งนี้ได้

ให้ย้ายไปใช้บริการหน่วยความจำเฉพาะเมื่อเข้าเงื่อนไขข้อใดข้อหนึ่งต่อไปนี้: ภาระงานในการค้นหาแย่งทรัพยากรกับแอปพลิเคชันของคุณจนต้องการเครื่องแยกต่างหาก, มีเอเจนต์หลายตัวบนโฮสต์หลายเครื่องที่ต้องใช้หน่วยความจำร่วมกัน หรือคุณต้องการตรรกะการสกัดข้อมูลและการขจัดข้อมูลซ้ำซ้อนที่มาพร้อมกับผลิตภัณฑ์สำเร็จรูป ซึ่งเป็นเหตุผลสนับสนุนสำหรับการใช้ เซิร์ฟเวอร์หน่วยความจำ Mem0 แบบ self-hosted สำหรับเอเจนต์หนึ่งตัวและคลังข้อมูลที่มีจำนวน chunk หลักล้านต้นๆ การใช้ pgvector บนเครื่องที่คุณใช้งานอยู่แล้วจะช่วยลดภาระในการดูแลรักษาและลดโอกาสเกิดข้อผิดพลาดได้มากกว่า ทั้งนี้ การเลือก engine และความต้องการ RAM ของแต่ละ engine ได้รับการอธิบายไว้ใน การรันฐานข้อมูล vector บน VPS

ต้นทุนของการทำ re-embedding เมื่อเปลี่ยนโมเดล

เวกเตอร์จากโมเดลสองตัวที่ต่างกันไม่สามารถนำมาเปรียบเทียบกันได้ ดังนั้นคุณจึงไม่สามารถฝังหน่วยความจำใหม่ด้วยโมเดลใหม่โดยปล่อยแถวข้อมูลเก่าไว้เฉยๆ ได้ ตารางที่มีข้อมูลผสมกันจะให้ผลลัพธ์ที่ไร้ความหมาย เพราะระยะห่างที่คำนวณระหว่างระบบพิกัดสองระบบที่ต่างกันนั้นเป็นเพียงตัวเลขที่ไม่มีความหมาย การเปลี่ยนโมเดลหมายถึงการทำ re-embedding ข้อมูลทั้งหมดใหม่

ค่าใช้จ่ายในส่วนนี้ประกอบด้วย 4 ส่วน ได้แก่ ค่าโทเค็น (ค่าบริการ API หรือเวลา CPU และ GPU บนเครื่องของคุณเอง), เวลาที่ใช้จริงในการประมวลผล, พื้นที่ดิสก์ที่ต้องใช้สำหรับเก็บทั้งสองคอลัมน์พร้อมกันระหว่างการทำ backfill และการสร้างดัชนีใหม่ในขั้นตอนสุดท้าย ลำดับการทำงานที่ปลอดภัยคือการเพิ่มคอลัมน์ใหม่ ทำ backfill เป็นชุดๆ สลับไปใช้คอลัมน์ใหม่ในการสืบค้น จากนั้นจึงลบคอลัมน์เก่าและดัชนีของมันทิ้ง

ควรวัดอัตราการประมวลผลบนฮาร์ดแวร์ของคุณเองแทนการเชื่อตัวเลขที่เผยแพร่ทั่วไป เพราะการทำ embedding ด้วย CPU บน VPS ขนาดเล็กจะทำงานช้ากว่าการใช้โมเดลเดียวกันบน GPU อย่างมาก ให้ลองจับเวลาในส่วนข้อมูลตัวอย่างหนึ่งชุด แล้วนำไปคูณกับขนาดข้อมูลทั้งหมด

ollama pull nomic-embed-text
time curl -s http://localhost:11434/api/embed \
  -d '{"model": "nomic-embed-text", "input": "one representative chunk of your corpus"}' > /dev/null

โมเดล embedding แบบ local จะจัดเก็บไฟล์น้ำหนัก (weights) ไว้บนดิสก์เดียวกับที่เก็บหน่วยความจำ และเนื้อหาใน ตำแหน่งที่ Ollama จัดเก็บโมเดลที่ดาวน์โหลดมา จะอธิบายว่าพื้นที่ดังกล่าวถูกใช้ไปที่ใด

มีข้อกำหนดประการหนึ่งที่ทำให้กระบวนการทั้งหมดนี้เป็นไปได้ คือต้องเก็บข้อความต้นฉบับไว้คู่กับเวกเตอร์ทุกตัวเสมอ คลังข้อมูลที่เก็บเฉพาะเวกเตอร์จะไม่สามารถทำ re-embedding ได้เลย เพราะไม่มีข้อมูลเหลืออยู่สำหรับป้อนให้โมเดลใหม่ หากคุณไม่สามารถตอบได้ว่า "ข้อความใดที่สร้างแถวข้อมูลนี้ขึ้นมา" เส้นทางการย้ายข้อมูลของคุณจะเป็นการสร้างใหม่ทั้งหมดจากแหล่งที่มาของข้อความนั้นๆ

สิ่งที่ต้องเฝ้าระวังเมื่อหน่วยความจำเริ่มทำงาน

ค่าใช้จ่ายไม่ใช่สิ่งเดียวที่เปลี่ยนแปลงเมื่อพื้นที่จัดเก็บข้อมูลเต็ม ข้อมูลเก่าอาจล้าสมัยและเหตุการณ์เก่าๆ อาจเข้ามาแทนที่ผลลัพธ์ที่มีประโยชน์ ซึ่งเป็นปัญหาเรื่องการตัดแต่งข้อมูล (pruning) อีกครั้ง หน่วยความจำยังเป็นข้อมูลนำเข้าที่แก้ไขได้ซึ่งส่งผลต่อพฤติกรรมในอนาคตของเอเจนต์ ดังนั้นสิ่งที่ได้รับอนุญาตให้เขียนลงในหน่วยความจำจึงสามารถชี้นำการทำงานของเอเจนต์ในภายหลังได้ หากข้อความจากหน้าเว็บหรือตั๋วเข้าสู่หน่วยความจำ โปรดอ่าน วิธีการทำงานของการวางยาพิษในหน่วยความจำของเอเจนต์ ก่อนที่คุณจะขยายขอบเขตสิ่งที่สามารถเขียนข้อมูลได้ นอกจากนี้ ขนาดของการดึงข้อมูลยังส่งผลต่อการใช้โทเค็นในทุกคำขอ ซึ่งเป็นจุดเริ่มต้นของ การควบคุมค่าใช้จ่ายในการทำงานของเอเจนต์ให้คาดการณ์ได้

FAQ

ฉันจำเป็นต้องใช้ vector database สำหรับหน่วยความจำของ agent หรือไม่?

ไม่จำเป็นสำหรับข้อเท็จจริง (facts) หน่วยความจำเชิงความหมาย (semantic memory) มีขนาดเล็กและคุณจำเป็นต้องแก้ไขข้อมูลโดยระบุชื่อ ดังนั้นการใช้ตารางแบบ keyed table หรือไดเรกทอรีของไฟล์ markdown ใน git จะเหมาะสมกว่า เพราะคุณสามารถดูค่าและแก้ไขได้โดยตรง การใช้ embeddings จะคุ้มค่าก็ต่อเมื่อคุณต้องดึงข้อมูลตามความหมายจากคลังข้อมูลที่มีขนาดใหญ่เกินกว่าจะแสดงรายการได้ทั้งหมด ซึ่งมักจะเป็นหน่วยความจำเชิงเหตุการณ์ (episodic memory) และเอกสารต่างๆ หากคุณใช้งาน Postgres อยู่แล้ว CREATE EXTENSION vector สามารถรองรับงานนี้ได้โดยไม่ต้องเพิ่มบริการอื่นเข้ามาให้ต้องดูแล

หน่วยความจำของ agent จะใช้พื้นที่ดิสก์เท่าใด?

ขนาดของเวกเตอร์สามารถคาดการณ์ได้ โดยใช้ 4 ไบต์ต่อมิติ บวกกับส่วนหัว (header) ขนาด 8 ไบต์ใน pgvector ที่ 768 มิติ จะใช้พื้นที่ 293.7 MiB ต่อ 100,000 แถว และที่ 384 มิติ จะใช้พื้นที่ 147.2 MiB จากนั้นให้บวกเพิ่มด้วยข้อความใน chunk, overhead ของแถว และดัชนี HNSW ซึ่งเก็บสำเนาของเวกเตอร์ไว้เอง ดังนั้นควรเผื่อพื้นที่ไว้อย่างน้อยสองเท่าของขนาดเวกเตอร์ และวัดค่าจริงด้วย pg_total_relation_size

หน่วยความจำเชิงกระบวนการ (procedural memory) ควรเก็บไว้ที่ใด?

ควรเก็บไว้ใน git repository ในรูปแบบสคริปต์หรือไฟล์ทักษะ (skill files) ที่ agent เรียกใช้งานโดยตรง กระบวนการทำงานต้องการความแม่นยำในการเรียกใช้และประวัติเวอร์ชัน ซึ่งการค้นหาด้วยความคล้ายคลึง (similarity search) ไม่สามารถให้สิ่งเหล่านี้ได้ การดึงข้อมูล runbook แบบแบ่งส่วนอาจได้ผลลัพธ์ที่มีคะแนนสูงสุดกลับมา ซึ่งอาจหมายถึงขั้นตอนที่ 2 และ 5 ถูกดึงมา แต่ขั้นตอนที่ 3 หายไป และไม่มีการบันทึกว่าเวอร์ชันใดที่ถูกเรียกใช้งาน

การเปลี่ยน embedding model มีค่าใช้จ่ายอย่างไร?

คุณต้องทำ re-embedding ข้อมูลทั้งหมดใหม่ เนื่องจากเวกเตอร์จากโมเดลที่ต่างกันไม่สามารถนำมาเปรียบเทียบกันได้ คุณต้องคำนึงถึงค่าใช้จ่ายด้าน token หรือเวลาของ GPU, พื้นที่ดิสก์สำหรับคอลัมน์เก่าและใหม่ที่ต้องมีอยู่พร้อมกันในระหว่างดำเนินการ และการสร้างดัชนีใหม่ ให้เพิ่มคอลัมน์ใหม่, ทำการ backfill ข้อมูลเป็นชุดๆ, สลับการ query แล้วจึงลบคอลัมน์เก่าทิ้ง ทั้งหมดนี้ขึ้นอยู่กับการที่คุณเก็บข้อความต้นฉบับไว้คู่กับเวกเตอร์แต่ละตัวเสมอ