การค้นหาเนื้อหาในไฟล์ และการให้ AI ตอบคำถามจากไฟล์ จาก Ctrl + F สู่ระบบค้นหาข้อมูลในยุค AI

มีปัญหาในชีวิตการทำงานของสาย Tech และผมเชื่อว่า คนทำงานสายอื่นๆแทบทุกคนน่าจะเคยเจอครับ

เรารู้ว่าข้อมูลนี้มีอยู่แน่ๆ แต่จำไม่ได้ว่ามันอยู่ไฟล์ไหน ย่อหน้าไหน หรือบรรทัดไหน

ถ้ามีไฟล์เดียว เราก็กด Ctrl + F แล้วพิมพ์คำที่จำได้ แต่พอเอกสารกระจายอยู่หลายโฟลเดอร์ มีทั้ง PDF, Word, คู่มือ และบันทึกประชุม เรื่องที่ดูง่ายก็เริ่มวุ่นวายขึ้นทันที

ปัจจุบันเราขยับไปไกลกว่าการค้นชื่อไฟล์แล้ว เราสามารถถามระบบด้วยประโยคธรรมดาว่า “สัญญาฉบับนี้กำหนดค่าปรับล่าช้าไว้อย่างไร?” แล้วคาดหวังให้ AI ไปค้นข้อความที่เกี่ยวข้อง ก่อนสรุปคำตอบกลับมาพร้อมแหล่งอ้างอิง

เบื้องหลังประสบการณ์นี้ไม่ได้มีแค่ LLM ครับ มันเกิดจากเทคโนโลยีค้นหาและดึงข้อมูลหลายชั้นที่ทำงานคนละหน้าที่

TL;DR

ระบบค้นหาหลักๆ มองโจทย์ต่างกันแบบนี้

• Linear scan เปิดอ่านเนื้อหาแล้วเทียบตัวอักษรโดยตรง เหมาะกับข้อมูลไม่มากและความสดใหม่(ค้นหาจากเนื้อหาตรงๆ)
• Inverted index เตรียมดัชนีของคำต่างๆไว้ล่วงหน้า เวลาค้นหาก็ไปค้นหาที่ดัชนี ทำให้ค้นคำที่ตรงกันได้เร็วโดยไม่ต้องไล่อ่านทุกไฟล์ตอนค้น
• Semantic vector search ใช้วิธีเปรียบเทียบความใกล้เคียงของความหมาย (แปลงข้อความเป็น ชุดตัวเลข แล้วใช้สมการคณิตศาสตร์ เทียบความใกล้เคียง) ช่วยเมื่อคำถามกับเอกสารใช้คำไม่เหมือนกัน
• Retrieval + LLM ค้นท่อนข้อมูลที่เกี่ยวข้องก่อน แล้วให้โมเดล LLM เรียบเรียงเป็นคำตอบ

ไม่มีวิธีไหนดีที่สุด การค้นหาด้วย Keyword ยังมีประโยชน์มากกับรหัสเฉพาะ ส่วน Vector (วิธีค้นหาด้วยความหมายด้วย model) ช่วยเรื่องภาษาธรรมชาติ ระบบที่ใช้งานจริงจึงอาจต้องผสมหลายวิธีและประเมินผลกับข้อมูลของตัวเอง

มนุษย์อ่านความหมาย แต่คอมพิวเตอร์อ่านจากตัวอักษร

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

แต่ในระดับ Low-Level คอมพิวเตอร์รู้เพียงลำดับตัวอักษรหรือไบต์ มันไม่ได้เชื่อมโยงแนวคิดเหล่านั้นแบบมนุษย์โดยอัตโนมัติ

ดังนั้นทำให้การค้นหาแบ่งเป็นสองแนวทางใหญ่ๆ

1. Lexical search สนใจคำ รูปคำ และตัวสะกด (เทียบด้วยคำตรงๆ)
2. Semantic search ใช้แบบจำลองทางคณิตศาสตร์เพื่อเปรียบเทียบรูปแบบของความหมายและบริบท ของประโยคหรือคำเหล่านั้น

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

เปิดไฟล์ แล้วค้นหาจาก keyword

Ctrl + F และ grep เป็นภาพของ Linear scan ที่เข้าใจง่ายที่สุด

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

Trade-off คือปริมาณงานเพิ่มตามขนาดข้อมูล เมื่อมีไฟล์จำนวนมาก หรือไฟล์มีขนาดใหญ่มาก การเปิดและตรวจทุกไฟล์ทุกครั้งย่อมใช้ทั้งเวลา, CPU และ I/O มากขึ้น

แต่ Linear scan ก็ไม่ได้ล้าสมัย แต่มันจะเหมาะมากกับงานบางประเภท เช่น หาเลขใบเสร็จ, หาชื่อ ค้นในไฟล์เดียว, ตรวจ Log ขนาดเล็ก หรือค้นข้อมูลขนาดที่ไม่ได้ใหญ่มาก ที่ยังไม่คุ้มจะสร้างดัชนี หรือทำ index

Inverted index: ทำดัชนี(index)ไว้ก่อน พอค้นหาค่อยเปิดดูจากดัชนีนั้น

