การจัดการบันทึกการอนุมาน LLM แบบรวมศูนย์: การสร้างความโปร่งใสในสภาพแวดล้อมการใช้งานจริงด้วย Converged Database

สำหรับวิศวกรที่ดูแลระบบ LLM Inference ในระดับโปรดักชัน คงมีไม่น้อยที่เคยประสบเหตุการณ์ต้องคอยสลับหน้าจอไปมาระหว่าง 3 แดชบอร์ดเพื่อตรวจสอบปัญหา โดยต้องดู "Input Prompt ใน CloudWatch, จำนวน Output Token ใน Datadog และ Error Log ใน Elasticsearch" การที่ข้อมูลที่จำเป็นต่อการสืบสวนสาเหตุของปัญหาถูกกระจัดกระจายเช่นนี้ ทำให้ต้องเสียเวลาไปหลายสิบนาทีเพียงเพื่อตรวจสอบความคลาดเคลื่อนของ Timestamp หรือจับคู่ข้อมูลที่ขาดหายไป

Converged Database คือฐานข้อมูลที่สามารถจัดการโมเดลข้อมูลที่หลากหลาย ไม่ว่าจะเป็น relational, document/JSON, graph, vector และ text ได้ภายใน Engine เดียว โดยบริหารจัดการผ่าน Optimizer และขอบเขตของ Transaction เพียงชุดเดียว ในบทความนี้ เราจะมาสรุปประเด็นปัญหาของสถานการณ์ปัจจุบันที่ Log ขาเข้า-ขาออก, Latency, ปริมาณการใช้ Token และ Error Event ถูกจัดเก็บแยกกันในหลาย Storage สำหรับผู้ดูแลระบบ LLM Inference ขนาดใหญ่, วิศวกร Backend และวิศวกร MLOps พร้อมทั้งอธิบายขั้นตอนการนำ Converged Database มาใช้เพื่อการบริหารจัดการแบบบูรณาการ เมื่ออ่านจบ คุณจะเห็นแนวทางที่เป็นรูปธรรมในการเพิ่มประสิทธิภาพการตอบสนองต่อการตรวจจับความผิดปกติ (Anomaly Detection) และความแม่นยำในการตรวจจับ Drift ผ่านวิธีการทำ Visualization ที่ชัดเจน

ในการอนุมานด้วย LLM จะมีการเกิดขึ้นของข้อมูลหลายประเภทพร้อมกัน ได้แก่ ข้อมูลข้อความ/JSON เช่น พรอมต์และข้อความที่สร้างขึ้น, ข้อมูลเมตริกอนุกรมเวลา (Time-series metrics) เช่น ค่าความหน่วง (Latency) และปริมาณการใช้โทเค็น รวมถึงเวกเตอร์เอ็มเบดดิ้ง (Vector embeddings) ที่ใช้สำหรับการค้นหาความคล้ายคลึง โดยทั่วไปแล้วในอดีตจะใช้วิธีแยกจัดเก็บข้อมูลเหล่านี้ไว้ในที่จัดเก็บเฉพาะตามวัตถุประสงค์ (Text DB, Time-series DB, Vector DB) แต่การแยกส่วนเช่นนี้มีราคาที่ต้องจ่าย คือการที่แอปพลิเคชันต้องเสียเวลาคอยรวมผลลัพธ์จากหลายคิวรีเข้าด้วยกันเพียงเพื่อจะติดตามข้อมูลของการอนุมานในหนึ่งครั้ง

Converged Database คือกลไกที่จัดการโมเดลข้อมูลทั้งแบบ relational, document/JSON, vector, text และ graph ได้โดยตรงภายในเอนจินเดียว และบริหารจัดการด้วยตัวปรับแต่งประสิทธิภาพ (Optimizer) และรูปแบบความสอดคล้อง (Consistency model) เพียงหนึ่งเดียว โดยเกณฑ์การตัดสินในทางปฏิบัติจะอยู่ที่ว่า "สามารถจัดการได้ภายในขอบเขตของธุรกรรม (Transaction boundary) เดียวกันหรือไม่" มากกว่าประเภทของโมเดลข้อมูล ด้วยการออกแบบนี้ ทำให้ไม่จำเป็นต้องดึงข้อมูลอินพุต/เอาต์พุต, ค่าความหน่วง, จำนวนโทเค็น และเหตุการณ์ข้อผิดพลาดของการอนุมานแต่ละครั้งแยกกันแล้วนำมาเชื่อมโยงกันในภายหลัง แต่สามารถทำการวิเคราะห์ความสัมพันธ์ภายในขอบเขตของธุรกรรมเดียวได้ทันที

การรวมโมเดลข้อมูลนี้เป็นแนวคิดพื้นฐานในการเพิ่มการตอบสนองต่อการตรวจจับความผิดปกติและยกระดับความแม่นยำในการตรวจจับการเบี่ยงเบนของข้อมูล (Drift detection) ในส่วนถัดไป เราจะสรุปให้เห็นว่าการจัดการแบบกระจายศูนย์นำไปสู่ความล่าช้าและการลดลงของความแม่นยำในการตรวจจับได้อย่างไร

หากความเร่งด่วนในการตรวจสอบปัญหาอยู่ในระดับสูง การเข้าถึง Latency และ Error Log ได้ทันทีจะมีความสำคัญเป็นอันดับแรก แต่หากมีวัตถุประสงค์เพื่อการตรวจสอบ (Audit) หรือการวิเคราะห์ต้นทุน ความครบถ้วนของ Log ปริมาณการใช้ Token และระยะเวลาในการจัดเก็บจะมีความสำคัญมากกว่า เมื่อพิจารณาจากเกณฑ์การตัดสินใจดังกล่าว สามารถสรุปรูปแบบการกระจายข้อมูลที่เป็นตัวแทนได้ดังนี้

เมื่อเปรียบเทียบทั้ง 4 แถวในตาราง จะเห็นได้ว่าทั้ง Text/JSON Store และ Time-series DB ต่างก็มีความเร็วในตัวของมันเอง แต่หากนำทั้งสองมาใช้ร่วมกันเพื่อ "ตรวจสอบว่ามีอะไรเข้า-ออกบ้างในช่วงเวลาที่ Latency ของคำขอนั้นพุ่งสูงขึ้น" ความยุ่งยากในการทำ Join จะกลายเป็นคอขวด เช่นเดียวกับ Vector DB ที่แม้การค้นหาความคล้ายคลึงจะรวดเร็ว แต่เมื่อต้องการกรองผลลัพธ์โดยเชื่อมโยงกับจำนวน Token หรือข้อมูลการเรียกเก็บเงิน ก็อาจมีสถานการณ์ที่จำเป็นต้องใช้ Query แยกต่างหาก

