ใหม่ · เปิดตัวตามพื้นที่ทำงาน

การกำกับดูแล AI: การตรวจสอบตนเองและการอนุมัติ

Flash นำทุกการกระทำที่ริเริ่มโดย AI ไว้เบื้องหลังอุปกรณ์การอนุญาตต่อการกระทำ — auto, review หรือ forbidden — กำหนดค่าต่อพื้นที่ทำงานในคอนโซลกิจกรรมและการอนุมัติของ AI สำหรับไคลเอนต์ AI ที่มากกว่า MCP นี่หมายถึงสองสิ่ง: คุณสามารถค้นพบออบเจ็กต์ทางธุรกิจและการดำเนินการที่คุณได้รับอนุญาตให้ทำก่อนดำเนินการ และการเรียกการเขียนของคุณจะส่งกลับผลลัพธ์ที่มีโครงสร้าง — ดำเนินการ รอการอนุมัติจากมนุษย์ หรือปฏิเสธด้วยเหตุผลที่เครื่องอ่านได้

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

วิปัสสนาวัตถุธุรกิจ (ขอบเขต `introspection:read`)

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

list_objectsอ่าน

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

พารามิเตอร์: (none)

describe_objectอ่าน

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

พารามิเตอร์: object

list_actionsอ่าน

การกระทำที่ลูกค้า AI อาจดำเนินการ พร้อมเงื่อนไขเบื้องต้นของการกระทำแต่ละอย่าง และกลไกการอนุญาตปัจจุบัน (อัตโนมัติ / ตรวจสอบ / ห้าม) ตามที่กำหนดค่าไว้ในพื้นที่ทำงาน กรองตาม object เพื่อดูเฉพาะการกระทำที่เกี่ยวข้องเท่านั้น สิ่งที่ได้กลับมาคือสิ่งที่เลเยอร์การกำกับดูแลจะบังคับใช้ — ใช้เพื่อหลีกเลี่ยงการเสนอการกระทำที่จะถูกปฏิเสธ

พารามิเตอร์: object?

PII เป็นข้อมูลเมตาเท่านั้น โดยการออกแบบ Introspection อธิบายช่องต่างๆ ที่เก็บข้อมูลส่วนบุคคล (ชื่อ ประเภท ความหมาย และธง pii) แต่จะไม่ส่งคืนค่าเหล่านั้น การอ่านข้อมูลสมาชิกจริงจะต้องผ่านเครื่องมือการอ่านของสมาชิกและขอบเขตของตนเอง

ตัวอย่าง: อธิบายวัตถุ แล้วตรวจสอบเกียร์

ตัวอย่างเชิงพรรณนาของรูปแบบคำขอ/การตอบกลับ (ตัวย่อ — รายการคำตอบจริงทุกฟิลด์และการดำเนินการ):

// describe_object { "object": "member" }
{
  "object": "member",
  "label": "Member",
  "meaning": "A loyalty program member owned by this workspace.",
  "fields": [
    { "name": "email",            "type": "string",  "pii": true,
      "meaning": "Contact email. PII: metadata only — values are never returned here." },
    { "name": "tier",             "type": "string",  "pii": false,
      "meaning": "Current loyalty tier." },
    { "name": "membership_no",    "type": "string",  "pii": false, "custom": true,
      "meaning": "Workspace-defined custom field." }
  ],
  "relationships": [
    { "to": "order",  "kind": "has_many",  "meaning": "Orders placed by this member." },
    { "to": "coupon", "kind": "has_many",  "meaning": "Coupons issued to this member." },
    { "to": "tag",    "kind": "has_many",  "meaning": "Tags currently applied to this member." }
  ]
}

// list_actions { "object": "member" }
{
  "actions": [
    { "action": "issue_coupon",     "gear": "review",
      "preconditions": ["member has consent", "coupon pool has stock"] },
    { "action": "earn_points",      "gear": "auto",
      "preconditions": ["amount within the workspace cap"] },
    { "action": "assign_tag",       "gear": "auto",
      "preconditions": ["tag exists and is active"] },
    { "action": "add_member_note",  "gear": "auto",
      "preconditions": ["note passes server-side sanitation"] },
    { "action": "send_campaign",    "gear": "review", "locked": true,
      "preconditions": ["sending can never be auto — a human always approves"] }
  ]
}

gear ที่คุณเห็นคืออุปกรณ์ที่จะถูกบังคับใช้ — พื้นที่ทำงานจะกำหนดค่าต่อการกระทำในคอนโซล และตัวตัดวงจรต่อการกระทำสามารถลดระดับการกระทำเป็น review ได้ตลอดเวลา (มันจะลดระดับลงโดยอัตโนมัติเท่านั้น มนุษย์เท่านั้นที่จะกู้คืนได้) ตรวจสอบอีกครั้งด้วย list_actions แทนที่จะแคชอุปกรณ์สำหรับเซสชันที่ยาวนาน