ถ้ามีเอกสารจำนวนมาก หรือไฟล์มีขนาดใหญ่มาก เราไม่อยากเริ่มอ่านใหม่ทุกครั้งที่มีการค้นหา ระบบ Search Engine จึงเตรียม Inverted index ไว้ล่วงหน้า

แนวคิดคล้ายดัชนีในส่วนท้ายของหนังสือครับ แทนที่จะอ่านตำราทุกหน้าเพื่อหาคำว่า “ลาป่วย” เราเปิดดัชนีแล้วดูว่าคำนี้อยู่ในเอกสารหน้าไหน และย่อหน้าใดบ้าง (ไม่เหมือนสารบัญนะครับ ที่สารบัญบอกว่าเรื่องนี้ หัวข้อนี้อยู่ที่หน้าไหน แต่ดัชนีจะบอกว่า คำนี้อยู่หน้าไหนบ้าง)

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

ข้อเสียคือ เราต้องมี Indexing pipeline ถ้าเอกสารเปลี่ยนเนื้อหาไปแล้ว แนานอนว่าดัชนียังไม่อัปเดตทันที ผลค้นหาอาจยังไม่เห็นเนื้อหาใหม่ หรือยังพาไปหาเอกสารเก่า จึงต้องรอการทำ Indexing pipeline จนเสร็จก่อนครับ ถึงจะ update ตรงกับเนื้อหาใหม่

บางกรณี Keyword ก็หาไม่เจอ

Lexical search เก่งมากเมื่อคำที่ User พิมพ์ตรงกับข้อความในเอกสาร แต่ภาษาของคน ที่มีความหมายเดียวกันไม่ได้ใช้คำเดียวกันตลอด

สมมติเอกสารเขียนว่า

ระเบียบการหยุดงานเพื่อรักษาตัว

แต่พนักงานค้นว่า

วิธีลาป่วย

ความหมายแทบจะเหมือนกัน แต่ตัวสะกดต่างกัน ระบบที่ต้องค้นหาด้วยคำตรงๆ อาจให้คะแนนต่ำหรือไม่เจอเลย

ยังมีปัญหาอื่นอีก เช่น

• คำเดียวมีหลายความหมายตามบริบท (เช่นคำว่า "สูง" ใน ราคาสูง กับคนตัวสูง)
• User พิมพ์ผิด
• User ถามเป็นประโยคธรรมชาติ แต่เอกสารเขียนเป็นภาษาทางการ
• คนเขียนกับคนค้นใช้ศัพท์คนละชุด

ระบบ Lexical ที่ดีมีเครื่องมือช่วยได้ เช่น การจัดรูปคำ, synonym, fuzzy matching และการให้คะแนนแบบ BM25 แต่มันยังเริ่มต้นจาก คำที่ใกล้เคียงกันอยู่ดี

Semantic search: เปลี่ยนข้อความเป็นพิกัด

Text embedding คือการแปลงข้อความให้เป็นชุดตัวเลข หรือ Vector เพื่อให้ระบบเปรียบเทียบความใกล้เคียงได้

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

ในตอนที่ผมทดลอง ผมลองทำ Vector Embedding ครั้งแรกด้วย BAAI/bge-m3 ผมจงใจใช้คำ ในการค้นหา กับข้อมูลที่สะกดไม่เหมือนกัน และบางทีก็ลองใช้คนละภาษา จากนั้นดูผลลัพธ์ ซึ่งผลที่ได้ คือข้อความที่มีความหมายใกล้กัน ถูกดึงขึ้นมาอันดับแรกๆ ได้ แม้ไม่ได้ใช้คำเดียวกันเลยครับ

การทดลองนี้ ขึ้นอยู่กับ Model, ภาษา, Test data แต่สิ่งที่ทำให้ผมเห็นชัดคือ การ Search ไม่จำเป็นต้องยึดติดกับตัวสะกดเพียงอย่างเดียว นั่นเอง

แล้วทำไมไม่แปลง PDF ทั้งเล่มเป็น Vector หรือ หน้าทั้งหน้า เป็น Vector เดียว

ถ้า Vector เก็บความหมายได้ เราอาจคิดว่าเอา PDF ทั้งหน้า หรือหนึ่งร้อยหน้าไปสร้าง Vector เดียวก็น่าจะจบ

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

ผมขอเปรียบเทียบกับการเอาผลไม้หลายชนิดไปปั่นรวมกันครับ เราอาจได้รสชาดที่บอกว่าได้ว่าเป็นน้ำผลไม้ แต่รสเฉพาะของผลไม้บางชนิดอาจเจือจางหรือเพี้ยนไป

ระบบจึงแบ่งเอกสารเป็น Chunk หรือท่อนย่อยๆ ก่อนสร้าง Embedding ขนาดและจุดตัดของ Chunk ไม่ได้มีค่าตายตัว ต้องดูโครงสร้างภาษา, ประเภทเอกสาร, คำถามที่คาดว่าจะเจอ และผลการประเมินจริง

