วิธีที่มีประสิทธิภาพที่สุดในการป้องกันไม่ให้ตัวแทนบริการลูกค้า AI รั่วไหลข้อมูลที่ละเอียดอ่อน คือการทำให้แน่ใจว่าโมเดลจะไม่รับ ดึงข้อมูล หรือดำเนินการกับข้อมูลมากกว่าที่คำขอของลูกค้าในปัจจุบันต้องการอย่าพึ่งพาข้อความแจ้งเตือนของระบบที่บอกว่า “ห้ามเปิดเผยข้อมูลส่วนตัว” ควรใช้การควบคุมแบบกำหนดได้กับโมเดล: ลดและปกปิดข้อมูลป้อนเข้า อนุญาตการค้นหาข้อมูลทุกครั้งนอก LLM ให้สิทธิ์ขั้นต่ำแก่เครื่องมือ แยกข้อมูลของลูกค้าแต่ละราย ตรวจสอบความถูกต้องของคำตอบก่อนส่ง และตรวจสอบเส้นทางทั้งหมด
การออกแบบดังกล่าวสอดคล้องกับทิศทางของแนวทางการรักษาความปลอดภัยในปัจจุบันเอกสาร NIST Generative AI Profile (NIST AI 600-1)ซึ่งเผยแพร่ในปี 2024 และได้รับการปรับปรุงโดย NIST ในปี 2026 ถือว่าความเป็นส่วนตัว ความปลอดภัย การตรวจสอบ และการจัดการความเสี่ยงเป็นประเด็นสำคัญตลอดวงจรชีวิตOWASP Top 10 สำหรับ LLM และแอปพลิเคชัน Generative AIระบุการแทรกข้อความแจ้งเตือน การเปิดเผยข้อมูลที่ละเอียดอ่อน การจัดการเอาต์พุตที่ไม่เหมาะสม การให้อำนาจมากเกินไป และการรั่วไหลของข้อความแจ้งเตือนจากระบบ เป็นความเสี่ยงที่แยกต่างหาก ในทางปฏิบัติแล้ว ข้อสรุปนั้นง่ายมาก: ตัวแทนบริการลูกค้าที่ปลอดภัยต้องการการควบคุมอิสระหลายอย่าง ไม่ใช่แค่ข้อความแจ้งเตือนอัจฉริยะเพียงอย่างเดียว
ก่อนที่จะเลือกโมเดลหรือเพิ่มข้อความเตือนเพิ่มเติม ให้ลองวาดเส้นทางที่ข้อมูลลูกค้าไหลผ่านระบบของคุณเสียก่อน โดยทั่วไปแล้ว เจ้าหน้าที่ฝ่ายสนับสนุนอาจได้รับข้อความ ดึงข้อมูลจาก CRM ค้นหาในฐานความรู้ เรียกใช้ API สำหรับการสั่งซื้อหรือการเรียกเก็บเงิน สร้างคำตอบ บันทึกข้อมูล และจัดเก็บหน่วยความจำการสนทนา ข้อมูลที่ละเอียดอ่อนอาจรั่วไหลได้ในจุดใดจุดหนึ่งเหล่านั้น
สำหรับบอทถามตอบพื้นฐานที่ไม่เข้าถึงข้อมูลลูกค้ารายใดเลย ความเสี่ยงหลักของคุณคือสิ่งที่ลูกค้าพิมพ์ลงในแชทและสิ่งที่ถูกบันทึกไว้ สำหรับผู้ช่วยตรวจสอบสถานะคำสั่งซื้อ การอนุญาตและการกรองข้อมูลในระดับฟิลด์มีความสำคัญอย่างยิ่ง สำหรับเจ้าหน้าที่ที่สามารถคืนเงิน เปลี่ยนที่อยู่ หรือยกเลิกบริการได้ สิทธิ์การใช้งานเครื่องมือและการยืนยันธุรกรรมมีความสำคัญไม่แพ้การกรองคำตอบ
การลดปริมาณข้อมูลเป็นมาตรการควบคุมขั้นแรกที่แข็งแกร่งที่สุด เพราะข้อมูลที่โมเดลไม่เคยได้รับจะไม่สามารถนำมาใช้ซ้ำในผลลัพธ์ได้แนวทางการรักษาความปลอดภัยข้อมูลของ FTCแนะนำให้เก็บรวบรวมเฉพาะสิ่งที่จำเป็น เก็บรักษาให้ปลอดภัย และกำจัดทิ้งอย่างปลอดภัย นำแนวคิดนี้ไปประยุกต์ใช้โดยตรงกับการสร้างบริบทของ AI
สมมติว่าลูกค้าถามว่า “คำสั่งซื้อของฉันอยู่ที่ไหน?” โดยปกติแล้วโมเดลไม่จำเป็นต้องทราบหมายเลขบัตรเครดิต หมายเลขประจำตัวผู้เสียภาษี วันเกิด ประวัติที่อยู่โดยละเอียด หรือบันทึกการป้องกันการฉ้อโกงภายในของลูกค้า แอปพลิเคชันของคุณสามารถตรวจสอบตัวตนของลูกค้า โทรไปยังฝ่ายบริการคำสั่งซื้อ และส่งเฉพาะผลลัพธ์ที่จำกัด เช่น หมายเลขคำสั่งซื้อ สถานะการจัดส่ง การประมาณการจัดส่ง และบันทึกการสนับสนุนที่ได้รับการอนุมัติ ไปยังโมเดลเท่านั้น
รายการที่แน่นอนขึ้นอยู่กับธุรกิจและข้อผูกพันทางกฎหมายของคุณ แต่โดยทั่วไปแล้ว ข้อมูลที่อาจพบได้บ่อย ได้แก่ ข้อมูลประจำตัวการชำระเงิน รหัสลับการตรวจสอบสิทธิ์ รหัสประจำตัวของหน่วยงานรัฐ ข้อมูลสุขภาพ หมายเลขบัญชีการเงินทั้งหมด ที่อยู่ส่วนตัว บันทึกความปลอดภัยภายใน และข้อมูลธุรกิจที่เป็นความลับ ควรใช้ตัวตรวจจับแบบกำหนดได้ (deterministic detectors) เท่าที่จะเป็นไปได้ และรักษาแบบแผนเฉพาะโดเมนสำหรับรหัสประจำตัวของคุณเอง
อย่าคิดว่าการซ่อนข้อความแชทที่มองเห็นได้นั้นเพียงพอแล้ว ให้ใช้หลักการเดียวกันนี้กับเอกสารที่ดึงมา การตอบสนองของเครื่องมือ บันทึกย่อของเจ้าหน้าที่ สรุปการสนทนา เหตุการณ์การวิเคราะห์ ร่องรอย และบันทึกข้อผิดพลาดด้วย
แบบจำลอง AI ไม่ควรตัดสินใจว่าลูกค้า A ได้รับอนุญาตให้อ่านข้อมูลของลูกค้า B หรือไม่ การอนุญาตต้องเกิดขึ้นในโค้ดแอปพลิเคชันที่กำหนดได้แน่นอน หรือบริการควบคุมการเข้าถึง ก่อนที่จะส่งข้อมูลกลับไปยังตัวแทน
หลักการนี้สอดคล้องกับหลักการของNIST SP 800-207 สถาปัตยกรรมความไว้วางใจเป็นศูนย์ (Zero Trust Architecture ) กล่าวคือ การเข้าถึงทรัพยากรจะได้รับอนุญาตโดยพิจารณาจากตัวตนที่ได้รับการตรวจสอบและอนุญาตอย่างถูกต้อง แทนที่จะเป็นความไว้วางใจโดยปริยาย สำหรับเอเจนต์ AI แนวทางเดียวกันนี้หมายความว่า ทุกคำขอ CRM การออกตั๋ว การสั่งซื้อ หรือการเรียกเก็บเงิน ควรมีข้อมูลระบุตัวตนผู้ใช้ที่ได้รับการตรวจสอบแล้ว และตรวจสอบกับทรัพยากรที่ร้องขอ
การค้นหาข้อมูลคำสั่งซื้อที่ปลอดภัยอาจทำได้โดยการ "ดึงสถานะคำสั่งซื้อสำหรับ authenticated_customer_id และ order_id" โดยที่ระบบแบ็กเอนด์จะยืนยันความเป็นเจ้าของก่อนที่จะส่งการตอบกลับที่อนุญาตกลับมา ส่วนการออกแบบที่อันตรายคือการ "ค้นหาบันทึกของลูกค้าทั้งหมด" แล้วเชื่อมั่นว่าโมเดลจะเลือกข้อมูลที่ถูกต้องได้เอง
เอเจนต์ที่ใช้เครื่องมือช่วยนั้นมีความเสี่ยงเป็นพิเศษ เพราะการฉีดข้อมูลผิดพลาดหรือข้อผิดพลาดของโมเดลเพียงเล็กน้อยก็อาจกลายเป็นการโจมตีระบบจริงได้คำแนะนำเรื่องเอเจนต์ที่มีฟังก์ชันการทำงานมากเกินไป สิทธิ์การเข้าถึงที่มากเกินไป และความเป็นอิสระที่มากเกินไป ระบุว่าเป็นสาเหตุหลักของพฤติกรรมเอเจนต์ที่ก่อให้เกิดความเสียหาย
อย่าให้สิทธิ์การเข้าถึง CRM แบบทั่วไปแก่เจ้าหน้าที่บริการลูกค้าเพียงคนเดียว โดยให้สิทธิ์ในการอ่าน/เขียนข้อมูลทุกรายการ ควรแบ่งสิทธิ์ตามวัตถุประสงค์ เจ้าหน้าที่ฝ่ายความรู้ อาจต้องการสิทธิ์ในการอ่านอย่างเดียวสำหรับเนื้อหาช่วยเหลือที่ได้รับอนุมัติ เครื่องมือตรวจสอบสถานะคำสั่งซื้อ อาจแสดงเฉพาะข้อมูลการจัดส่ง เครื่องมือคืนเงิน อาจต้องการขอบเขตการอนุญาต ขีดจำกัดการทำธุรกรรม และการยืนยันจากบุคคลหรือลูกค้าก่อนดำเนินการ
สำหรับการดำเนินการที่มีผลกระทบสูง ควรบังคับใช้กฎทางธุรกิจในโค้ดแบ็กเอนด์ โมเดลอาจเสนอ "คำสั่งคืนเงิน 123" แต่แอปพลิเคชันควรตรวจสอบความถูกต้องของลูกค้าที่ได้รับการยืนยันตัวตน สิทธิ์ในการคืนเงิน จำนวนเงิน สกุลเงิน สถานะการทำธุรกรรม และข้อกำหนดการอนุมัติอย่างอิสระ
การแทรกคำสั่งแบบป้อนข้อความอัตโนมัติไม่ได้จำกัดอยู่แค่การที่ลูกค้าพิมพ์ “ละเว้นคำสั่งของคุณ” เท่านั้นแนวทางของ OWASP Prompt Injectionระบุว่า คำสั่งทางอ้อมยังสามารถมาในรูปแบบเอกสาร เว็บเพจ ผลลัพธ์จากเครื่องมือ รูปภาพ หรือเนื้อหาอื่นๆ ที่โมเดลประมวลผลได้อีกด้วย
เรื่องนี้สำคัญในงานบริการลูกค้า เพราะเจ้าหน้าที่มักเรียกดูประวัติการแจ้งปัญหา อีเมล เอกสารที่อัปโหลด หน้าสินค้า หรือบันทึกในระบบ CRM คำสั่งที่เป็นอันตรายที่ซ่อนอยู่ภายในแหล่งข้อมูลเหล่านั้นควรคงอยู่เป็นเพียงข้อมูล ไม่ใช่กลายเป็นอำนาจเหนือเจ้าหน้าที่
ใช้รายการแหล่งข้อมูลการเรียกค้นที่ได้รับอนุญาต แยกคำสั่งที่เชื่อถือได้ออกจากเนื้อหาที่ไม่น่าเชื่อถือ ทำความสะอาดหรือแปลงข้อมูลที่เรียกค้นได้เมื่อทำได้ และตรวจสอบการอนุญาตที่ขอบเขตของเครื่องมือ เมื่อเอกสารที่เรียกค้นร้องขอข้อมูลลับ ข้อมูลประจำตัว บันทึกที่ไม่เกี่ยวข้อง หรือการกระทำของเครื่องมือ แอปพลิเคชันโดยรอบควรบล็อกการดำเนินการเหล่านั้นโดยไม่คำนึงถึงสิ่งที่แบบจำลองตัดสินใจ
ข้อความแจ้งเตือนที่ชัดเจนจากระบบยังคงมีคุณค่า มันสามารถบอกเจ้าหน้าที่ไม่ให้พูดซ้ำข้อมูลที่เป็นความลับ ไม่ให้เปิดเผยข้อมูลของลูกค้ารายอื่น ให้ขอการยืนยันเมื่อจำเป็น และให้ส่งต่อกรณีที่ไม่แน่ใจไปยังผู้ที่เกี่ยวข้อง แต่ควรใช้ข้อความแจ้งเตือนนี้เป็นเพียงแนวทางในการกำหนดนโยบายให้กับแบบจำลอง ไม่ใช่กลไกที่ใช้ปกป้องข้อมูล
คำแนะนำเรื่องการรั่วไหลของข้อมูลในระบบแจ้งเตือนของ OWASP เตือนอย่างชัดเจนถึงการไม่ควรวางข้อมูลประจำตัว สตริงการเชื่อมต่อ โครงสร้างสิทธิ์ที่ละเอียดอ่อน หรือความลับอื่นๆ ไว้ในระบบแจ้งเตือน นอกจากนี้ยังแนะนำให้บังคับใช้การควบคุมที่สำคัญ เช่น การอนุญาตและการแยกสิทธิ์ไว้ภายนอก LLM (Level of Life)
สมมติว่าโมเดลอาจสร้างสิ่งที่ไม่ควรสร้างได้ในบางครั้ง จึงควรสร้างเกตตรวจสอบผลลัพธ์ที่ตรวจสอบข้อมูลที่อาจมีความละเอียดอ่อน เช่น รูปแบบข้อมูลที่ซับซ้อน ตัวระบุข้ามลูกค้า ข้อมูลลับ ลิงก์ที่ไม่รองรับ รูปแบบการเขียนโค้ดที่เป็นอันตราย หรือค่าที่ละเมิดนโยบายทางธุรกิจของคุณ ก่อนที่จะส่งข้อมูลนั้นออกไป
คำแนะนำเรื่องการจัดการเอาต์พุตที่ไม่เหมาะสมของ OWASP แนะนำให้ถือว่าเอาต์พุตของโมเดลนั้นไม่น่าเชื่อถือ และควรตรวจสอบความถูกต้องหรือกรองข้อมูลก่อนส่งต่อไปยังส่วนประกอบปลายทาง ในงานบริการลูกค้า คำแนะนำนี้ใช้ได้ทั้งกับข้อความที่แสดงต่อผู้ใช้และเอาต์พุตที่มีโครงสร้างซึ่งใช้สำหรับการเรียกใช้ API
ตัวอย่างเช่น หากโมเดลสร้างคำขอเครื่องมือ JSON เพื่อเปลี่ยนที่อยู่ไปรษณีย์ ให้ตรวจสอบความถูกต้องของโครงสร้างข้อมูล ยืนยันตัวตนลูกค้า ตรวจสอบว่าบัญชีเป้าหมายอยู่ในเซสชันเดียวกัน ปฏิเสธฟิลด์ที่ไม่คาดคิด และขอการยืนยันเมื่อการกระทำนั้นมีความละเอียดอ่อน ห้ามเรียกใช้คำสั่ง SQL คำสั่งเชลล์ URL หรือตัวระบุฐานข้อมูลที่สร้างโดยโมเดลเพียงเพราะผลลัพธ์ “ดูมีโครงสร้าง”
การรั่วไหลของข้อมูลระหว่างลูกค้ามักเกิดจากการเรียกค้นข้อมูลหรือการจัดการสถานะมากกว่าจากแบบจำลองพื้นฐานเอง ระบบบริการลูกค้าที่ใช้ดัชนีเวกเตอร์ แคชการสนทนา หน่วยความจำระยะยาว หรือผลการค้นหาร่วมกันระหว่างผู้ใช้งาน จำเป็นต้องมีการกรองอย่างเข้มงวดก่อนการเรียกค้นข้อมูล
ตรวจสอบสิทธิ์การเข้าถึงของผู้เช่าและผู้ใช้ก่อนที่จะส่งเอกสารกลับไปยังระบบ อย่าดึงข้อมูลจำนวนมากเกินไปแล้วขอให้ LLM ทิ้งข้อมูลที่ไม่ควรเห็น ระบบควรได้รับเฉพาะข้อมูลที่ผู้ใช้ที่ได้รับการรับรองสิทธิ์ในปัจจุบันได้รับอนุญาตให้เข้าถึงเท่านั้น
ใช้เนมสเปซที่แยกต่างหาก นโยบายระดับแถว ACL ของเอกสาร หรือการแยกส่วนที่เทียบเท่าซึ่งบังคับใช้โดยเลเยอร์ข้อมูล ทดสอบกรณีเชิงลบ: ลูกค้า A ค้นหาที่อยู่อีเมล รหัสคำสั่งซื้อ ตั๋วสนับสนุน และหมายเลขบัญชีบางส่วนของลูกค้า B ผลลัพธ์ที่ถูกต้องคือไม่มีเอกสารที่ไม่ได้รับอนุญาตเข้าสู่บริบทของโมเดลเลย
การบันทึกข้อมูลเป็นสิ่งจำเป็นสำหรับการรับมือกับเหตุการณ์ แต่บันทึกเหล่านั้นอาจกลายเป็นสำเนาข้อมูลสำคัญที่คุณพยายามปกป้องไว้อีกชุดหนึ่งได้ ควรบันทึกบริบทให้เพียงพอต่อการตรวจสอบการตัดสินใจ ในขณะเดียวกันก็ต้องปิดบังหรือแปลงข้อมูลสำคัญให้เป็นโทเค็น จำกัดการเข้าถึงบันทึก กำหนดระยะเวลาการเก็บรักษา และหลีกเลี่ยงการบันทึกข้อความแจ้งเตือนและข้อมูลเครื่องมือดิบโดยค่าเริ่มต้น หากข้อมูลเหล่านั้นมีข้อมูลลับของลูกค้าอยู่
มาตรฐาน NIST SP 800-53 ฉบับแก้ไข 5.1ประกอบด้วยการควบคุมการตรวจสอบและการรับผิดชอบที่เน้นการเลือกและทบทวนประเภทเหตุการณ์ที่เกี่ยวข้องกับความปลอดภัย เพื่อให้สามารถตรวจสอบเหตุการณ์ต่างๆ ได้ สำหรับระบบสนับสนุน AI เหตุการณ์ที่มีประโยชน์ ได้แก่ การปฏิเสธการเข้าถึงข้อมูล การกระตุ้นการปกปิดข้อมูล ปริมาณการเรียกค้นข้อมูลที่ผิดปกติ ความพยายามแทรกข้อความแจ้งเตือนซ้ำๆ การเรียกใช้เครื่องมือที่ถูกบล็อก ความล้มเหลวในการอนุญาตข้ามผู้เช่า และการละเมิดนโยบายเอาต์พุต
ดำเนินการทดสอบความปลอดภัยที่สามารถทำซ้ำได้ก่อนเปิดใช้งานและหลังจากการเปลี่ยนแปลงที่สำคัญในส่วนของข้อความแจ้งเตือน โมเดล เครื่องมือ ดัชนีการเรียกค้น นโยบายการเข้าถึง หรือพฤติกรรมของหน่วยความจำ รวมถึงการทดสอบการแทรกข้อความแจ้งเตือนโดยตรง การแทรกข้อความโดยอ้อมในเอกสารที่เรียกค้น การขอข้อมูลของลูกค้ารายอื่น ตัวระบุที่เข้ารหัสหรือปกปิด การใช้เครื่องมือในทางที่ผิด การพยายามหลีกเลี่ยงนโยบายหลายรอบ และการพยายามทำให้เอเจนต์เปิดเผยบริบทภายในของตนเอง
| ประเภทตัวแทน | การควบคุมที่มีลำดับความสำคัญสูงสุด | ทำไม |
|---|---|---|
| บอทคำถามที่พบบ่อยสาธารณะ | การลดปริมาณข้อมูลขาเข้า การบันทึกข้อมูลอย่างปลอดภัย การกรองข้อความแจ้งเตือน การตรวจสอบผลลัพธ์ | ไม่ควรจำเป็นต้องใช้ข้อมูลส่วนตัวของลูกค้าเลย |
| ผู้ช่วยตรวจสอบสถานะคำสั่งซื้อ | การตรวจสอบสิทธิ์ที่เข้มงวด การตรวจสอบความเป็นเจ้าของ การตอบสนอง API ระดับฟิลด์ การแยกผู้เช่า | ระบบต้องการข้อมูลลูกค้าบางส่วน แต่เฉพาะสำหรับผู้ใช้ที่ได้รับการยืนยันตัวตนและคำสั่งซื้อปัจจุบันเท่านั้น |
| เจ้าหน้าที่ฝ่ายสนับสนุนบัญชี | เครื่องมือ CRM ที่มีสิทธิ์ขั้นต่ำสุด การปกปิดข้อมูลส่วนบุคคล (PII redaction) การป้องกันการรั่วไหลของข้อมูล (DLP) การแยกหน่วยความจำ การยกระดับสิทธิ์ | ระบบนี้จัดการข้อมูลส่วนบุคคลที่ซับซ้อนกว่าและอาจเข้าถึงระบบหลายระบบได้ |
| ตัวแทนคืนเงินหรือยกเลิก | ทุกสิ่งที่กล่าวมาข้างต้น รวมถึงกฎทางธุรกิจที่กำหนดไว้แน่นอน ข้อจำกัดในการทำธุรกรรม การยืนยัน และบันทึกการตรวจสอบ | ตัวแทนสามารถเปลี่ยนแปลงสถานะในโลกแห่งความเป็นจริงได้ ดังนั้นการรั่วไหลและการกระทำที่ไม่ได้รับอนุญาตจึงมีความสำคัญ |
| แพลตฟอร์มสนับสนุนองค์กรแบบหลายผู้เช่า | การเรียกค้นข้อมูลโดยคำนึงถึงผู้เช่า, การระบุตัวตนบริการแบบมีขอบเขต, การบังคับใช้ ACL ของเอกสาร, การบันทึกข้อมูลต่อผู้เช่าแต่ละราย | ความผิดพลาดในการดึงข้อมูลเพียงครั้งเดียวอาจทำให้ข้อมูลขององค์กรหนึ่งรั่วไหลไปยังอีกองค์กรหนึ่งได้ |
อย่าวัดความปลอดภัยเพียงแค่ว่าแชทบอทปฏิเสธคำขอที่น่าสงสัยอย่างสุภาพบ่อยแค่ไหน ควรวัดว่าระบบพื้นฐานป้องกันไม่ให้ข้อมูลที่ละเอียดอ่อนเข้าสู่บริบทของโมเดลหรือออกจากบริบทนั้นผ่านการตอบสนองหรือการกระทำของเครื่องมือหรือไม่
ตัวชี้วัดทางวิศวกรรมที่มีประโยชน์ ได้แก่ เปอร์เซ็นต์ของคำขอข้อมูลส่วนตัวที่ถูกบล็อกก่อนการเรียกใช้ การตรวจสอบสิทธิ์ที่ไม่สำเร็จระหว่างผู้ใช้งาน ความแม่นยำในการปกปิดข้อมูลในกรณีทดสอบที่ทราบ การบล็อกเอาต์พุตที่ละเอียดอ่อน ความพยายามเรียกใช้เครื่องมือโดยไม่ได้รับอนุญาต เปอร์เซ็นต์ของการกระทำที่มีความเสี่ยงสูงที่ต้องได้รับการยืนยัน และเวลาตั้งแต่การตรวจพบจนถึงการสืบสวน ควรใช้ชุดข้อมูลทดสอบที่เป็นข้อมูลสังเคราะห์หรือมีการควบคุมอย่างเหมาะสม เพื่อให้การประเมินความปลอดภัยของคุณไม่ก่อให้เกิดปัญหาด้านความเป็นส่วนตัวใหม่
ระบบ AI บริการลูกค้าที่ปลอดภัยที่สุดไม่ใช่ระบบที่มีข้อความแจ้งเตือนด้านความปลอดภัยยาวที่สุด แต่เป็นระบบที่ทำงานอยู่ภายในเส้นทางข้อมูลที่แคบและตรวจสอบได้ ให้ข้อมูลเฉพาะที่จำเป็นสำหรับลูกค้าที่ได้รับการยืนยันในปัจจุบัน เฉพาะเครื่องมือที่จำเป็นสำหรับงานปัจจุบัน และเฉพาะสิทธิ์ที่จำเป็นสำหรับการเรียกใช้เครื่องมือนั้น กรองข้อมูลก่อนการประมวลผล ตรวจสอบความถูกต้องของผลลัพธ์หลังการประมวลผล และบังคับใช้การตรวจสอบตัวตนและการอนุญาตโดยไม่ขึ้นอยู่กับตัวแบบ
ใช้คำสั่งระดับโมเดลเป็นเพียงชั้นหนึ่ง ไม่ใช่เป็นด่านสุดท้าย เมื่อข้อมูลที่ละเอียดอ่อนได้รับการปกป้องด้วยการควบคุมการเข้าถึงแบบกำหนดได้ การลดบริบทให้น้อยที่สุด เครื่องมือที่มีสิทธิ์ขั้นต่ำ การแยกผู้เช่า การตรวจสอบความถูกต้องของผลลัพธ์ การบันทึกข้อมูลอย่างปลอดภัย และการทดสอบอย่างต่อเนื่อง โอกาสที่จะเกิดการรั่วไหลของข้อมูลลูกค้าจากการโจมตีแบบฉับพลันหรือข้อผิดพลาดของโมเดลจะลดลงอย่างมาก
สร้างเวิร์กโฟลว์ Ollama ในเครื่องของคุณเพื่อสร้างชื่อเรื่อง SEO และคำอธิบายเมตาที่มีโครงสร้างในปริมาณมาก ตรวจสอบความถูกต้องของผลลัพธ์ และทำเครื่องหมายผลลัพธ์เพื่อส่งให้มนุษย์ตรวจสอบ
Use this free modern real estate listing presentation PowerPoint blueprint to organize pricing, marketing, property prep, agent value, and seller next steps.
สร้างเทมเพลตประมาณการค่าใช้จ่ายในการก่อสร้างที่สามารถพิมพ์ได้ใน Excel โดยระบุค่าแรง ค่าวัสดุ สูตรคำนวณ ส่วนเพิ่มราคา รายการที่ยกเว้น และยอดรวมสำหรับลูกค้าที่พร้อมพิมพ์ได้อย่างชัดเจน
สร้างพรอมต์วิดีโอ Luma Dream Machine ที่ทรงพลังยิ่งขึ้นด้วยสูตรแสงภาพยนตร์ที่ใช้งานได้จริง สูตรที่นำกลับมาใช้ใหม่ได้ ตัวอย่าง และรายการตรวจสอบการแก้ไขปัญหาอย่างรวดเร็ว
สร้างสไลด์นำเสนอสำหรับนักลงทุนสตาร์ทอัพด้านเทคโนโลยีแบบเรียบง่ายใน PowerPoint โดยจัดลำดับสไลด์ให้เหมาะสม มีกฎการออกแบบที่ชัดเจน ตัวชี้วัดความก้าวหน้า และภาคผนวกที่พร้อมสำหรับนักลงทุน
ป้องกันไม่ให้ Excel แปลงรหัส รหัสประจำตัว และเศษส่วนเป็นวันที่ ใช้รูปแบบข้อความ เครื่องหมายอัญประกาศ การควบคุมการนำเข้า และตัวเลือก Microsoft 365 ที่มีอยู่
เร่งความเร็วในการเรนเดอร์ ComfyUI SDXL โดยลดงานการสุ่มตัวอย่าง ควบคุมความละเอียดและขนาดแบทช์ ลดความซับซ้อนของโหนด ใช้แคช และปรับแต่ง VRAM และ Attention อย่างปลอดภัย
สร้างระบบติดตามรายรับและค่าใช้จ่ายจากอสังหาริมทรัพย์ให้เช่าที่ใช้งานได้จริงใน Excel โดยมีหมวดหมู่ที่ชัดเจน สูตรคำนวณ สรุปรายเดือน และคำแนะนำในการบันทึกบัญชีเพื่อการยื่นภาษี
สร้างฐานความรู้ AI ส่วนตัวในพื้นที่ด้วย Ollama, AnythingLLM, การฝังข้อมูลในพื้นที่ และ RAG เรียนรู้ขั้นตอนการตั้งค่าสี่ขั้นตอน การตรวจสอบความเป็นส่วนตัว การทดสอบ และการสำรองข้อมูล
แก้ไขข้อผิดพลาดของหน้าต่างบริบทในการวิเคราะห์เอกสารขนาดยาวโดยการตัดแต่งข้อมูลนำเข้า การแบ่งไฟล์ การใช้การดึงข้อมูล และการตรวจสอบว่าคำตอบสุดท้ายครอบคลุมแหล่งที่มา