เขียนเครื่องมือภายใต้เครื่องมือตรวจสอบ: รอดำเนินการ / ปฏิเสธ

เมื่อเครื่องมือเขียน MCP กำหนดเป้าหมายไปยังการกระทำที่มีเกียร์เป็น review การเรียกนั้น จะไม่ ดำเนินการผลข้างเคียง มันจะส่งคืนผลลัพธ์ที่มีโครงสร้าง: ไม่ว่าข้อเสนอจะถูกจัดคิวเพื่อขออนุมัติจากมนุษย์ (pending) หรือถูกปฏิเสธโดยสิ้นเชิง (refused) พร้อมด้วย reason_code และ suggested_action ที่เครื่องอ่านได้

// proposed — waiting for a human
{
  "status": "pending",
  "proposal_id": "prop_9f2c…",
  "action": "issue_coupon",
  "expires_at": "2026-07-10T00:00:00Z",  // 7 days
  "message": "Queued for human approval in
              AI Activity & Approvals."
}

// refused — with a reason and a next step
{
  "status": "refused",
  "action": "issue_coupon",
  "reason_code": "recently_rejected",
  "suggested_action": "A human rejected this
    proposal recently. Do not re-propose;
    consider a different action or ask the
    operator."
}

reason_code	ความหมาย	สิ่งที่ตัวแทนของคุณควรทำ
`gear_forbidden`	การตั้งค่าการกระทำถูกห้ามสำหรับพื้นที่ทำงานนี้ (หรือการกระทำนั้นไม่สามารถเป็นอัตโนมัติได้ เช่น การส่ง และถูกเรียกใช้ในลักษณะที่ต้องใช้โหมดอัตโนมัติ)	อย่าพยายามซ้ำ เปิดเผยการปฏิเสธ แล้วทำตาม suggested_action (โดยทั่วไปหมายถึงการกระทำทางเลือกหรือ 'ขอให้คนอื่นเปลี่ยนเกียร์')
`recently_rejected`	เมื่อเร็ว ๆ นี้มนุษย์ได้ปฏิเสธข้อเสนอเดียวกันสำหรับเป้าหมายเดียวกัน - แพลตฟอร์มจะไม่จัดคิวใหม่	เคารพการตัดสินใจของมนุษย์ อย่าเสนอใหม่หรือแก้ไขถ้อยคำ ให้ปฏิบัติตาม suggested_action.

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

วงจรการอนุมัติ

ข้อเสนอ pending จะได้รับการแก้ไขเพียงวิธีเดียวเท่านั้น: approved, rejected หรือ expired มนุษย์จะดำเนินการกับข้อเสนอนั้นในคอนโซล AI Activity & Approvals (แบบเดี่ยวหรือแบบกลุ่มตามประเภทการดำเนินการ) อีเมลสรุปรายวันจะแสดงสิ่งที่รออยู่

สถานะ	มันเกิดขึ้นได้อย่างไร	แล้ว
`pending`	มีการเรียกใช้เครื่องมือเขียนในขณะที่อุปกรณ์ของการดำเนินการอยู่ระหว่างการตรวจสอบ ข้อเสนออยู่ในคิวรอการอนุมัติจากมนุษย์	อนุมัติ · ถูกปฏิเสธ · หมดอายุแล้ว
`approved`	มนุษย์เป็นผู้ให้การอนุมัติ ก่อนดำเนินการ แพลตฟอร์มจะตรวจสอบความถูกต้องของเหตุผลที่ AI ระบุไว้อีกครั้ง หากเหตุผลนั้นไม่ถูกต้องอีกต่อไป (เช่น ลูกค้าซื้อซ้ำแล้ว) การดำเนินการจะไม่ถูกดำเนินการ	เทอร์มินัล (บันทึกผลลัพธ์ในบันทึกการตัดสินใจ สามารถยกเลิกได้ทีละรายการ)
`rejected`	มนุษย์ปฏิเสธข้อเสนอนั้น โดยอาจมีหมายเหตุประกอบ หากส่งข้อเสนอเดิมซ้ำอีกครั้ง ก็จะถูกปฏิเสธอีกครั้งโดยมีข้อความว่า recently_rejected	เทอร์มินัล
`expired`	ไม่มีการตัดสินใจภายใน 7 วัน — ข้อเสนอจะหมดอายุเองและไม่มีการดำเนินการใดๆ	เทอร์มินัล

รับประกันความไม่มีอำนาจ

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

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

พื้นฐานความโปร่งใสและสินค้าคงคลังแบบจำลองกล่องแก้ว

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

