คำตอบถูก แต่เส้นทางผิด

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

การให้คะแนนเฉพาะผลลัพธ์จะให้คะแนนเต็มทั้งคู่ ซึ่งเป็นการให้คะแนนผิด

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

ค่าสุดท้ายพิสูจน์ที่มาไม่ได้

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

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

แต่ละคำตอบเปลี่ยนความน่าเชื่อถือของการแมปสุดท้ายเดียวกัน การแมปคือผลลัพธ์ ส่วนร่องรอยหลักฐานคือเหตุผลที่ควรใช้

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

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

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

เขียนเส้นทางที่อนุญาตไว้ในงาน

กรณีทดสอบที่ดีมีสองส่วน ส่วนแรกบอกสิ่งที่ปลายทางควรมี ส่วนที่สองบอกหลักฐานและการกระทำที่อนุญาตระหว่างทาง

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

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

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

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

ร่องรอยพิสูจน์อะไร?

1. แหล่งที่อนุมัติและการตรวจที่ต้องทำ

   รับเส้นทาง

   ผลลัพธ์มีหลักฐานตามที่งานกำหนด

2. แหล่งข้ามพื้นที่ทำงาน

   ปฏิเสธเส้นทาง

   จำนวนที่ตรงกันไม่ได้ให้อำนาจอ่าน

3. ขาดหลักฐานบังคับ

   พักเพื่อทบทวน

   ผลลัพธ์อย่างเดียวพิสูจน์วิธีได้มาไม่ได้

อย่าให้ร่องรอยกลายเป็นพิธี

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

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

ต้นทุนคือกรณีทดสอบต้องละเอียดขึ้น ใครบางคนต้องกำหนดแหล่งที่อนุญาต ความต่างที่คาด และทางลัดที่ห้าม คะแนนทั่วไปแบบ “คำตอบดูดีไหม” สร้างถูกกว่า แต่สอนน้อยกว่า

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

คำตอบถูกที่ได้จากบัญชีผิดไม่ใช่เกือบสำเร็จ มันเป็นคนละงาน