นอกจากนี้ ในโครงสร้างแบบกระจาย (Distributed Configuration) แต่ละ Store จะมีโมเดลความสอดคล้อง (Consistency Model) เป็นของตัวเอง ทำให้เกิดกรณีที่ Timestamp ของ Log คลาดเคลื่อนกันเล็กน้อย แม้จะเป็นความคลาดเคลื่อนเพียงไม่กี่ร้อยมิลลิวินาที แต่ก็อาจเป็นข้อผิดพลาดที่ไม่สามารถมองข้ามได้เมื่อต้องติดตามลำดับเหตุการณ์ในการตรวจสอบปัญหา หากให้ความสำคัญกับการตอบสนองต่อการตรวจพบความผิดปกติ ความคลาดเคลื่อนของเวลาและจำนวนครั้งในการทำ Join Query เหล่านี้เองที่จะเป็นเกณฑ์การตัดสินใจในทางปฏิบัติเมื่อต้องเลือกโครงสร้างของ Store

การจัดเก็บข้อมูล Input/Output log, Latency, ปริมาณการใช้ Token และ Error event ไว้ใน Store แยกกัน จะทำให้เกิดกระบวนการที่ต้องส่ง Query ไปยังหลายระบบแยกกันและนำผลลัพธ์มาเชื่อมโยงกันเองเมื่อต้องตรวจสอบปัญหา การไปกลับของข้อมูลในแต่ละครั้งจะสะสมทั้ง Network I/O และการรอประมวลผล ซึ่งแม้แต่การกรองข้อมูลแบบง่ายๆ ก็อาจเพิ่มความล่าช้าได้ตั้งแต่หลายร้อยมิลลิวินาทีไปจนถึงหลายวินาที

ในหน้างานที่ต้องการระบุให้ได้ภายในไม่กี่นาทีว่า "เกิดอะไรขึ้นกับ Request ใด" เมื่อมีความผิดปกติเกิดขึ้น การไปกลับระหว่าง Store เหล่านี้ถือเป็นคอขวดที่ใหญ่ที่สุด ลองพิจารณาสถานการณ์ที่ต้องตรวจสอบว่า Latency แย่ลงใน Prompt pattern เฉพาะหรือไม่ เราจำเป็นต้องใช้ Query สองขั้นตอน คือการดึง ID ของ Prompt เป้าหมายจาก Text store แล้วส่งรายการ ID นั้นไปยัง Time-series DB เพื่อจับคู่กับ Latency ซึ่งยิ่งปริมาณข้อมูลเพิ่มขึ้น ต้นทุนในการส่งผ่านผลลัพธ์ระหว่างกลางก็จะยิ่งกลายเป็นสิ่งที่มองข้ามไม่ได้

หากแต่ละ Store มีรูปแบบความสอดคล้องของข้อมูล (Consistency model) ที่แตกต่างกัน อาจเกิดกรณีที่ Log ของ Request เดียวกันถูกอ้างอิงในสถานะที่ไม่ครบถ้วนชั่วคราวเนื่องจากความเหลื่อมลือของจังหวะเวลาในการเขียนข้อมูล ซึ่งไม่เพียงแต่ทำให้ Dashboard การตรวจสอบแสดงผลล่าช้าเท่านั้น แต่อาจนำไปสู่การแจ้งเตือนอัตโนมัติที่ผิดพลาดหรือการตรวจไม่พบปัญหาได้ หากสามารถจัดการ Input/Output, Metrics และ Error ภายใต้ขอบเขต Transaction เดียวกันได้ ต้นทุนการเชื่อมโยงข้อมูลและความไม่สอดคล้องเหล่านี้ก็จะถูกกำจัดออกไปในเชิงโครงสร้าง

สาเหตุที่การตรวจจับ Drift ในการใช้งานจริงมีความล่าช้า อยู่ที่โครงสร้างการกระจายตัวของ Log เอง

การตรวจจับ Drift คือกระบวนการติดตามการเปลี่ยนแปลงของการกระจายตัวของ Input/Output ตามช่วงเวลา และเปรียบเทียบความแตกต่างกับข้อมูลในอดีตอย่างต่อเนื่อง อย่างไรก็ตาม หาก Input/Output Text ถูกเก็บไว้ใน Document Store ในขณะที่ Latency และ Token Usage ถูกเก็บแยกไว้ใน Time-series DB กระบวนการ Join เพื่อจับคู่ข้อมูลทั้งสองส่วนจะต้องเกิดขึ้นก่อนขั้นตอนการตรวจจับเสมอ หากโครงสร้างนี้ต้องพึ่งพา Batch Processing ที่ทำงานเป็นรอบ จะทำให้เกิด Time lag เท่ากับช่วงเวลาของ Batch ตั้งแต่เกิดความผิดปกติจนถึงเวลาที่ Logic การตรวจจับจะตรวจพบความแตกต่าง หากเป็น Batch รายชั่วโมง ในกรณีที่เลวร้ายที่สุดอาจต้องใช้เวลาเกือบ 1 ชั่วโมงกว่าจะตรวจพบ

นอกจากนี้ หากระยะเวลาการเก็บรักษาข้อมูล (Data Retention) หรือความละเอียดของข้อมูล (Granularity) ในแต่ละ Store ไม่เท่ากัน ช่วงเวลาที่ใช้เปรียบเทียบจะคลาดเคลื่อน ส่งผลให้เกิดการแจ้งเตือนผิดพลาด (False Positive) หรือตรวจไม่พบ (False Negative) หากต้องการตรวจสอบแนวโน้มของ Prompt ที่เปลี่ยนไป ระยะเวลาการเก็บรักษาของ Text Store จะเป็นจุดเริ่มต้น แต่หากต้องการตรวจสอบ Latency ที่แย่ลง ความละเอียดของ Time-series DB จะเป็นจุดเริ่มต้น การที่เวลาในการตรวจจับเปลี่ยนไปตาม Store ที่อ้างอิงแม้จะเป็นเหตุการณ์ (Incident) เดียวกันนั้น มีสาเหตุมาจากความไม่สอดคล้องกันของจุดเริ่มต้นนี้ ตัวอย่างเช่น ในกรณีที่เนื้อหาของ Prompt เปลี่ยนไปพร้อมกับ Latency ที่แย่ลง แม้ใน Text Store จะเริ่มเห็นการเปลี่ยนแปลงของแนวโน้มในไม่กี่นาที แต่หากความละเอียดของ Time-series DB ถูกสรุปผลเป็นหน่วย 5 นาทีหรือ 1 นาที ก็ต้องใช้เวลาอีกกว่าที่ความผิดปกติของทั้งสองส่วนจะถูกเชื่อมโยงว่าเป็น "เหตุการณ์เดียวกัน" ซึ่งบ่อยครั้งที่เมื่อเจ้าหน้าที่เห็นการแจ้งเตือน การแยกแยะสาเหตุก็กลายเป็นเรื่องยากไปแล้ว