การเพิ่มประสิทธิภาพการรับส่งข้อมูล A/B อัตโนมัติ: บันทึกการตัดสินใจ

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

บันทึกการตัดสินใจต่อท้ายเท่านั้น การคำนวณซ้ำรายชั่วโมงแต่ละครั้งจะเขียนบันทึกหนึ่งรายการพร้อมน้ำหนักที่ใช้และเหตุผลที่มนุษย์สามารถอ่านได้ บันทึกจะไม่ถูกเขียนใหม่ - บันทึกคือประวัติทั้งหมดว่าทำไมการรับส่งข้อมูลจึงมีลักษณะเช่นนั้น
การแยกที่กำหนดค่าไว้จะไม่กลายพันธุ์ การแยกที่กำหนดค่าของการทดสอบของคุณจะไม่ถูกแตะต้องเป็นค่าพื้นฐาน น้ำหนักที่ปรับให้เหมาะสมจะถูกคำนวณและบันทึกควบคู่ไปกับน้ำหนักนั้น
ขั้นต่ำของการสำรวจ: 10% ไม่มีน้ำหนักของตัวแปรใดลดลงต่ำกว่า 10% ดังนั้นตัวแปรทุกตัวจะได้รับการเข้าชมและการกลับตัวยังคงตรวจพบได้
แบ่งเท่าๆ กันจนกว่าจะมีการส่งมอบ ≥100 ต่อตัวแปร น้ำหนักจะอยู่ที่การแยกที่กำหนดค่าไว้จนกว่าทุกตัวแปรจะมีการส่งมอบอย่างน้อย ~100 ครั้ง โดยไม่มีการจัดสรรใหม่บน Thin Data และไม่มีการประกาศ "ผู้ชนะ" ทางสถิติโดยกลไกนี้

การปกปิด LLM PII ที่ตะเข็บของผู้ให้บริการ

ก่อนที่ข้อความแจ้งเตือนใดๆ จะออกจาก Flash ไปยังผู้ให้บริการ LLM ภายนอก ตัวระบุส่วนบุคคลของสมาชิกจะถูกปิดบัง — ซึ่งใช้ในขั้นตอนการเชื่อมต่อของผู้ให้บริการ ดังนั้นฟีเจอร์ AI ทุกอย่างจึงผ่านไปได้:

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

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

สินค้าคงคลังแบบกล่องกระจก

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

