<div class="key-takeaways"><ul><li>LLM ทำงานด้วยการคาดเดาจากบริบท ทำให้คำตอบอาจเปลี่ยนไปหรือผิดเพี้ยนได้แม้ใช้พรอมต์เดิม</li><li>เหตุการณ์ใน staging แสดงให้เห็นว่าโมเดลที่เคยใช้งานได้ปกติกลับส่งออกข้อมูลจำลองอย่าง Vendor A และ Vendor B ออกมาดื้อๆ</li><li>การตรวจสอบแบ่งออกเป็นโครงสร้าง (Schema) และความหมาย (Semantic) ซึ่งอย่างหลังต้องใช้โมเดลช่วยตรวจสอบอีกชั้น</li><li>การทำ validation ตั้งแต่วันแรกช่วยป้องกันปัญหาผลลัพธ์พังและคุ้มค่ากว่าการรอใส่ทีหลัง</li></ul></div><p>ในวงจรการพัฒนาซอฟต์แวร์แบบดั้งเดิมหรือ SDLC งานตรวจสอบคุณภาพหรือ QA มักเป็นหน้าที่ของทีมอื่นและเกิดขึ้นในช่วงท้ายของโปรเจกต์ ทีม QA จะคอยตรวจว่าซอฟต์แวร์ทำงานได้ตามที่ออกแบบไว้หรือไม่ พฤติกรรมของระบบมีความสม่ำเสมอจนสามารถเขียนสคริปต์อัตโนมัติเพื่อทดสอบซ้ำๆ ได้ก่อนจะส่งมอบงานต่อไป แต่วิธีการเหล่านี้พังทลายลงทันทีเมื่อระบบเริ่มมีโมเดลภาษาขนาดใหญ่หรือ LLM เข้ามาเกี่ยวข้อง</p><p>ระหว่างการพัฒนาแอปพลิเคชัน Slooster ผู้พัฒนาเลือกที่จะทำส่วนยากๆ ก่อน และคิดว่าชั้นตรวจสอบข้อมูลหรือ validation layer สามารถรอไว้ก่อนได้เนื่องจากระบบทดสอบในเครื่องทำงานได้เป็นอย่างดี แต่ความจริงก็คือ LLM สร้างผลลัพธ์จากการคาดเดาตามบริบท แม้เทคโนโลยีจะเก่งขึ้นเรื่อยๆ แต่มันก็ยังเป็นการคาดเดาอยู่ดี พรอมต์เดิมในเวลาที่ต่างออกไปอาจให้คำตอบที่เพี้ยนหรือผิดพลาดได้โดยที่ไม่มีอะไรเปลี่ยนแปลงเลย การตรวจสอบจึงต้องฝังอยู่ในตัวซอฟต์แวร์ตั้งแต่วันแรกที่สร้างระบบเพื่อรองรับความไม่แน่นอนนี้</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_msceqr1i_inline_1_3058ef8c38.jpg" alt="software staging dashboard developer interface" loading="lazy" /><p class="color-gray-500 text-sm mt-10">ภาพประกอบจากคลังภาพสต็อก ไม่ใช่ภาพจากเหตุการณ์จริง</p></div><p>เหตุการณ์ช็อกในสภาพแวดล้อม staging เกิดขึ้นเมื่อนำ Slooster Guide ไปทดสอบก่อนสาธิตให้ผู้ร่วมก่อตั้งดู พรอมต์และโมเดลชุดเดิมที่เคยให้ข้อมูลผู้ขายตรงตามเกณฑ์มานานนับสัปดาห์ กลับส่งข้อมูลจำลองอย่างคำว่า Vendor A, Vendor B และ Vendor C ออกมาแทน และเมื่อสั่งให้ระบบสร้างคำตอบใหม่ ก็ได้ Vendor D หลุดเข้ามาผสมด้วย เหตุการณ์นี้พิสูจน์ให้เห็นว่าโมเดลที่ทำงานได้สะอาดเรียบร้อยในเครื่องนานหลายสัปดาห์ยังคงพ่นขยะออกมาได้จริงเมื่อใช้งานจริง และการทดสอบก่อนส่งมอบล่วงหน้าไม่สามารถป้องกันปัญหานี้ได้เลย นี่คือเหตุผลหลักที่ต้องตรวจสอบแบบ inline บนทุกผลลัพธ์จริง ไม่ใช่แค่ตรวจครั้งเดียวก่อนปล่อยของ</p><div class="ai-insight"><p>การนำ LLM มาใช้งานจริงบนระบบโปรดักชันมักเผชิญกับความท้าทายเรื่อง Non-determinism หรือความไม่แน่นอนของผลลัพธ์ ซึ่งแตกต่างจากโค้ดทั่วไปที่ใส่ค่าเท่าเดิมต้องได้ผลลัพธ์เดิมเสมอ การที่นักพัฒนาต้องสร้างระบบตรวจสอบซ้อนระบบอีกชั้น (Model-grading-model) จึงกลายเป็นแนวปฏิบัติใหม่ที่สำคัญในการันตีความถูกต้องของข้อมูลก่อนแสดงผลสู่ผู้ใช้งานจริง</p></div><p>ผู้พัฒนาได้เพิ่มชั้นตรวจสอบข้อมูลพร้อมระบบลองใหม่ (retries) เมื่อเจอผลลัพธ์ที่ไม่ผ่านเกณฑ์ ระบบจะเรียกใช้งานซ้ำทันที แต่การทำ retry มีต้นทุนด้านเวลาและแอปพลิเคชันยังต้องตอบสนองได้รวดเร็วขณะที่ผู้ใช้งานรอดำเนินการ การตรวจสอบจึงไม่ใช่เรื่องฟรีและไม่มีสูตรสำเร็จตายตัว ตำแหน่งที่รัน จำนวนครั้งที่ลองซ้ำ และการให้มนุษย์เข้ามาตรวจสอบ (Human-in-the-loop) ล้วนขึ้นอยู่กับลักษณะการใช้งานของแต่ละระบบ</p><p>กระบวนการตรวจสอบแบ่งออกเป็นสองระดับหลัก:</p><ul><li>การตรวจสอบเชิงโครงสร้าง (Deterministic checks): ใช้ตัวตรวจสอบ Schema เพื่อปฏิเสธข้อมูลที่โครงสร้างผิดเพี้ยน</li><li>การตรวจสอบเชิงความหมาย (Semantic checks): ใช้โมเดลตรวจทานโมเดลอีกทีเพื่อจับข้อมูลจำลองหรือข้อความฟิลเลอร์ทั่วไปที่ผ่านเกณฑ์โครงสร้างแต่ใช้การไม่ได้</li></ul><p class="source-attribution">ที่มา: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/smukker/lesson-4-validation-a-must-have-cornerstone-3bd2" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