ในระบบ Observability อย่าง Prometheus มีการแนะนำให้ใช้ Histogram สำหรับการวัด Latency แต่ความละเอียดนี้อาจไม่ตรงกับความละเอียดของ Log ในฝั่ง Text Store ในกรณีที่ Time-series DB เก็บค่าที่ปัดเศษเป็น Bucket ในขณะที่ Text Store เก็บ Raw Log ราย Request การจับคู่ข้อมูลอาจทำให้ข้อมูลฝั่งหนึ่งหยาบเกินไปจนไม่สามารถตรวจพบความแตกต่างที่มีนัยสำคัญทางสถิติได้ เมื่อความไม่สอดคล้องของความละเอียดสะสมมากขึ้น จะทำให้ไม่สามารถตรวจจับการเปลี่ยนแปลงของการกระจายตัวที่เกิดขึ้นจริงได้ในเชิงสถิติ ส่งผลให้ความแม่นยำในการตรวจจับลดลงโดยตรง

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

ในบันทึกการอนุมาน (Inference Log) ของ LLM จะมีข้อมูลที่มีคุณลักษณะแตกต่างกันปะปนอยู่ ทั้งข้อความขาเข้าและขาออก (Input/Output text), ค่า Latency และ Throughput, รวมถึงปริมาณการใช้ Token และค่าใช้จ่าย หากยังคงใช้งานโดยแยกข้อมูลเหล่านี้ไว้ในตารางหรือไฟล์บันทึกที่กระจัดกระจาย จะทำให้เกิดภาระในการนำข้อมูลจากหลายแหล่งมาตรวจสอบเปรียบเทียบกันทุกครั้งที่เกิดปัญหา ส่งผลให้ใช้เวลานานกว่าจะระบุสาเหตุได้ หากออกแบบให้บันทึกข้อมูลแบบรวมศูนย์โดยใช้ Request ID เดียวกันเป็นแกนกลาง ก็จะสามารถขจัดต้นทุนในการตรวจสอบเปรียบเทียบนี้ออกไปได้ในเชิงโครงสร้าง ต่อจากนี้จะเน้นไปที่ข้อความขาเข้าและขาออกรวมถึง Metadata ซึ่งเป็นหัวใจสำคัญของการบูรณาการ ส่วนข้อมูลประเภทอื่นจะกล่าวถึงเฉพาะประเด็นสำคัญเท่านั้น

การตัดสินใจว่าจะจัดเก็บ Log การรับส่งข้อมูล (Input/Output Log) เป็นคอลัมน์ประเภท Text หรือจัดเก็บแบบโครงสร้างด้วยประเภท JSON ขึ้นอยู่กับว่าโครงสร้างของ Prompt นั้นเป็นเพียงสตริงเดียวแบบง่าย หรือเป็นโครงสร้างหลายระดับที่รวมถึง System Prompt และผลลัพธ์จากการเรียกใช้ Tool (Tool calling) หากเป็นเพียงการถามตอบทั่วไป ประเภท Text ก็เพียงพอแล้ว แต่หากรวมถึงผลลัพธ์การค้นหาจาก RAG หรือประวัติการสนทนาแบบ Multi-turn คุณสมบัติของ Converged Database ที่สามารถจัดการทั้งข้อมูลแบบ Relational และแบบ Document/JSON ได้ใน Engine เดียวจะแสดงประสิทธิภาพออกมาได้ดีที่สุด

ในหน้างานด้านการตรวจจับความผิดปกติ (Anomaly detection) มักจะพบอุปสรรคที่ทำให้การตรวจสอบหยุดชะงัก หากไม่สามารถดึงข้อมูลการรับส่งข้อมูลฉบับเต็มออกมาได้ทันทีเมื่อต้องตรวจสอบว่าส่วนใดของข้อความที่สร้างขึ้น (Generated text) ที่มีความผิดปกติ หากแยกจัดเก็บ Prompt และผลลัพธ์ที่ได้ไว้ใน Storage คนละแห่ง จะต้องเสียเวลาไปกับการสืบค้นข้ามระบบโดยใช้ Request ID เป็นตัวเชื่อม ซึ่งจะทำให้การตอบสนองเบื้องต้นล่าช้า ต้นทุนในการสืบค้นข้ามระบบนี้เป็นสิ่งที่มองข้ามไม่ได้ในสภาพแวดล้อมการใช้งานจริง (Production environment) ที่การตอบสนองต่อเหตุขัดข้องในช่วงแรกมีความสำคัญในระดับนาที

ในการจัดเก็บข้อมูล จำเป็นต้องกำหนดนโยบายการทำ Masking หรือการเข้ารหัสไว้ล่วงหน้า โดยคำนึงถึงความเป็นไปได้ที่จะมีข้อมูลส่วนบุคคลหรือข้อมูลที่เป็นความลับรวมอยู่ด้วย ในกรณีที่ข้อความที่สร้างขึ้นมีความยาวมาก การแยกจัดเก็บแบบฉบับเต็มและแบบสรุป (Summary) โดยอ้างอิงฉบับเต็มเฉพาะเมื่อต้องการตรวจสอบรายละเอียดเชิงลึกก็เป็นอีกทางเลือกหนึ่ง เนื่องจาก Log การรับส่งข้อมูลเป็นฐานรากสำคัญสำหรับการตรวจสอบ (Audit), การดีบั๊ก (Debug) และการตรวจจับความคลาดเคลื่อน (Drift detection) การออกแบบให้สามารถเชื่อมโยงกับ Metric อื่นๆ ได้ด้วย Request ID เดียวกันจึงเป็นสิ่งที่จำเป็นต้องมีตั้งแต่ต้น