แบบอย่าง	อำนาจ	ประตูแห่งความซื่อสัตย์
การยกระดับสองรุ่น (เหมาะกับลอจิสติกที่กำหนดสองแบบ)	SoClaw การจัดอันดับรายการงานแบบ win-back — มูลค่าที่มีความเสี่ยง × การยกระดับ ฝึกฝนเกี่ยวกับ RCT ที่ค้างอยู่ตลอดเวลาของโปรแกรม	เปิดใช้งานเฉพาะแถวที่ได้รับการบำบัดที่ครบกำหนดแล้ว ≥200 แถว แถวที่ระงับ ≥50 แถว และการแปลง ≥20 รายการ โดยที่ทั้งสองแถวมาบรรจบกันพอดี - หากต่ำกว่านั้น การจัดอันดับจะกลับไปอยู่ที่มูลค่าที่มีความเสี่ยงอย่างแท้จริง สมาชิกเชิงลบ (ห้ามรบกวน) จม; แต่ละงานจะเก็บภาพรวมคะแนนไว้
Gamma การซื้อระหว่างสมาชิกต่อสมาชิก (วิธีช่วงเวลา)	วันที่คาดว่าจะซื้อครั้งถัดไปในโปรไฟล์ + เงื่อนไขส่วน “จำนวนวันจนถึงวันที่คาดว่าจะซื้อครั้งถัดไป” (ค่าลบ = เกินกำหนด)	ต้องมีช่องว่างที่สังเกตได้ ≥3 ช่อง (เช่น การซื้อ ≥4 ครั้ง) และเกณฑ์สัมประสิทธิ์ความแปรปรวน (≤1.5) สำหรับความสม่ำเสมอของจังหวะ — ผู้ซื้อที่ไม่สม่ำเสมอจะได้รับค่า NULL ไม่ใช่วันที่ที่สร้างขึ้นเอง วันที่ที่คาดไว้ในอดีตจะถูกส่งออกเป็นสัญญาณล่าช้าที่แท้จริง
การถดถอยโลจิสติกแบบ L2-regularized ต่อทีม	แนวโน้มการคลิก (0–100) ปรับทุกคืนตามการส่ง 90 วันสุดท้ายของทีม	ป้ายกำกับเฉพาะคลิกเท่านั้น (ไม่เคยเปิดเลย — Apple MPP ขยายออก) คุณสมบัติการคลิกล่วงหน้าที่ป้องกันการรั่วไหล การไล่ระดับไล่ระดับแบบเต็มชุดที่กำหนดตามกำหนดเวลา พอดีเกต ≥500 ส่ง / ≥30คลิก / ≥50สมาชิก สมาชิกต้องการการส่งล่าสุด ≥3 ครั้งจึงจะให้คะแนน
รายการโคไซน์ที่ทำให้เป็นมาตรฐาน-kNN	การจับคู่ผลิตภัณฑ์ "ซื้อด้วย" บนพื้นผิวคำแนะนำ	co_count / √(buyers(A) × buyers(B)) แก้ไขอคติความนิยม; คู่ต้องมีผู้ซื้อร่วมกันอย่างน้อย 2 รายจึงจะเกิดขึ้นได้; จำนวนการซื้อร่วมกันดิบจะถูกจัดเก็บไว้พร้อมกับคะแนนเป็นหลักฐานที่ตรวจสอบได้
กฎสมาคม (สนับสนุน / ความมั่นใจ / ยก)	คำแนะนำการขายต่อ ซึ่งขุดได้ทุกคืนจากรายการสั่งซื้อของผู้ค้าเอง	กฎต้องมีคำสั่งซื้อที่เกิดขึ้นพร้อมกันอย่างน้อย 3 รายการและความมั่นใจอย่างน้อย 5%; ทุกกฎจะจัดเก็บจำนวนคำสั่งซื้อดิบที่ได้มา ดังนั้นจึงสามารถคำนวณตัวเลขใด ๆ ใหม่ได้ด้วยตนเอง พื้นผิวโปรไฟล์สมาชิกจะไม่รวมผลิตภัณฑ์ที่เป็นเจ้าของอยู่แล้วและแสดงเฉพาะผู้ซื้อที่ใช้งานอยู่
ค่าผิดปกติทางสถิติที่แข็งแกร่ง (ค่ามัธยฐาน / MAD)	เดอะ behavior_outlier เครื่องตรวจจับการฉ้อโกงคะแนน	z ที่แข็งแกร่ง ≥ 6 บวกกับค่าต่ำสุดสัมบูรณ์ (≥10 ธุรกรรมที่ได้รับ; ทีมที่มีสมาชิกใช้งานน้อยกว่า 50 คนจะถูกข้ามไป); การลบข้อมูลซ้ำซ้อนแบบแบ่งตามเดือนต่อสมาชิก; การระงับเท่านั้น — ระบบจะเปิดการตรวจสอบและจะไม่ยกเลิกโดยอัตโนมัติ
อันตรายตามสัดส่วนของ Kaplan-Meier + Cox (ความน่าจะเป็นบางส่วนของ Nelder-Mead)	การรักษาผู้ใช้ตามกลุ่มประชากรตามรุ่นการลงชื่อสมัครใช้รายเดือน + แผง "การรักษาผู้ใช้สัมพันธ์กับอะไร"	คำจำกัดความที่แสดงบนหน้าจอ: กลุ่มที่เลิกใช้บริการ (churn) = กลุ่มที่ไม่ได้ซื้อสินค้าเป็นเวลา 90 วัน โดยไม่รวมกลุ่มที่ไม่เคยซื้อสินค้า กลุ่มที่มีสมาชิกน้อยกว่า 30 คนจะถูกซ่อนและเปิดเผย การวิเคราะห์แบบ Cox fit ต้องการเหตุการณ์การเลิกใช้บริการที่สังเกตได้ ≥30 ครั้ง และจำกัดตัวแปรอิสระไว้ที่ 3 ตัว ตัวแปรที่เกี่ยวข้องจะถูกระบุว่าเป็นความสัมพันธ์ ไม่ใช่สาเหตุ
Holt-Winters (ฤดูกาลรายสัปดาห์ ค่าคงที่คงที่)	แนวโน้มรายได้ใน 14 วันข้างหน้าบนแดชบอร์ด	ค่าคงที่การปรับเรียบแบบตายตัว — ไม่มีการปรับแต่งเฉพาะทีม; อ่านค่าตัวชี้วัดรายได้ที่ได้รับการรับรองเหมือนกับหน้าจออื่นๆ ทุกหน้าจอ; เส้นประ + แถบแสดงข้อผิดพลาดพร้อมพิมพ์หน่วยเป็นดอลลาร์; ซ่อนไว้ทั้งหมดภายใต้ข้อมูลย้อนหลัง 4 สัปดาห์; ระบุว่าเป็นประมาณการ ไม่ใช่ข้อผูกมัด

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

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

ภาพรวมการกำกับดูแลและการอนุมัติของ AI MCP คู่มือการบูรณาการ SoClaw การรวม Win-Back กลับไปที่ศูนย์นักพัฒนา

สร้างคีย์ API