โดยMalvina MatlisและMarcos Calvo Lance

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

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

การประเมินระบบ IR

การประเมินระบบ IR ได้รับการศึกษาและจัดทำเป็นเอกสาร อย่างกว้างขวาง ซึ่งหมายความว่ามีการกำหนดเมตริกมาตรฐานสองสามรายการ สามารถดูภาพรวมที่ดีได้ที่เมตริกการประเมินสำหรับการดึงข้อมูล
ตัวอย่างเช่น เมตริกมาตรฐานบางส่วนได้แก่:

ความแม่นยำ
จะวัดสัดส่วนของผลลัพธ์ที่ส่งคืนโดยระบบที่เกี่ยวข้องกับข้อความค้นหา (เช่น ข้อความค้นหา) ตัวอย่างเช่น ในภาพด้านบน เราค้นหาสูตรของปาเอยาแท้ๆ เสิร์ชเอ็นจิ้นดึงเอกสาร 330 ล้านฉบับ หากเรามีข้อมูลอ้างอิงที่ระบุว่าเอกสารดังกล่าว 200 ล้านฉบับเกี่ยวข้องกับการค้นหาสูตรอาหาร ความแม่นยำในการสืบค้นจะเท่ากับ 200/330 = 60.6%

Recall
วัดสัดส่วนของผลลัพธ์ที่เกี่ยวข้องที่ระบบส่งคืนจากชุดของผลลัพธ์ที่เกี่ยวข้องทั้งหมด กลับไปที่ตัวอย่างของเรา จะเกิดอะไรขึ้นหากเครื่องมือค้นหาพลาดเอกสารที่เกี่ยวข้อง 20 ล้านฉบับ จากนั้นการเรียกคืนจะเป็น 200/(200+20) = 90.9%

การจัดอันดับซึ่งกันและกัน (RR)
เป็นการวัดตำแหน่งในรายการผลลัพธ์ที่ส่งคืนเป็นเอกสารที่เกี่ยวข้องรายการแรก เนื่องจากสะดวกที่จะมีเมตริกที่มีค่าตั้งแต่ 0 ถึง 1 โดยที่ 1 แสดงถึงคะแนนที่ดีกว่า 0 การจัดอันดับซึ่งกันและกันจึงถูกกำหนดให้เป็น 1 เหนือดัชนีสูงสุดของเอกสารที่เกี่ยวข้องกับข้อความค้นหา ในการวัดค่านี้บนชุดของข้อความค้นหา เราเพียงแค่หาค่าเฉลี่ยของการจัดอันดับซึ่งกันและกันของชุดข้อความค้นหา โดยได้รับการจัดอันดับเฉลี่ย (Mean Reciprocal Ranking - MRR) หรือในรูปแบบสมการ:

เนื่องจากเรายังคงหิวอยู่และยังไม่ได้ทำสูตรอาหารมากกว่า 330 ล้านสูตร RR จะดูเอกสารฉบับแรกที่เราทำเครื่องหมายว่าเกี่ยวข้อง สมมติว่าเป็นสูตรที่ 5 แล้ว RR สำหรับข้อความค้นหาจะเป็น 1/5

พูดง่ายกว่าทำ

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

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

1. ป้อนข้อความค้นหา:ผู้ใช้ป้อนข้อความค้นหา (“สูตรพาสต้าแท้” ในตัวอย่างของเรา) ลงในแอปพลิเคชัน ซึ่งจะถูกส่งผ่านไปยังเครื่องมือค้นหา
2. การเรียกดูเอกสาร:ระบบจะส่งคืนรายการเอกสาร และแอปพลิเคชันจะแสดงเอกสารเหล่านั้นโดยเรียงลำดับตามความเกี่ยวข้อง
3. การตรวจสอบเอกสาร:ผู้ใช้เรียกดูเอกสารที่ส่งคืนตามลำดับ และเลือกเอกสารเพื่อตรวจสอบเพิ่มเติม
4. สำเร็จ:หากผู้ใช้พอใจกับเอกสารที่ตรวจสอบ พวกเขาสามารถแจ้งแอปพลิเคชันว่าการค้นหาเสร็จสิ้น ทางเลือกหนึ่งคือการให้คะแนนผลลัพธ์ในเชิงบวก อีกวิธีหนึ่งคือการใช้วิธีตัวแทนเพื่ออนุมานว่าการค้นหาสำเร็จ เช่น การวัดเวลาที่ผู้ใช้ใช้ในการตรวจสอบเอกสาร
5. หากผู้ใช้ไม่พอใจกับเอกสารที่ตรวจสอบ ผู้ใช้จะกลับไปเรียกดูผลลัพธ์ (จุดที่ 4) และอาจเลือกเอกสารใหม่เพื่อตรวจสอบ

Kusto เพื่อช่วยเหลือ

กลไกการสังเกต เช่น การบันทึกจะสร้างข้อมูลจำนวนมาก ซึ่งสร้างความท้าทายเพิ่มเติมในการสืบค้น

