โมเดล Abliterated คืออะไร? อธิบายแบบเข้าใจง่าย

สรุปสั้นๆ

โมเดล abliterated คือโมเดลภาษา open-weight ธรรมดาที่มีการแก้ไขพฤติกรรมปฏิเสธออกโดยตรง โดยเปลี่ยนตัวเลขภายในโมเดลแทนที่จะฝึกใหม่หรือเขียน prompt ฉลาดๆ คำนี้ผสมคำว่า "ablation" (การตัดส่วนออกเพื่อดูว่ามันทำอะไร) กับ "obliteration" หลังจากแก้ไข โมเดลจะไม่ตอบว่า "ฉันช่วยเรื่องนั้นไม่ได้" สำหรับคำขอที่มันถูกสอนให้ปฏิเสธอีกต่อไป

มี 3 ประเด็นสำคัญที่ควรจดจำก่อนลงรายละเอียด:

• นี่คือการแก้ไขน้ำหนัก ไม่ใช่เทคนิคพรอมต์ ไม่มี jailbreak text ให้รักษา และไม่ใช้ context กับมัน
• มันลบพฤติกรรม ไม่ใช่ความรู้ โมเดลยังมีความรู้เดิม แต่หยุดปฏิเสธ
• ไม่ได้ฟรี การแก้ไขอาจกระทบคุณภาพทั่วไป ดังนั้นผู้สร้างโมเดลควรทดสอบผลลัพธ์และอาจทำ fine-tune ต่อเพื่อซ่อมแซมคุณภาพที่สูญเสียไป

ที่มาของแนวคิด

โมเดลแชทเรียนรู้ที่จะปฏิเสธระหว่างขั้นตอน post-training ผู้ติดป้ายกำกับข้อมูล (annotators) และ reward models ผลักดันให้โมเดลปฏิเสธคำขอบางประเภท และพฤติกรรมนี้ถูกฝังรวมไปกับความรู้ทุกอย่างที่โมเดลเรียนรู้มา เป็นเวลานานที่พฤติกรรมนี้ดูเหมือนจะกระจายอยู่ทั่วพารามิเตอร์หลายพันล้านตัว

บทความวิจัย Refusal in Language Models Is Mediated by a Single Direction แสดงสิ่งที่จัดการได้ง่ายกว่า ในโมเดลแชทแบบเปิดหลายตัว พฤติกรรมปฏิเสธส่วนใหญ่ถูกควบคุมโดยทิศทางเดียวใน activation space ภายในของโมเดล ดัน activations ไปตามทิศทางนั้นแล้วโมเดลจะปฏิเสธคำขอที่ไม่เป็นอันตรายด้วย ลบทิศทางนั้นออกแล้วมันจะหยุดปฏิเสธคำขอที่ปกติจะปฏิเสธ

ชุมชน open-source นำการค้นพบนี้มาสร้างเป็นสูตรปฏิบัติและตั้งชื่อให้ สูตรนี้เรียกว่า Abliteration คือการหาทิศทางปฏิเสธ แล้วทำให้โมเดลไม่สามารถใช้ทิศทางนั้นได้

หลักการทำงานของ Abliteration ทีละขั้นตอน

ขั้นตอนสั้นพอที่จะอธิบายในห้าขั้นตอน ไม่มีการ gradient descent จึงใช้ compute น้อยกว่าการฝึกโมเดลมาก

