<!-- Canonical URL: https://ask.atlascloud.ai/th/build-sanitized-request-replay-set-llm-api-migration -->

# จะสร้างชุดเล่นซ้ำคำขอที่ล้างข้อมูลอ่อนไหวสำหรับการย้าย LLM API ได้อย่างไร

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

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

เป้าหมายคือความครอบคลุมพฤติกรรมโดยไม่คัดลอกความเสี่ยงการผลิตไปยังชุดข้อมูลใหม่

## กำหนดสิ่งที่การเล่นซ้ำต้องพิสูจน์

ระบุความเสี่ยงการย้ายก่อนสุ่มตัวอย่าง มิติทั่วไป ได้แก่ ความยาว prompt ภาษา schema เครื่องมือ เอาต์พุตมีโครงสร้าง ส่วนประกอบหลายสื่อ streaming การปฏิเสธด้านความปลอดภัย บริบทยาว และพารามิเตอร์โมเดล

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

## ลดข้อมูลตั้งแต่ตอนเก็บ

ส่งออกเฉพาะฟิลด์ที่จำเป็นต่อการเล่นซ้ำ ตัด authorization header, cookie, IP address, ข้อมูลเมตาบัญชี, ฟิลด์การเรียกเก็บเงิน และ log ที่ไม่เกี่ยวข้องก่อนข้อมูลถึงพื้นที่ทดสอบ

ใช้ allowlist เช่น:

```json
{
  "fixture_id": "fx_0042",
  "request": {
    "model_alias": "support_default",
    "messages": [],
    "tools": [],
    "temperature": 0.2
  },
  "assertions": {
    "valid_json": true,
    "required_keys": ["category", "confidence"]
  }
}
```

สร้าง `fixture_id` ใหม่ อย่าใช้ ID ผู้ใช้หรือ ID คำขอของผู้ให้บริการเป็นคีย์ fixture สาธารณะ

## ตรวจหาข้อมูลอ่อนไหวหลายชั้น

รวมตัวตรวจแบบกำหนดกฎ พจนานุกรมเฉพาะองค์กร และการทบทวนตามบริบท ค้นหา API key, bearer token, private key, connection string, อีเมล, เบอร์โทร, เลขบัญชี, hostname ภายใน, ความลับในซอร์สโค้ด และตัวระบุที่ถูกกำกับดูแล

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

## แทนค่าโดยรักษาพฤติกรรม

ใช้ placeholder ที่มีชนิดและสอดคล้องกัน เช่น `<EMAIL_1>` หรือ `<ORDER_ID_2>` ค่าเดิมเดียวกันควรแมปไปยัง placeholder เดียวกันภายใน fixture เพื่อรักษาการอ้างอิง แต่การแมปไม่ควรย้อนกลับได้นอกกระบวนการชั่วคราวที่ควบคุมเข้มงวด

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

อย่าเพียงแฮชค่าที่มี entropy ต่ำ เช่น เบอร์โทร เพราะมักเดาได้ ให้ลบหรือสังเคราะห์เมื่อไม่จำเป็นต้องย้อนกลับ

## เอาเนื้อหาที่ออกฤทธิ์และอันตรายออก

ชุดเล่นซ้ำอาจมี prompt injection คำสั่งเครื่องมือ URL หรือโค้ดที่สร้างผลข้างเคียง ปิดเครื่องมือภายนอกตามค่าเริ่มต้นและแทนการทำงานที่เขียนข้อมูลได้ด้วย stub แบบกำหนดผลได้

อนุญาตเครือข่ายเฉพาะ endpoint ทดสอบที่ควบคุม ห้ามเล่นซ้ำข้อมูลรับรองการผลิต URL ลงนาม คำสั่งทำลาย หรือปลายทาง webhook ลูกค้า

## เพิ่ม assertion แทนคำตอบที่ตรงทุกตัว

ผลลัพธ์ LLM เปลี่ยนแปลงได้ จึงควรเก็บการตรวจพฤติกรรม เช่น schema ถูกต้อง ฟิลด์บังคับ การเลือกเครื่องมือ หมวดการปฏิเสธ ภาษา เวลาแฝงสูงสุด ขอบเขตโทเค็น และคะแนน rubric เชิงความหมาย เก็บ fixture แบบ exact match เพียงเล็กน้อยสำหรับการแปลงที่กำหนดผลได้จริง

บันทึก ID โมเดลต้นทางและปลายทาง เวอร์ชัน adapter เวอร์ชันเทมเพลต prompt และวันที่เล่นซ้ำในทุกการรัน

## ตรวจสอบ artifact ที่ล้างแล้ว

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

จำกัดชุดเล่นซ้ำเหมือนข้อมูลทดสอบ ไม่ใช่เอกสารสาธารณะ ใช้การควบคุมการเข้าถึง ระยะเก็บ audit log และเส้นทางลบ เก็บการแมปต้นฉบับกับ placeholder ชั่วคราวแยกไว้และทำลายหลังตรวจสอบเมื่อมาตรฐานอนุญาต

## ใช้เป็นด่านการย้าย

รัน fixture เดียวกันผ่าน adapter ต้นทางและปลายทาง เปรียบเทียบผลลัพธ์ที่ทำให้เป็นมาตรฐาน พฤติกรรมข้อผิดพลาด เวลาแฝง การใช้งาน และต้นทุน ตรวจสอบความต่างตามกลุ่มความครอบคลุม แล้วเพิ่ม regression fixture สำหรับความไม่เข้ากันที่พบใหม่

จัดเวอร์ชันชุดข้อมูลและกฎการล้างข้อมูลร่วมกันเพื่อให้ผลลัพธ์อธิบายได้

## สรุป

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

## FAQ

### เหตุใดจึงไม่ควรเล่นซ้ำการส่งออกแบบสุ่มจาก log การผลิต

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

### ควรแทนค่าที่อ่อนไหวอย่างไร

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

### การแฮชเพียงพอสำหรับทำข้อมูลผู้ใช้ให้ไม่ระบุตัวตนหรือไม่

ไม่เพียงพอสำหรับค่าที่มี entropy ต่ำ เช่น หมายเลขโทรศัพท์ เพราะอาจเดาได้ ให้ลบหรือสังเคราะห์เมื่อไม่ต้องย้อนกลับ

### จะเล่นซ้ำการเรียกเครื่องมืออย่างปลอดภัยได้อย่างไร

ปิดเครื่องมือภายนอกตามค่าเริ่มต้นและแทนด้วย stub แบบกำหนดผลได้ ห้ามใช้ข้อมูลรับรองการผลิต webhook ลูกค้า หรือผลการเขียนจริง

### ผลลัพธ์ที่คาดหวังต้องตรงกันทุกตัวอักษรหรือไม่

โดยทั่วไปไม่ต้อง ใช้ assertion สำหรับ schema ฟิลด์บังคับ การเลือกเครื่องมือ การปฏิเสธ ภาษา เวลาแฝง การใช้งาน และคะแนน ใช้ exact match เฉพาะงานที่กำหนดผลได้จริง

### จะอนุมัติชุดเล่นซ้ำสุดท้ายอย่างไร

สแกนความลับและ PII ตรวจสอบชนิดไฟล์ ทบทวนตัวอย่างด้วยคน ยืนยันความครอบคลุม และใช้การควบคุมการเข้าถึง การเก็บรักษา และการลบ