สามารถตรวจสอบบันทึกได้ในพอร์ทัล Azure AppInsights โดยใช้Azure Data Explorerและโดยเฉพาะภาษาคิวรี ของ Kusto หากคุณคุ้นเคยกับ SQL คุณจะรู้จักจุดร่วมบางประการในภาษานี้ อย่างไรก็ตาม มีความแตกต่างอย่างมีนัยสำคัญระหว่าง Kusto และ SQL — ใน Kusto คำสั่งจะถูกดำเนินการตามลำดับ ทำให้การสืบค้นสั้นลงและอ่านง่ายขึ้นกว่าการสืบค้น SQL

เมตริกการประเมินโดยใช้การบันทึกเหตุการณ์ของผู้ใช้

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

อันดับเฉลี่ยซึ่งกันและกัน (MRR)

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

จากนั้นสามารถคำนวณ MRR ได้โดยการหาค่าเฉลี่ย RR ในช่วงระยะเวลาที่มีความหมาย เช่น หนึ่งวัน จากประชากรผู้ใช้ที่มีนัยสำคัญทางสถิติ เพื่อให้คำค้นหาและโปรไฟล์ผู้ใช้ต่างๆ ถูกรวมเข้าด้วยกันและแสดงในเมตริก วิธีนี้ทำให้เราสามารถเปรียบเทียบได้ ตัวอย่างเช่น ผู้ใช้จากสเปนค้นหาสูตรอาหารที่เกี่ยวข้องที่ 1 ในเอกสารฉบับที่ 15 โดยเฉลี่ย และผู้ใช้จากอิสราเอลค้นหาสูตรอาหารที่เกี่ยวข้องในเอกสารฉบับที่ 3 โดยเฉลี่ย

ข้อความค้นหา Kusto ต่อไปนี้คำนวณตามนั้นทุกประการ

แผ่นโกง Kusto to SQL ฉบับย่อ (และจำไว้ว่า Kusto ดำเนินการตามลำดับ):

• [ความอยาก] -> [SQL]
• ที่ไหน -> ที่ไหน
• โครงการ -> เลือก
• สรุป -> เลือกด้วยฟังก์ชันการรวมใดๆ เช่น ผลรวม ค่าเฉลี่ย หรือนาที พร้อมกับจัดกลุ่มตามคอลัมน์
• make-series -> คุณสมบัติที่ไม่มีใน SQL ที่เปลี่ยนชุดข้อมูลเป็นพล็อตอนุกรมเวลา
• แสดงผล -> คุณสมบัติอื่นที่ไม่มีใน SQL ที่วางแผนข้อมูล

จากการค้นหา "สูตรพาสต้าของแท้" และเอกสาร 10 ฉบับที่ส่งคืนโดยเครื่องมือค้นหา เราจัดลำดับเอกสารเพื่อให้เอกสารที่คล้ายกับข้อความค้นหามากที่สุดอยู่ในอันดับ 1 และเอกสารที่คล้ายกันน้อยที่สุดอยู่ในอันดับ 10 เพื่อประโยชน์ในตัวอย่าง สมมติว่าผู้ใช้ของเราพบว่าเอกสาร 3, 6 และ 8 มีความเกี่ยวข้อง

arg_max (ExprToMaximize, * | ExprToReturn [, ...])

เมตริกช่องทาง

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

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

คุณสามารถดูสูตรโกง Kusto to SQL ที่สมบูรณ์ สำหรับการตีความแบบสอบถาม

รวมทุกอย่างเข้าด้วยกัน — แดชบอร์ด

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

แดชบอร์ดนี้ช่วยให้เราสามารถติดตามเมตริกของระบบและประสิทธิภาพได้พร้อมกัน อย่างไรก็ตาม ไม่จำเป็นต้องช่วยให้เราสามารถวินิจฉัยได้ว่าเหตุใดประสิทธิภาพของเมตริกของเราจึงแย่ลง ตัวอย่างเช่น หาก “RR รายวัน” ลดลงเมื่อเวลาผ่านไป เป็นเพราะ:

• ความต้องการของผู้ใช้มีการเปลี่ยนแปลง?
• เอกสารใหม่ได้รับการจัดทำดัชนีและเนื้อหาใหม่ไม่ตรงกับเอกสารเก่า?
• ไลบรารีเอกสารของเราล้าสมัยและจำเป็นต้องอัปเดตด้วยเอกสารใหม่หรือไม่
• นิยามความสำเร็จของผู้ใช้เปลี่ยนไปหรือไม่?
• การเปลี่ยนแปลง UX ส่งผลต่อวิธีที่ผู้ใช้โต้ตอบกับผลลัพธ์หรือไม่ ตัวอย่างเช่น วิดเจ็ตหัวข้อจะปรากฏในหน้าผลลัพธ์และแสดงข้อมูล ทำให้ไม่จำเป็นต้องโต้ตอบกับเอกสารใดเอกสารหนึ่ง
• ฤดูกาล?
• อื่น?

บทสรุป

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

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