<div class="key-takeaways"><ul><li>LLMs generate outputs by guessing based on context, meaning the exact same prompt can yield different or incorrect answers.</li><li>A staging deployment revealed that a stable model suddenly started spitting out raw placeholders like Vendor A and Vendor B.</li><li>Validation requires both structural schema checks and semantic model-graded evaluations to catch dummy data.</li><li>Building a validation layer from day one prevents broken outputs and is far more cost-effective than adding it later.</li></ul></div><p>In a traditional software development life cycle, validation was handled by someone else later in the process. QA teams verified that the software behaved as expected, and because behaviors were repeatable, teams eventually automated those checks and moved on. However, that traditional model breaks down the exact moment an LLM enters the picture.</p><p>While building Slooster, the developer tackled the hard parts first and assumed the validation layer could wait because everything worked locally. Unfortunately, LLMs produce outputs by guessing based on context. While they are improving, they are still guessing, meaning the same prompt can produce a different or incorrect response next time with zero changes made. As a result, validation must be embedded directly into the software.</p><div class="mb-20"><img class="img-bdrd-16" src="https://api.inewgen.co/uploads/ai_msceqr1i_inline_1_3058ef8c38.jpg" alt="software staging dashboard developer interface" loading="lazy" /><p class="color-gray-500 text-sm mt-10">Stock photo for illustration only, not from the actual event</p></div><p>The reality check struck after deploying Slooster Guide to staging right before a demo with co-founders. The exact same prompts, models, and configurations that had successfully returned real, criteria-matched vendors for weeks suddenly outputted placeholder data literally reading Vendor A, Vendor B, and Vendor C. Regenerating simply brought Vendor D into the mix. A model providing clean local outputs for weeks can still hand over garbage during a real call, proving why inline validation on every actual output is essential instead of a one-time check before shipping.</p><div class="ai-insight"><p>Deploying LLMs to production often exposes developers to non-determinism, a stark contrast to standard code where identical inputs guarantee identical outputs. Implementing a secondary validation gate where a model evaluates another model's output has quickly become an essential industry pattern for safeguarding AI-driven applications before end-users ever see the response.</p><p>Adding a validation layer with built-in retries catches bad outputs, but retries consume time while users wait, meaning validation incurs costs and lacks a one-stop solution. Where it runs and how aggressively it retries depend heavily on the specific use case.</p><p>The validation pipeline splits into distinct gates:</p><ul><li>Deterministic checks: Schema validators immediately reject structurally off-spec data.</li><li>Semantic checks: A secondary model reviews the response against the original criteria to flag placeholders, generic filler, or example data that passed schema checks.</li></ul><p class="source-attribution">Source: <img src="https://www.google.com/s2/favicons?domain=dev.to&sz=64" alt="Dev.to" class="source-logo" width="16" height="16" /> <a href="https://dev.to/smukker/lesson-4-validation-a-must-have-cornerstone-3bd2" target="_blank" rel="noopener noreferrer">Dev.to</a></p>

large_article-1286.jpg

medium_article-1286.jpg

small_article-1286.jpg

thumbnail_article-1286.jpg

Inewgen

Inewgen

#AI Validation

Why AI Validation Must Be Your Core Foundation From Day One

Inewgen