Latency และ Throughput ควรได้รับการจัดการในรูปแบบอนุกรมเวลา (Time-series) โดยแยกเป็นตารางหรือกลุ่มคอลัมน์ต่างหากจากบันทึก Input/Output เนื่องจากข้อมูล Input/Output เป็นข้อมูลที่ใช้ตรวจสอบเป็นรายกรณี แต่ Latency เป็นตัวเลขที่ต้องนำมาประมวลผลรวมและติดตามแนวโน้มอยู่ตลอดเวลา หากใช้ Converged Database ที่สามารถจัดการข้อมูลทั้งสองประเภทได้ด้วย Query Engine เดียวกัน จะสามารถนำ Latency ณ เวลาที่ตรวจพบข้อความที่สร้างขึ้นผิดปกติมาตรวจสอบเปรียบเทียบภายในขอบเขตของ Transaction เดียวกันได้ทันที

ในการบันทึก Latency สิ่งสำคัญคือต้องเก็บข้อมูลในรูปแบบการกระจายตัว (Distribution) ไม่ใช่แค่ค่าเฉลี่ย ตามแนวทางปฏิบัติที่ดีที่สุดของ Prometheus ได้ระบุไว้อย่างชัดเจนว่าการวัด Latency ควรให้ความสำคัญกับ Histogram มากกว่า Summary เนื่องจากสามารถนำมาคำนวณค่า Percentile (เช่น p95 หรือ p99) ใหม่ได้อย่างยืดหยุ่นในภายหลัง ในระบบ Inference มักพบกรณีที่คำขอเพียงบางส่วนเกิดความล่าช้าอย่างรุนแรง ซึ่งหากดูเพียงค่าเฉลี่ยก็จะทำให้มองข้ามความผิดปกติประเภทนี้ไป สถานะที่ p50 มีความเสถียรแต่ p99 พุ่งสูงขึ้น อาจมีสาเหตุมาจากความยาวของ Prompt หรือจังหวะการทำ Batch Processing หากไม่มีการเก็บข้อมูล Histogram ไว้ ก็จะไม่สามารถสืบหาสาเหตุย้อนหลังได้เลย

สำหรับ Throughput หากบันทึกจำนวนการประมวลผลต่อหน่วยเวลาโดยแยกตาม Endpoint หรือเวอร์ชันของโมเดล จะช่วยให้สามารถแยกแยะความไม่สมดุลของ Load Balancing หรือการเสื่อมถอยของประสิทธิภาพเมื่อมีการสลับโมเดลได้ง่ายขึ้น ในการใช้งาน InvokeEndpoint ของ AWS SageMaker มีข้อจำกัดว่าการประมวลผลของโมเดลต้องตอบสนองภายใน 60 วินาที การเฝ้าติดตามสัดส่วนของคำขอที่ใกล้ถึงขีดจำกัดนี้จะช่วยให้ตรวจพบการเสื่อมถอยของประสิทธิภาพก่อนที่จะเกิด Timeout ได้ตั้งแต่เนิ่นๆ

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

ใน OpenAI API นั้น ออบเจกต์การตอบกลับจะมีฟิลด์ usage ซึ่งประกอบด้วย prompt_tokens, completion_tokens และ total_tokens โดยคุณสามารถจัดเก็บข้อมูลเหล่านี้ในรูปแบบโครงสร้างลงใน Converged Database ได้โดยตรง สำหรับการใช้งาน Batch API นั้น มีข้อกำหนดว่าค่า usage จะถูกบันทึกเฉพาะสำหรับแบตช์ที่สร้างขึ้นหลังจากช่วงเวลาที่กำหนดเท่านั้น ดังนั้นในระบบที่ใช้การประมวลผลแบบแบตช์ร่วมด้วย จึงจำเป็นต้องตรวจสอบสถานะการบันทึกข้อมูลให้ดี

การบันทึกจำนวนโทเค็นเพียงอย่างเดียวนั้นไม่เพียงพอ การจัดเก็บข้อมูลโดยเชื่อมโยงชื่อโมเดล, แหล่งที่มาของคำขอ และเนื้อหาของข้อความที่สร้างขึ้นไว้ภายในขอบเขตธุรกรรม (Transaction boundary) เดียวกัน จะช่วยให้คุณสามารถระบุได้ทันทีว่า "การออกแบบพรอมต์ใดที่เป็นสาเหตุ" เมื่อเกิดต้นทุนพุ่งสูงขึ้น หากคุณออกแบบให้มีจำนวนโทเค็นต่อคำขอเป็นคอลัมน์แบบอนุกรมเวลา (Time-series column) และเชื่อมโยง ID ของบันทึกอินพุต/เอาต์พุตด้วย Foreign key คุณจะสามารถย้อนกลับไปดูเนื้อหาที่สร้างขึ้นที่เกี่ยวข้องได้ด้วยการคิวรีเพียงครั้งเดียวจากสัญญาณเตือนความผิดปกติของต้นทุน ซึ่งถือเป็นข้อได้เปรียบเฉพาะของการจัดการแบบบูรณาการที่ทำได้ยากหากบันทึกข้อมูลกระจัดกระจายอยู่ในที่เก็บข้อมูลต่างกัน

การจัดการแบบรวมศูนย์สำหรับบันทึกการอนุมาน (Inference Log) หากพยายามปรับเปลี่ยนทั้งหมดในคราวเดียวจะส่งผลกระทบต่อระบบเดิมมากเกินไป ดังนั้น ในทางปฏิบัติจึงนิยมใช้วิธีแบ่งการดำเนินงานออกเป็น 3 ขั้นตอน ได้แก่ การเลือกและสร้างโครงสร้างพื้นฐานของ "Converged Database" ในช่วงเริ่มต้น, การจัดเก็บและจัดรูปแบบบันทึกขณะประมวลผลการอนุมาน, และการสร้างไปป์ไลน์สำหรับการรวบรวมข้อมูล ต่อไปนี้เราจะมาดูกันว่าในแต่ละขั้นตอนควรทำอะไรและทำถึงระดับไหนครับ