1. เก็บชุดพรอมต์สองชุด ชุดหนึ่งมีคำขอที่โมเดลปฏิเสธ อีกชุดมีคำขอที่โมเดลตอบ จำนวนหลายร้อยต่อชุดเป็นขนาดทั่วไป
2. บันทึก activations รันชุดทั้งสองผ่านโมเดลและบันทึก hidden state ที่เลเยอร์ที่เลือก มักที่โทเคนพรอมต์สุดท้าย
3. คำนวณทิศทาง หาค่าเฉลี่ยของการกระตุ้นของแต่ละชุด นำค่าเฉลี่ยของชุด "ตอบ" ลบออกจากค่าเฉลี่ยของชุด "ปฏิเสธ" แล้ว normalize ผลลัพธ์ เวกเตอร์ที่ได้คือทิศทางปฏิเสธ
4. กำจัดทิศทางนั้นด้วยการโปรเจกต์ สามารถลบทิศทางออกขณะรันไทม์ หรือแก้ไข weight matrices ที่เขียนเข้าสู่ residual stream (embeddings, attention outputs, MLP outputs) เพื่อให้ไม่สามารถสร้างองค์ประกอบตามทิศทางนั้นได้ ตัวเลือกที่สองเป็นการแก้ไขถาวรและเป็นสิ่งที่ checkpoint แบบ abliterated ส่วนใหญ่ใช้
5. ทดสอบ รัน held-out prompts เปรียบเทียบอัตราการปฏิเสธก่อนและหลัง และตรวจสอบงานทั่วไปเช่น reasoning และ coding เพื่อหา regressions

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

เปรียบเทียบ Abliteration กับวิธีอื่น

มีสามวิธีทั่วไปที่ทำให้โมเดลหยุดปฏิเสธ วิธีเหล่านี้แตกต่างกันที่สิ่งที่เปลี่ยนแปลงและจุดที่มักล้มเหลว

แนวทาง	สิ่งที่เปลี่ยนแปลง	ต้นทุน	จุดอ่อนทั่วไป
Jailbreak prompt	เฉพาะข้อความ input	ไม่มี แต่ใช้ context ทุกครั้งที่เรียก	เปราะบาง; อัปเดตโมเดลเพียงครั้งเดียวก็หยุดทำงาน
Fine-tune บนข้อมูลที่ไม่มีข้อจำกัด	น้ำหนักโมเดล ผ่านการเทรน	ชั่วโมง GPU และชุดข้อมูลที่ผ่านการคัดสรร	คุณภาพของชุดข้อมูลเป็นตัวกำหนดทุกอย่าง; สไตล์การเขียนอาจเพี้ยนไปได้
Abliteration	น้ำหนักโมเดล ผ่านการแก้ไขโดยตรง	ต่ำเมื่อเทียบกับการเทรน	ทิศทางนั้นเป็นการประมาณค่า ดังนั้นคุณภาพอาจลดลงได้

โมเดลสำเร็จรูปจำนวนมากใช้หลายวิธีร่วมกัน รูปแบบทั่วไปคือทำ abliteration ก่อน แล้วรันการ fine-tune สั้นๆ เพื่อฟื้นฟูคุณภาพที่เสียไปจากการแก้ไข เมื่ออ่าน model card ให้ดูว่าใช้ขั้นตอนใดบ้าง และผู้เขียนรายงานผลการทดสอบก่อน-หลังหรือไม่

สิ่งที่ต้องเสียไปและสิ่งที่ควรระวัง

การลบการปฏิเสธไม่ได้ทำให้โมเดลเก่งขึ้นในสิ่งใดเลย มันแค่เอาตัวกรองออก ผลที่ตามมาคือ

คุณภาพอาจลดลง

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

การตัดสินเป็นของคุณแล้ว

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

ข้อผิดพลาดยังคงเกิดขึ้นได้

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

โมเดลที่อยู่เบื้องหลัง API นี้ทำงานอย่างไร

บทความนี้อธิบายวิธีการในภาพรวม สิ่งที่ API มอบให้คุณคือโมเดล open-weight โมเดลหนึ่ง ที่ให้บริการโดยผู้ให้บริการอิสระ ซึ่งปรับแต่งให้ตอบโดยไม่มีการปฏิเสธเนื้อหาสำหรับการใช้งานผู้ใหญ่ที่ถูกต้องตามกฎหมาย ไม่ใช่ API ทางการของ Meta, Mistral, Qwen, DeepSeek, OpenAI หรือผู้ขายรายอื่น และไม่ใช่ router ที่เชื่อมต่อกับหลายราย รองรับเฉพาะข้อความ: ไม่มีรูปภาพ เสียง embedding หรือการ fine-tuning

อินเทอร์เฟซเข้ากันได้กับ OpenAI ชี้ SDK ของ OpenAI ไปที่ https://api.abliteratedmodels.cc/v1 ใช้ model ID uncensored และส่งคีย์ของคุณเป็น Bearer token:

Copycurl https://api.abliteratedmodels.cc/v1/chat/completions \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "uncensored",
    "messages": [
      {"role": "user", "content": "Explain directional ablation in two sentences."}
    ]
  }'

การเรียกใช้เดียวกันใน Python ด้วย SDK ทางการ:

Copyfrom openai import OpenAI

client = OpenAI(
    base_url="https://api.abliteratedmodels.cc/v1",
    api_key="YOUR_KEY",
)

reply = client.chat.completions.create(
    model="uncensored",
    messages=[{"role": "user", "content": "What does a refusal direction mean?"}],
)
print(reply.choices[0].message.content)

context window คือ 100,000 tokens นับ prompt และ completion รวมกัน การสตรีมมิง การเรียกใช้ฟังก์ชัน และโหมด JSON ทำงานเหมือนใน API ของ OpenAI รายละเอียดอยู่ใน เอกสาร API

ตำนานทั่วไปเกี่ยวกับโมเดลแบบ abliterated

มีความคิดบางอย่างที่แพร่หลายเกี่ยวกับโมเดลเหล่านี้ซึ่งควรแก้ไข เพราะนำไปสู่ความคาดหวังที่คลาดเคลื่อน

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

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

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

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

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

ใครคือกลุ่มที่จำเป็นต้องใช้

ผู้ใช้ส่วนใหญ่ไม่เคยเจอการปฏิเสธ (refusal) แต่ผู้ที่เจอมักจะอยู่ในกลุ่มต่อไปนี้:

• นักเขียนนิยายและบทบาทสมมติ ธีมมืด ตัวร้ายที่น่าเกรงขาม และฉากที่ความถูกต้องทางศีลธรรมคลุมเครือเป็นเรื่องปกติในวรรณกรรม โมเดลที่ผ่านการปรับแต่งมักจะลดทอนหรือปฏิเสธเนื้อหาเหล่านี้ แอปคู่หู (companion)และเรื่องราวสำหรับผู้ใหญ่ก็เจอปัญหาเดียวกัน
• ทีมรักษาความปลอดภัยและทีม Red Team การเขียน payload ทดสอบ การอธิบายการทำงานของ exploit chain หรือการวิเคราะห์ตัวอย่างมัลแวร์ อาจไปกระตุ้นตัวกรองที่ออกแบบมาสำหรับผู้ใช้ทั่วไป
• ทีม moderation และวิจัย เพื่อสร้าง classifier สำหรับข้อความที่เป็นอันตราย คุณบางครั้งต้องการโมเดลที่จะผลิตตัวอย่าง หรือที่จะพูดคุยเกี่ยวกับมันโดยไม่เกร็ง
• นักพัฒนาที่เหนื่อยกับลูปการเรียกซ้ำ หากครึ่งหนึ่งของ pipeline ของคุณต้องจับการปฏิเสธและปรับคำใหม่ การกำจัดสิ่งเหล่านี้จะช่วยให้โค้ดง่ายขึ้น

หากคุณกำลังชั่งน้ำหนักระหว่างต้นทุนและการควบคุมกับโมเดลที่โฮสต์แบบปรับแต่งแล้ว หน้า ต้นทุนเทียบกับการควบคุมของ LLM API แบบไม่เซ็นเซอร์ จะอธิบายรายละเอียด ราคาเป็นอัตราคงที่: $0.15 ต่อหนึ่งล้านโทเคนอินพุต และ $0.50 ต่อหนึ่งล้านโทเคนเอาต์พุต โดยคำขอที่ล้มเหลวหรือถูกปฏิเสธจะไม่ถูกเรียกเก็บเงิน ดู หน้าราคา สำหรับจำนวนเงินเติมเงินและโบนัส

ลองใช้โดยไม่เสียเงิน

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

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

คู่มือเพิ่มเติม

• โมเดล abliterated ที่ดีที่สุดสำหรับการเขียนโค้ด: สิ่งที่ต้องพิจารณา
• API LLM แบบไม่เซ็นเซอร์: การวิเคราะห์ต้นทุน vs การควบคุม