Chunk เล็กเกินไปอาจขาดบริบท ส่วน Chunk ใหญ่เกินไปอาจมีหลายประเด็นปนกัน นี่จึงเป็นศิลปะงานออกแบบ อย่างนึง ไม่ใช่แค่ตั้งตัวเลขครั้งเดียวแล้วจบ

การค้นหาเจอ กับ ตอบคำถามได้ เป็นคนละงานกัน

Search หรือ Retrieval มีหน้าที่ชี้ว่า “ข้อมูลที่น่าจะเกี่ยวข้องอยู่ตรงไหน” แต่ผู้ใช้ก็ไม่ได้ต้องการ ลิงก์ หรือ list ไปยังข้อความนั้นๆเสมอไป เขาต้องการคำตอบที่อ่านรู้เรื่อง

ตรงนี้เอง ที่ทำให้ Retrieval ทำงานร่วมกับ LLM เป็น Flow พื้นฐานที่ลื่นไหล มีสามขั้นตอน ดังนี้

1. Retrieval: รับคำถามแล้วค้นหาประโยค หรือก้อนของข้อมูลที่เกี่ยวข้อง
2. Context augmentation: นำคำถาม, คำสั่ง และก้อนของข้อมูลที่ค้นเจอมาจัดเป็น Context
3. Generation: ให้ LLM อ่าน Context แล้วเรียบเรียงคำตอบ

ถ้าระบบเก็บ Metadata และตำแหน่งอ้างอิงไว้ดีพอ คำตอบยังสามารถ อ้างอิงกลับไปตรวจข้อความต้นทางได้ด้วย

แต่ LLM ไม่ได้ทำให้ข้อมูลต้นทางถูกต้องขึ้น และถ้า Retrieval หยิบผิด Chunk หรือการแบ่งชุดประโยค หรือ แบ่งก้อนของข้อมูลwม่ดีพอ, เอกสารล้าสมัย หรือ Context ขาดเงื่อนไขสำคัญ คำตอบก็ผิดได้เหมือนเดิม ระบบที่ดีจึงควรกล้าตอบว่า “ไม่มีข้อมูลเพียงพอ” เมื่อหลักฐานไม่พอหรือ หลักฐานไม่ชัด แทนที่จะตอบมโน หรือแต่งประโยคเอาเอง

Keyword หรือ Vector ควรเลือกอะไรดี ?

คำตอบคือ ขึ้นอยู่กับข้อมูลและคำถามครับ

Keyword search เหมาะมากเมื่อเราต้องหา

• รหัสสินค้า เช่น NK-9920-X
• เลขเอกสาร
• ชื่อเฉพาะ
• คำที่ต้องตรงตามต้นฉบับ หรือคำที่ต้องตรงบางส่วน

Vector search เหมาะกับ

• ถามด้วยภาษาธรรมชาติ
• ใช้คำพ้องกับเอกสาร
• จำข้อความจริงๆ ไม่ได้
• ต้องการค้นตามแนวความคิดมากกว่าตัวสะกด

หลายระบบจึงใช้ Hybrid search รวมสัญญาณจาก Keyword กับ Vector แล้วอาจมีขั้นตอนการจัดอันดับซ้ำอีกรอบ เพื่อไม่ให้หลุด และยังค้นหาด้วยคำต่างจากเอกสารได้

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

ก่อนเชื่อมต่อกับ LLM ให้ลองตอบคำถามเรื่อง Search ให้ได้ก่อน

ระบบถามตอบจากเอกสารที่ดี ควรเริ่มจากคำถามเหล่านี้ก่อน

1. ข้อมูลต้นทางคืออะไร และไฟล์ไหนเป็นฉบับล่าสุด
2. ผู้ใช้ค้นด้วยรหัสเฉพาะหรือภาษาธรรมชาติมากกว่ากัน
3. เอกสารควรถูกแบ่งเป็น Chunk ตรงไหน
4. เมื่อเอกสารเปลี่ยน ดัชนีจะอัปเดตอย่างไร
5. เราจะรู้ได้อย่างไรว่า Retrieval หยิบข้อมูลที่ถูกต้อง
6. คำตอบพาคนกลับไปตรวจ Source ได้หรือไม่
7. ถ้าหาไม่เจอ ระบบยอมรับว่าไม่มีข้อมูลได้หรือเปล่า

สำหรับผม แก่นของระบบตอบคำถามจากไฟล์ไม่ได้เริ่มจากการถามว่า LLM ตัวไหนเก่งที่สุดเพียงอย่างเดียว แต่เริ่มจากการเลือกวิธีค้นให้เหมาะกับข้อมูล แล้วส่งหลักฐานที่มีคุณภาพมากพอให้โมเดลอ่าน

และนี่เป็นส่วนหนึ่งของกรอบคิดที่ผมกำลังใช้ในแนวทางการ Search และ Retrieval สำหรับ Platfrom NEXT4I ในระดับ Concept ที่กำลังดำเนินการพัฒนาอยู่ครับ

เพราะก่อนที่ AI จะตอบได้ดี เราต้องช่วยให้มันได้ค้นหาเจอหน้าที่ควรอ่าน และข้อมูลที่ควรจะเจอให้ได้ก่อนนั่นเองครับ