หากปริมาณบันทึกข้อมูล (log) ที่มีอยู่มีขนาดหลายร้อย GB และส่วนใหญ่เป็นข้อมูลที่มีโครงสร้าง (structured data) ตัวเลือกที่เหมาะสมคือการใช้ PostgreSQL ที่ปรับแต่งด้วยส่วนขยาย TimescaleDB แต่หากมีข้อมูลที่ไม่มีโครงสร้าง (unstructured data) เช่น ข้อความที่สร้างขึ้น (generated text) หรือเวกเตอร์ฝังตัว (embedding vector) จำนวนมาก ตัวเลือกที่เหมาะสมจะเป็นเอนจินแบบคอลัมน์ (column-oriented engine) อย่าง ClickHouse ทั้งนี้ Converged Database หมายถึงการออกแบบที่รองรับประเภทข้อมูลต่าง ๆ เช่น relational, document/JSON, vector และ text ได้โดยตรงบนเอนจินเดียว โดยรวมตัวปรับประสิทธิภาพ (optimizer) และขอบเขตของธุรกรรม (transaction boundary) ไว้เป็นหนึ่งเดียว คุณสมบัตินี้ช่วยให้สามารถรวมข้อมูลอินพุต/เอาต์พุตของบันทึกการอนุมาน (inference log), ข้อมูลเมตา (metadata) และการแสดงผลแบบเวกเตอร์เข้าด้วยกันได้บนฐานการสืบค้นเดียวกัน โดยไม่ต้องแยกเก็บไว้ในที่จัดเก็บข้อมูลต่างหาก ซึ่งถือเป็นปัจจัยสำคัญในการตัดสินใจเลือกใช้งาน

สำหรับการสร้างระบบในระยะเริ่มต้น ให้เริ่มจากการตรวจสอบสคีมาของบันทึกข้อมูลที่มีอยู่ และกำหนดว่าข้อมูลแต่ละรายการ ได้แก่ พรอมต์ (prompt), ข้อความที่สร้างขึ้น, ค่าความหน่วง (latency), ปริมาณการใช้โทเค็น (token usage) และเหตุการณ์ข้อผิดพลาด (error event) จะถูกจัดเก็บด้วยประเภทข้อมูลใด (JSON, text, numeric, vector) จากนั้นจึงออกแบบนโยบายการทำดัชนี (indexing policy) โดยอิงจากความถี่ในการเขียนและรูปแบบการสืบค้นที่คาดการณ์ไว้ และหากมีข้อมูลอนุกรมเวลา (time-series data) จำนวนมาก ให้พิจารณาการแบ่งพาร์ทิชันตามแกนเวลา (time-based partitioning) สำหรับการ ย้ายระบบ (migration) วิธีที่ปลอดภัยที่สุดคือการค่อยๆ สลับทราฟฟิกการใช้งานจริงทีละขั้นตอน โดยการกำหนดช่วงเวลาที่ให้ระบบทำงานขนานไปกับที่จัดเก็บข้อมูลเดิมเพื่อตรวจสอบความถูกต้องของข้อมูล จะช่วยลดความเสี่ยงในการสูญหายของข้อมูลในระหว่างการเปลี่ยนผ่านได้

การกำหนดรายการบันทึก (log) ที่ควรจัดเก็บไว้ล่วงหน้าในระหว่างการประมวลผลการอนุมาน (inference) จะช่วยลดปัญหาข้อมูลสูญหายหรือประเภทข้อมูลไม่ตรงกันในไปป์ไลน์การรวบรวมข้อมูลส่วนหลังได้ โดยเฉพาะอย่างยิ่ง ควรจัดรูปแบบข้อมูล 4 ประเภท ได้แก่ ข้อความขาเข้าและขาออก (Prompt และผลลัพธ์ที่สร้างขึ้น), Latency, ปริมาณการใช้ Token และเหตุการณ์ข้อผิดพลาด (Error event) ให้อยู่ในรูปแบบ JSON โดยใช้ Schema เดียวกัน

สำหรับปริมาณการใช้ Token หากสามารถดึงข้อมูล prompt_tokens, completion_tokens และ total_tokens ได้โดยตรงจาก object usage ในการตอบกลับ เช่นเดียวกับ OpenAI API การแมปข้อมูลเหล่านั้นลงในฟิลด์ของบันทึกการอนุมานโดยตรงจะช่วยลดต้นทุนในการติดตั้งใช้งาน อย่างไรก็ตาม เนื่องจากมีข้อกำหนดว่าในการเรียกใช้งานผ่าน Batch API ข้อมูล usage จะถูกเติมเต็ม (populate) เฉพาะใน Batch ที่สร้างขึ้นหลังจากช่วงเวลาหนึ่งเท่านั้น ดังนั้น ในการกำหนดค่าที่ใช้การอนุมานแบบ Batch ควบคู่ไปด้วย จึงจำเป็นต้องมีการเขียนโปรแกรมเพื่อรองรับความเข้ากันได้แบบย้อนหลัง (backward compatibility) โดยตั้งสมมติฐานว่าอาจเกิดกรณีฟิลด์ข้อมูลสูญหายได้

ในส่วนของ Latency ให้บันทึกเวลาที่ใช้ในการประมวลผลตั้งแต่ได้รับคำขอจนถึงการส่งผลลัพธ์กลับคืนในหน่วยมิลลิวินาที และหากเป็นไปได้ การแยกวัดผลระหว่างส่วนการเรียกใช้โมเดลกับส่วนการประมวลผลก่อนหน้า (pre-processing) และหลังการประมวลผล (post-processing) จะช่วยให้การระบุคอขวดในการตรวจจับความผิดปกติภายหลังทำได้ง่ายขึ้น สำหรับเหตุการณ์ข้อผิดพลาด (Error event) ควรบันทึกเป็นรหัสสถานะแบบ Enum เช่น Timeout, Rate limit หรือรูปแบบเอาต์พุตผิดปกติ และแยกเก็บไว้ในคอลัมน์ที่ต่างจากข้อความแสดงข้อผิดพลาดแบบอิสระ ซึ่งจะช่วยให้การเขียน Query เพื่อสรุปผลบน Converged Database มีความกระชับยิ่งขึ้น

ผู้ดูแลระบบหลายท่านอาจเคยลังเลในขั้นตอนการออกแบบคอลเลกชันไปป์ไลน์ (Collection Pipeline) ว่าควรเขียนบันทึก (Log) ที่จัดรูปแบบแล้วลงในคอนเวอร์จด์ดาต้าเบส (Converged Database) ในจังหวะเวลาใด

วิธีการแบบซิงโครนัส (Synchronous) ที่เขียนลงในฐานข้อมูลโดยตรงภายในกระบวนการอนุมาน (Inference Process) นั้นมีการใช้งานที่เรียบง่าย แต่มีแนวโน้มที่ความหน่วงในการเขียนจะส่งผลกระทบต่อการตอบสนองของการอนุมานโดยตรง ดังนั้น ในการใช้งานส่วนใหญ่จึงเลือกใช้วิธีแบบอะซิงโครนัส (Asynchronous) ที่แยกกระบวนการอนุมานออกจากการเขียนบันทึก โดยเฉพาะอย่างยิ่งคือการกำหนดค่าให้แอปพลิเคชันจัดเก็บบันทึกไว้ในข้อความคิว (Message Queue) หรือบัฟเฟอร์ภายในเครื่องชั่วคราว แล้วให้ตัวรวบรวม (Collector) ในกระบวนการแยกต่างหากเป็นผู้ส่งข้อมูลเข้าสู่คอนเวอร์จด์ดาต้าเบสแบบเป็นชุด (Batch)

การออกแบบขนาดของชุดข้อมูล (Batch Size) เป็นการแลกเปลี่ยนระหว่างความถี่ในการรวบรวมข้อมูลกับภาระของฐานข้อมูล สำหรับการใช้งานด้านการตรวจจับความผิดปกติที่เน้นความเรียลไทม์ จำเป็นต้องรักษาช่วงเวลาของชุดข้อมูลให้สั้น ในขณะที่การใช้งานอย่างการสรุปยอดการใช้โทเค็น (Token Usage) ซึ่งให้ความสำคัญกับการเพิ่มประสิทธิภาพด้านต้นทุน การเขียนข้อมูลรวมกันเป็นชุดในระดับหน่วยนาทีก็มักจะไม่ส่งผลเสียในทางปฏิบัติ ดังนั้น ในทางปฏิบัติจึงควรมีการกำหนดเงื่อนไขแยกส่วนภายในคอลเลกชันไปป์ไลน์ โดยประมวลผลบันทึกที่ต้องการการตรวจจับทันที เช่น ค่าความหน่วง (Latency) หรือเหตุการณ์ข้อผิดพลาด (Error Event) ด้วยช่วงเวลาที่สั้นและชุดข้อมูลขนาดเล็ก ส่วนบันทึกที่เพียงพอต่อการวิเคราะห์ย้อนหลัง เช่น การสรุปยอดการใช้โทเค็นหรือต้นทุน ให้ประมวลผลด้วยช่วงเวลาที่ยาวและชุดข้อมูลขนาดใหญ่

นอกจากนี้ ในเอกสารอย่างเป็นทางการของ AWS SageMaker Data Capture ยังมีข้อควรระวังในการใช้งานระบุไว้ว่า หากอัตราการใช้ดิสก์ที่ฝั่งเอนด์พอยต์การอนุมาน (Inference Endpoint) สูงขึ้น ควรหยุดการบันทึกข้อมูล (Capture) ไว้ชั่วคราว ดังนั้น คอลเลกชันไปป์ไลน์จึงจำเป็นต้องมีการรวมฟังก์ชันการลองใหม่ (Retry) เมื่อการเขียนล้มเหลว และการจัดการเพื่อสำรองข้อมูลเมื่อดิสก์เต็มเอาไว้ด้วย

เกณฑ์การตัดสิน: วิธีการนำบันทึก (Log) ที่รวมศูนย์แล้วไปใช้งาน คือปัจจัยชี้ขาดความสำเร็จของการดำเนินงานจริง

แม้จะรวมศูนย์ Log ไว้แล้ว แต่หากขาดการออกแบบการตรวจจับความผิดปกติและการทำ Visualization ผ่านแดชบอร์ด การตรวจสอบคุณภาพก็จะไม่สามารถทำงานได้ ในส่วนนี้จะอธิบายถึงวิธีการเฉพาะเจาะจงในการเชื่อมต่อข้อมูล Input/Output, Latency, ปริมาณการใช้ Token และเหตุการณ์ข้อผิดพลาด (Error events) ที่สะสมไว้ เข้ากับระบบ Query แบบเรียลไทม์และโครงสร้างพื้นฐานด้านการแสดงผลข้อมูล (Visualization)

สำหรับการตรวจจับความหน่วง (latency) ที่พุ่งสูงขึ้น การเฝ้าระวังด้วยค่าเปอร์เซ็นไทล์ผ่านการรวมข้อมูลแบบฮิสโตแกรม (histogram) จะมีประสิทธิภาพ ส่วนการตรวจจับความผิดปกติของปริมาณการใช้โทเค็น (token usage) ที่เบี่ยงเบนไปนั้น การเปรียบเทียบค่าเฉลี่ยเคลื่อนที่กับหน้าต่างเวลาล่าสุดจะเหมาะสมกว่า คิวรีตรวจจับความผิดปกติแบบเรียลไทม์ (real-time anomaly detection query) จะช่วยลดการแจ้งเตือนที่ผิดพลาดได้ง่ายขึ้นหากออกแบบโดยแยกทั้งสองระบบนี้ออกจากกัน

ในการเฝ้าระวังความหน่วง แนวทางปฏิบัติที่ดีที่สุดของ Prometheus ที่แนะนำให้ใช้ histogram แทน summary นั้นถือเป็นข้อมูลอ้างอิงที่ดี ข้อดีของฮิสโตแกรมคือการเก็บข้อมูลการกระจายตัวไว้ในแต่ละบัคเก็ต (bucket) ทำให้สามารถคำนวณค่าเปอร์เซ็นไทล์อย่าง p95 หรือ p99 ใหม่ได้อย่างยืดหยุ่นในภายหลัง ในฝั่งของคอนเวอร์จด์ดาต้าเบส (converged database) การออกแบบให้รวบรวมข้อมูลการกระจายตัวของความหน่วงในช่วงไม่กี่นาทีล่าสุดจากตารางอนุกรมเวลา (time-series table) และสั่งให้แจ้งเตือนเมื่อมีบัคเก็ตที่เกินเกณฑ์ต่อเนื่องกัน จะทำให้จัดการได้ง่ายขึ้น

สำหรับการตรวจจับความผิดปกติของปริมาณการใช้โทเค็น รูปแบบพื้นฐานคือการบันทึก prompt_tokens, completion_tokens และ total_tokens ที่อยู่ในออบเจกต์ usage ของ OpenAI API ลงในอนุกรมเวลา แล้วใช้คิวรีเพื่อดึงคำขอที่เบี่ยงเบนไปจากค่าเฉลี่ยล่าสุดเกินเกณฑ์ที่กำหนด นอกจากนี้ยังห้ามมองข้ามความสัมพันธ์กับ เหตุการณ์ข้อผิดพลาด (error event) ในกรณีที่ปริมาณการใช้โทเค็นพุ่งสูงขึ้นก่อนที่อัตราข้อผิดพลาดจะเพิ่มขึ้น สาเหตุอาจมาจากการที่พรอมต์ (prompt) ฝั่งอินพุตมีขนาดใหญ่เกินไป หากมีการกำหนดค่าที่สามารถเชื่อมโยงบันทึกอินพุต/เอาต์พุตเข้ากับเมทริกซ์ (metrics) ภายใต้ขอบเขตธุรกรรมเดียวกันได้ ก็จะช่วยลดจำนวนคิวรีที่ต้องทำซ้ำไปมาเพื่อระบุสาเหตุของปัญหาได้

การที่ทีมปฏิบัติการจะตีความค่าความผิดปกติที่ตรวจพบโดยคิวรีตรวจจับความผิดปกติ (Anomaly Detection Query) ได้อย่างไรนั้น ขึ้นอยู่กับคุณภาพของการออกแบบแดชบอร์ดเป็นสำคัญ แม้ว่าจะมีการรวมบันทึก (Log) ไว้แล้ว แต่หากขาดการแสดงผลด้วยภาพ (Visualization) ก็จะเกิดภาระงานในการอ่าน "สิ่งที่กำลังเกิดขึ้น" จากตัวเลขที่เรียงรายกันอยู่ ซึ่งมักจะทำให้การตอบสนองล่าช้า

ในแดชบอร์ด การจัดวางบันทึกขาเข้า-ขาออก, ค่าความหน่วง (Latency), ปริมาณการใช้โทเค็น (Token Usage) และเหตุการณ์ข้อผิดพลาด (Error Event) ไว้บนหน้าจอเดียวกันตามลำดับเวลา เพื่อให้สามารถตรวจสอบความสัมพันธ์ได้ในทันทีนั้นถือเป็นโครงสร้างที่มีประสิทธิภาพ ตัวอย่างเช่น หากแสดงผลแบบซ้อนทับกันว่าในช่วงเวลาที่ค่า p95 ของความหน่วงพุ่งสูงขึ้นนั้น มีรูปแบบของพรอมต์ (Prompt Pattern) หรือจำนวนโทเค็นที่ผิดปกติหรือไม่ จะช่วยให้จำกัดวงสาเหตุได้รวดเร็วยิ่งขึ้น หากเป็นฐานข้อมูลแบบคอนเวอร์จ (Converged Database) จะมีข้อได้เปรียบในการปฏิบัติงานคือ ไม่จำเป็นต้องดึงข้อมูลต่างประเภทเหล่านี้ด้วยคิวรีแยกกันแล้วนำมาเชื่อมโยงด้วยตนเอง แต่สามารถส่งผลลัพธ์จากคิวรีเดียวไปยังเครื่องมือแสดงผลข้อมูลได้โดยตรง

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

เราจะมาตอบคำถามที่ผู้ดูแลระบบมักสงสัยเกี่ยวกับการนำระบบจัดการรวมศูนย์บันทึกการอนุมาน (Inference Log) มาใช้งาน โดยแบ่งออกเป็น 3 ประเด็นหลัก ได้แก่ การเลือกฐานข้อมูล, ระยะเวลาในการย้ายข้อมูล (Migration), และการเพิ่มประสิทธิภาพด้านต้นทุน โปรดใช้ข้อมูลนี้เป็นส่วนประกอบในการตัดสินใจก่อนเริ่มใช้งานจริง

เกณฑ์การตัดสินใจ: สิ่งสำคัญคือการเลือกตามประเภทของบันทึก (Log) และคุณลักษณะของคิวรี (Query)

Converged Database หมายถึงผลิตภัณฑ์ที่สามารถจัดการข้อมูลประเภท "relational, document/JSON, graph, vector, spatial, text" ได้โดยตรงด้วยเอนจินเดียว หัวใจสำคัญของการเลือกคือความสามารถในการจัดการข้อมูลที่แตกต่างกัน เช่น โครงสร้าง JSON ของบันทึกอินพุต/เอาต์พุต, เมทริกซ์อนุกรมเวลา (Time-series metrics) เช่น ค่าความหน่วง (Latency) และปริมาณการใช้โทเค็น, รวมถึงการค้นหาความคล้ายคลึงด้วยเวกเตอร์ฝังตัว (Embedding vectors) ภายใต้ตัวปรับแต่งประสิทธิภาพ (Optimizer) เดียวและขอบเขตธุรกรรม (Transaction boundary) เดียวกัน

โดยเฉพาะอย่างยิ่ง หากมีคิวรีการรวมข้อมูล (Aggregation query) สำหรับเมทริกซ์อนุกรมเวลาจำนวนมาก โครงสร้างที่รวม PostgreSQL เข้ากับ TimescaleDB จะมีความเหมาะสม เนื่องจากสามารถจัดการการดำเนินการ JSON แบบรีเลชันและอนุกรมเวลาได้ด้วย SQL เดียวกัน ในทางกลับกัน หากเน้นไปที่คิวรีการวิเคราะห์ที่มีปริมาณงาน (Throughput) สูง และต้องการรวมบันทึกการอนุมาน (Inference logs) จำนวนมหาศาลในรูปแบบ Column-oriented แล้ว ClickHouse จะเป็นตัวเลือกที่เหมาะสมกว่า

ไม่ว่าในกรณีใด การตัดสินใจจะไม่ผิดพลาดหากใช้เกณฑ์ 3 ประการ ได้แก่ ความถี่ของคิวรีแบบผสมที่รวมถึงการค้นหาเวกเตอร์, ภาษาคิวรีที่ทีมปฏิบัติการเดิมมีความเชี่ยวชาญ และปริมาณของบันทึกที่ต้องตรวจสอบ หากมีการใช้งาน Vector Database แยกต่างหาก ควรจำกัดขอบเขตการบูรณาการไว้ที่ชั้นการจัดการบันทึก และกำหนดบทบาทให้ชัดเจนตามแนวคิดการเพิ่มประสิทธิภาพการค้นหาที่อธิบายไว้ใน Adaptive RAG คืออะไร? วิธีสร้างสมดุลระหว่างต้นทุนและความแม่นยำด้วยการค้นหาแบบไดนามิกที่ขับเคลื่อนด้วยคิวรี เพื่อหลีกเลี่ยงความซับซ้อนในการดำเนินงาน

หากขนาดของบันทึกข้อมูล (log) เดิมมีขนาดเล็ก จะต้องใช้เวลาประมาณสองสามสัปดาห์ แต่หากมีบันทึกข้อมูลแบบกระจายขนาดใหญ่ จะต้องเผื่อเวลาไว้เป็นหน่วยเดือน ระยะเวลาในการย้ายข้อมูลนั้นคล้ายกับการ "ย้ายบ้าน" ซึ่งปริมาณงานจะเปลี่ยนไปอย่างมาก ไม่เพียงแค่ขึ้นอยู่กับปริมาณของสัมภาระ (ข้อมูล log) เท่านั้น แต่ยังขึ้นอยู่กับความเข้ากันได้ของระบบสายไฟ (รูปแบบข้อมูลและโครงสร้างคิวรี) ระหว่างที่พักเดิมและที่พักใหม่ด้วย

งานย้ายข้อมูลแบ่งออกเป็น 3 ขั้นตอนหลัก ได้แก่ การตรวจสอบสคีมาของ log เดิมและการออกแบบการแมปข้อมูล ตามด้วยการตรวจสอบความถูกต้องของข้อมูลผ่านการทำงานแบบขนาน และสุดท้ายคือการหยุดระบบเดิมทีละขั้นตอน หากประเมิน ระยะเวลาการทำงานแบบขนาน (parallel operation period) สั้นเกินไป มักจะเกิดกรณีที่เกณฑ์การตรวจจับความผิดปกติคลาดเคลื่อนหลังจากการย้ายข้อมูลเสร็จสิ้น ทำให้เกิดการแจ้งเตือนที่ผิดพลาดเพิ่มมากขึ้น

ปัจจัยที่มีผลต่อระยะเวลาในการย้ายข้อมูลมีดังนี้:

• ความหลากหลายของรูปแบบ log (เช่น JSON, CSV, ไบนารีเฉพาะตัว ฯลฯ ซึ่งแปรผันตามจำนวนตรรกะการแปลงข้อมูล)
• จำนวนการกระจายตัวของพื้นที่จัดเก็บข้อมูลเดิม (ยิ่งมีการแยก S3, RDB และเครื่องมือตรวจสอบแยกจากกัน การปรับจูนการทำงานแบบขนานจะยิ่งซับซ้อนขึ้น)
• ความจำเป็นในการเรียนรู้ใหม่ของ โมเดลตรวจจับความคลาดเคลื่อน (drift detection model) (เนื่องจากการกระจายตัวของข้อมูลหลังการรวมระบบเปลี่ยนไป จึงมักเกิดการปรับจูนใหม่)

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

การสร้างสมดุลระหว่างระยะเวลาการจัดเก็บและต้นทุนเป็นส่วนที่การตัดสินใจแบบแยกส่วน (branching decision) มีประสิทธิภาพ โดยมีแนวทางพื้นฐานคือการจัดเก็บล็อกที่ต้องเรียกดูบ่อยเพื่อการตรวจจับความผิดปกติ (anomaly detection) หรือการตรวจสอบ (audit) ไว้ในชั้นที่เข้าถึงได้รวดเร็ว และย้ายล็อกเก่าที่ความถี่ในการเรียกดูต่ำลงไปยังชั้นที่มีต้นทุนต่ำกว่าตามลำดับ

เกณฑ์การตัดสินใจจะแตกต่างกันไปตามวัตถุประสงค์การใช้งาน แนวทางที่ใช้งานได้จริงคือการเก็บล็อกการอนุมาน (inference logs) ของช่วงไม่กี่สัปดาห์ล่าสุดไว้ในชั้นที่รวดเร็ว เนื่องจากต้องเรียกดูเป็นประจำเพื่อการตรวจจับความผิดปกติหรือการตรวจจับการเบี่ยงเบน (drift detection) ส่วนล็อกก่อนหน้านั้นให้เก็บเฉพาะสรุปทางสถิติ (statistical summary) และบีบอัดหรือเก็บถาวร (archive) ล็อกดิบ (raw logs) ไว้ ทั้งนี้ต้องระวังว่าหากใช้หลักเกณฑ์การจัดเก็บเดียวกันสำหรับล็อกที่ต้องเก็บระยะยาวเพื่อปฏิบัติตามกฎระเบียบ กับล็อกระยะสั้นที่ใช้เพื่อปรับปรุงประสิทธิภาพเพียงอย่างเดียว จะทำให้ต้นทุนเพิ่มขึ้นโดยไม่จำเป็น

สำหรับ OpenAI Responses API นั้นมีข้อกำหนดให้จัดเก็บสถานะของแอปพลิเคชันไว้เป็นเวลา 30 วันโดยค่าเริ่มต้น จึงควรหลีกเลี่ยงการออกแบบการตรวจจับความผิดปกติที่ต้องพึ่งพาข้อมูลหลังจากช่วงเวลานี้ หากมีการจัดการล็อกแบบรวมศูนย์ด้วยตนเอง ควรพิจารณาเกณฑ์ระยะเวลาการจัดเก็บที่คล้ายคลึงกันนี้ โดยการแยกการวิเคราะห์ระยะสั้นที่เสร็จสิ้นภายใน 30 วัน ออกจากการวิเคราะห์ระยะยาวที่ต้องเก็บข้อมูลไว้นานกว่านั้นตั้งแต่ขั้นตอนการออกแบบ จะช่วยลดต้นทุนในการออกแบบใหม่ในภายหลังได้

ในการเพิ่มประสิทธิภาพด้านต้นทุน การทบทวนความสัมพันธ์ระหว่างอัตราการบีบอัดของล็อกดิบและความถี่ในการคิวรี (query frequency) อย่างสม่ำเสมอเป็นสิ่งที่ขาดไม่ได้ แม้การขยายระยะเวลาการจัดเก็บจะช่วยเพิ่มความสามารถในการรองรับการตรวจสอบ แต่เนื่องจากเกิดการแลกเปลี่ยน (trade-off) ระหว่างต้นทุนการจัดเก็บและประสิทธิภาพในการค้นหา จึงจำเป็นต้องมีการดำเนินงานที่ปรับเปลี่ยนเกณฑ์ (threshold) ตามความต้องการทางธุรกิจ