คุณจะไว้วางใจตัวแทนปัญญาประดิษฐ์ด้านการเดินเรือได้หรือไม่ เมื่อคำตอบที่ผิดอาจเป็นอันตรายต่อบุคลากร?

การสร้าง ตัวแทน AI ทางทะเลที่น่าเชื่อถือ กลับกลายเป็นเรื่องของการออกแบบระบบมากกว่าการเลือกโมเดล นั่นคือบทเรียนสำคัญที่ Skylight ได้จากการพัฒนา Shippy ตัวแทน AI ที่สร้างขึ้นมาโดยเฉพาะสำหรับการรับรู้สถานการณ์ทางทะเลแบบเรียลไทม์ (maritime domain awareness) — ซึ่งเป็นโดเมนที่คำตอบที่ผิดไม่ใช่แค่ทำให้ผู้ใช้หงุดหงิด แต่สามารถสั่งให้เรือตรวจการณ์ออกนอกเส้นทางไปหลายไมล์ สูบทรัพยากรที่มีจำกัด และอาจทำให้บุคลากรตกอยู่ในอันตรายได้

ประเด็นสำคัญ

• Shippy เป็นตัวแทน AI ที่สร้างโดย Skylight สำหรับการรับรู้สถานการณ์ทางทะเลแบบเรียลไทม์ ใช้ในการถามตอบเกี่ยวกับพฤติกรรมเรือ ขอบเขต EEZ และ MPA และเส้นทางการเดินเรือ
• สถาปัตยกรรมของมันถูกจัดโครงสร้างรอบองค์ประกอบสามส่วน: soul (พรอมต์ระบบ), skills (การจัดการงาน), และ config (การตั้งค่ารันไทม์รวมถึงการใช้ Claude Opus 4.6)
• Shippy สื่อสารกับ API ของ Skylight ผ่าน CLI แบบกำหนดผลลัพธ์ได้ที่สร้างขึ้นเพื่อจุดประสงค์นี้ โดยกำจัดรูปแบบข้อผิดพลาดที่เกิดขึ้นเมื่อให้โมเดลสร้างคำเรียก API ดิบโดยตรง
• แต่ละเซสชันของผู้ใช้ทำงานใน Kubernetes sandbox เฉพาะที่จัดเตรียมโดย Mothership ทำให้มั่นใจได้ว่ามีการแยกข้อมูลอย่างสมบูรณ์ระหว่างลูกค้าหน่วยงานรัฐและ NGO หลายร้อยรายของ Skylight
• การประเมินอาศัยกรอบงานที่อิงภารกิจและรูบริก โดยมี LLM ทำหน้าที่เป็นผู้ตัดสินให้คะแนนคำตอบเทียบกับข้อมูลสด — เป็นการตั้งใจเบี่ยงออกจาก benchmark แบบสแตติก

เหตุใดการรับรู้สถานการณ์ทางทะเลจึงยกระดับมาตรฐานความน่าเชื่อถือ

เครื่องมือ AI ส่วนใหญ่ทำงานในสภาพแวดล้อมที่คำตอบระดับปานกลางเป็นเพียงแค่ไม่ช่วยอะไรเท่านั้น แต่ การปฏิบัติการทางทะเล นั้นต่างออกไป Skylight ให้บริการ หน่วยงานรัฐและ NGO หลายร้อยแห่งในกว่า 70 ประเทศ ตั้งแต่การบังคับใช้กฎหมายประมงไปจนถึง การติดตามการอนุรักษ์ เมื่อเจ้าหน้าที่วิเคราะห์ในบริบทนั้นถามว่าเรือกำลัง ปฏิบัติการอย่างผิดกฎหมายภายในเขตพื้นที่คุ้มครองทางทะเลหรือไม่ ความเสี่ยงจากคำตอบที่หลอนหรือไม่แม่นยำจะเป็นเรื่องเร่งด่วนและเชิงปฏิบัติการทันที

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

สถาปัตยกรรมของ Shippy: soul, skills และ config

Skylight อธิบายตัวแทน AI ทางทะเล Shippy ผ่านสามเลเยอร์ที่แตกต่างกัน: soul, skills และ config ความแตกต่างนี้สำคัญกว่าที่อาจดูในตอนแรก

soul คือพรอมต์ระบบ — มันกำหนดบุคลิกของ Shippy และตั้งขอบเขตพฤติกรรมที่เข้มงวด ว่า Shippy จะทำอะไร และที่สำคัญคือจะไม่ทำอะไร soul มีความชัดเจนและตรวจสอบได้: Shippy จะไม่ตัดสินทางกฎหมายว่าเรือกำลังทำผิดกฎหมายหรือไม่ และจะไม่คาดเดาเกินกว่าที่ข้อมูลรองรับ สิ่งเหล่านี้ไม่ใช่ราวกั้นแบบนุ่มที่ฝังอยู่ในกระบวนการ fine-tune แต่เขียนไว้โดยตรงในพรอมต์ระบบ ทำให้ตรวจสอบและแก้ไขได้ง่าย

Skills บอก Shippy ว่าจะจัดการกับคำขอประเภทต่าง ๆ อย่างไร พวกมันใช้สเปก agent-skills แบบเดียวกับที่ใช้ในเครื่องมือเขียนโค้ดอย่าง Claude Code และ Codex — เป็นไฟล์ markdown ธรรมดาที่มี frontmatter แบบมีโครงสร้าง ทำให้แต่ละสกิลมีเวอร์ชันและเข้าใจได้ง่าย ชุดสกิลปัจจุบันของ Shippy รวมถึง:

• การค้นหา API ของ Skylight เพื่อดูพฤติกรรมและเหตุการณ์ของเรือ (การทำประมง การถ่ายโอนสินค้าระหว่างเรือ)
• การค้นหาขอบเขตเขตเศรษฐกิจจำเพาะ (EEZ) และเขตพื้นที่คุ้มครองทางทะเล (MPA)
• การตีความข้อมูลเส้นทางเรือและสัญญาณตำแหน่ง โดยต่อยอดจากการจัดประเภทกิจกรรมที่โมเดลของ Skylight เองสร้างขึ้นแล้ว
• การสร้างลิงก์แผนที่แบบโต้ตอบเพื่อให้เจ้าหน้าที่วิเคราะห์กระโดดจากคำตอบในแชตไปยังตำแหน่งที่แน่นอนบนแผนที่ของ Skylight

คำถามของผู้ใช้เพียงคำถามเดียวสามารถเรียกใช้หลายสกิลพร้อมกันได้ ถ้าถามว่าเรือกำลังปฏิบัติการใกล้เขต MPA Cordillera de Coiba หรือไม่ Shippy จะดึงข้อมูลจากสกิลค้นหาข้อมูลของ Skylight ฐานข้อมูลขอบเขตของ ProtectedSeas และสกิลตีความเส้นทางเรือ — ทั้งหมดนี้ภายในรอบการสนทนาเดียว

Config และคำถามเรื่องโมเดล

เลเยอร์ config จัดการทุกอย่างที่เกี่ยวกับรันไทม์: จะรัน agent harness ตัวไหน ใช้ LLM ตัวใด และความลับที่ฉีดเข้าไปอย่างคีย์ API ต่าง ๆ ปัจจุบัน Shippy ทำงานบน Claude Opus 4.6 ในฐานะโมเดลภาษาขนาดใหญ่ ที่สำคัญคือ การสลับโมเดลพื้นฐานเป็นเพียงการเปลี่ยน config ไม่ใช่การสร้างใหม่ — soul และ skills ถูกบรรจุอยู่ในอิมเมจ Docker แยกจากกัน ทำให้ทีมมีความยืดหยุ่นในการส่งคำถามประเภทต่าง ๆ ไปยังโมเดลที่ต่างกันเมื่อระบบพัฒนาไป

เครื่องมือแบบกำหนดผลลัพธ์ได้สำหรับตัวแทนที่ไม่กำหนดผลลัพธ์ตายตัว

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

ทางออกคือ CLI แบบกำหนดผลลัพธ์ได้ที่สร้างขึ้นเพื่อจุดประสงค์นี้ แทนที่จะสร้างคำเรียก API ดิบ Shippy จะสั่งเพียงคำสั่งเดียว — ตัวอย่างเช่น skylight events search พร้อมแฟลกตัวกรองแบบมีชนิด — แล้ว CLI จะจัดการการยืนยันตัวตน การแบ่งหน้า และเอาต์พุตแบบมีโครงสร้าง CLI มีเอกสารในตัวเอง พร้อมข้อความช่วยเหลือและข้อความแสดงข้อผิดพลาดอย่างละเอียดที่ช่วยให้ตัวแทนฟื้นจากความผิดพลาดได้โดยไม่ต้องเดา ผลลัพธ์จะถูกเขียนลงไฟล์ JSON ภายในเครื่องเสมอแทนที่จะส่งผ่าน shell ทำให้หลีกเลี่ยงข้อจำกัดของบัฟเฟอร์ pipe ที่เคยสร้างปัญหากับชุดผลลัพธ์ขนาดใหญ่ในต้นแบบช่วงแรก

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

Kubernetes sandboxing และความท้าทายด้านการแยกข้อมูล

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

ทางออกคือ Mothership แพลตฟอร์มโฮสต์ตัวแทนของ Skylight Mothership จัดเตรียม Kubernetes deployment เฉพาะสำหรับแต่ละเซสชันของผู้ใช้ เมื่อการสนทนาเริ่มขึ้น ระบบจะสปินชุดของพ็อดที่บรรจุรันไทม์ของตัวแทน สกิลต่าง ๆ และ Skylight CLI โทเค็น JWT ของผู้ใช้จะถูกฉีดเข้าไปในตอนจัดเตรียม ทำให้คำเรียก API ทั้งหมดถูกจำกัดอยู่กับข้อมูลของผู้ใช้นั้น ไฟล์ที่ตัวแทนเขียนระหว่างการวิเคราะห์หลายขั้นตอนจะมีอยู่เฉพาะในเซสชันนั้นและไม่สามารถเข้าถึงข้ามผู้ใช้ได้เลย

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

การประเมินตัวแทนในบริบทการปฏิบัติการจริง

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

กรอบงานแบบรูบริกพร้อม LLM ผู้ตัดสิน

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

ไปป์ไลน์จะรันพรอมต์ภาษาธรรมชาติผ่าน sandbox สด และ LLM ผู้ตัดสินจะให้คะแนนแต่ละเกณฑ์ในสเกล 0 ถึง 1 พร้อมเหตุผลเป็นลายลักษณ์อักษรอธิบายว่าทำไมคำตอบจึงผ่านหรือไม่ผ่านเกณฑ์นั้น จากนั้นจะตรวจสอบผลรวมแบบถ่วงน้ำหนักเทียบกับเกณฑ์ผ่านที่กำหนดตายตัว งานต่าง ๆ จะรันผ่าน Harbor ซึ่งเป็นเฟรมเวิร์กประเมินแบบเปิด ผ่านปลั๊กอินที่ Skylight สร้างขึ้นซึ่งสปินเซสชัน Shippy จริงกับข้อมูลสดชุดเดียวกับที่ผู้ใช้จะเจอ

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

สิ่งที่จะตามมาสำหรับ Shippy — และไกลกว่านั้น

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

นัยยะที่กว้างกว่า ขยายออกไปไกลกว่าการใช้งานทางทะเล Mothership ถูกออกแบบให้ไม่ผูกกับโดเมนใดโดเมนหนึ่ง และองค์กรแม่ของ Skylight อย่าง Ai2 ก็กำลังนำบทเรียนจาก Shippy ไปใช้กับ EarthRanger แพลตฟอร์มอนุรักษ์สัตว์ป่า และ OlmoEarth ชุดเครื่องมือสังเกตโลกแบบเปิด สถาปัตยกรรม — soul, skills, config, เครื่องมือแบบกำหนดผลลัพธ์ได้, sandbox แบบแยกตามเซสชัน และการประเมินด้วยข้อมูลสด — เป็นพิมพ์เขียวสำหรับการปรับใช้ตัวแทน AI ในทุกโดเมนที่ต้นทุนของคำตอบผิดถูกวัดด้วยสิ่งอื่นที่ไม่ใช่แค่ความหงุดหงิดของผู้ใช้

คำถามที่พบบ่อย

Shippy ถูกออกแบบมาเพื่อทำอะไร?

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

Shippy ทำให้มั่นใจได้อย่างไรว่าตอบคำถามได้อย่างน่าเชื่อถือ?

Shippy ใช้ CLI แบบกำหนดผลลัพธ์ได้เพื่อจัดการคำเรียก API ทั้งหมดของ Skylight หลีกเลี่ยงรูปแบบข้อผิดพลาดที่เกิดขึ้นเมื่อให้โมเดลสร้างคำเรียก API ดิบโดยตรง เมื่อรวมกับสถาปัตยกรรมแบบโมดูลาร์ — soul, skills และ config — และขอบเขตพฤติกรรมที่เข้มงวดในพรอมต์ระบบ การออกแบบจึงให้ความสำคัญกับพฤติกรรมที่คาดเดาได้และตรวจสอบได้มากกว่าความยืดหยุ่น

Shippy ถูกประเมินด้านความแม่นยำและความน่าเชื่อถืออย่างไร?

Skylight สร้างกรอบงานประเมินแบบกำหนดเองที่ผู้เชี่ยวชาญเฉพาะด้านเขียนสถานการณ์ภารกิจและรูบริกแบบถ่วงน้ำหนัก LLM ผู้ตัดสินจะให้คะแนนคำตอบของตัวแทนแต่ละข้อเทียบกับข้อมูลสดในสเกล 0 ถึง 1 ต่อเกณฑ์ พร้อมเหตุผลเป็นลายลักษณ์อักษร ผลรวมแบบถ่วงน้ำหนักจะถูกตรวจสอบเทียบกับเกณฑ์ผ่านที่กำหนดตายตัว และเวอร์ชันใดของ Shippy ที่ถดถอยในเกณฑ์การประเมินจะไม่ถูกส่งถึงผู้ใช้ปลายทาง

Shippy จัดการการตัดสินทางกฎหมายเกี่ยวกับกิจกรรมของเรือหรือไม่?

ไม่ Shippy หลีกเลี่ยงอย่างชัดเจนในการตัดสินทางกฎหมายว่าเรือกำลังละเมิดกฎหมายใด ๆ หรือไม่ และจะไม่คาดเดาเกินกว่าที่ข้อมูลรองรับ การตัดสินเหล่านั้นถูกปล่อยให้เป็นหน้าที่ของเจ้าหน้าที่วิเคราะห์มนุษย์ ขีดจำกัดเหล่านี้ถูกเขียนไว้โดยตรงในพรอมต์ระบบ — ทำให้ตรวจสอบและปรับได้ — แทนที่จะเป็นนัยอยู่ในกระบวนการ fine-tune โมเดล

{“@context”:”https://schema.org”,”@type”:”FAQPage”,”mainEntity”:[{“@type”:”Question”,”name”:”Shippy ถูกออกแบบมาเพื่อทำอะไร?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Shippy เป็นตัวแทน AI ที่พัฒนาโดย Skylight สำหรับการรับรู้สถานการณ์ทางทะเลแบบเรียลไทม์ มันช่วยให้เจ้าหน้าที่วิเคราะห์สอบถามเกี่ยวกับพฤติกรรมของเรือ ค้นหาขอบเขตเขตเศรษฐกิจจำเพาะและเขตพื้นที่คุ้มครองทางทะเล ตีความข้อมูลเส้นทางเรือ และสร้างลิงก์แผนที่แบบโต้ตอบที่ผูกโดยตรงกับแพลตฟอร์มข้อมูลสดของ Skylight.”}},{“@type”:”Question”,”name”:”Shippy ทำให้มั่นใจได้อย่างไรว่าตอบคำถามได้อย่างน่าเชื่อถือ?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Shippy ใช้ CLI แบบกำหนดผลลัพธ์ได้เพื่อจัดการคำเรียก API ทั้งหมดของ Skylight หลีกเลี่ยงรูปแบบข้อผิดพลาดที่เกิดขึ้นเมื่อให้โมเดลสร้างคำเรียก API ดิบโดยตรง เมื่อรวมกับสถาปัตยกรรมแบบโมดูลาร์ — soul, skills และ config — และขอบเขตพฤติกรรมที่เข้มงวดในพรอมต์ระบบ การออกแบบจึงให้ความสำคัญกับพฤติกรรมที่คาดเดาได้และตรวจสอบได้มากกว่าความยืดหยุ่น.”}},{“@type”:”Question”,”name”:”Shippy ถูกประเมินด้านความแม่นยำและความน่าเชื่อถืออย่างไร?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”Skylight สร้างกรอบงานประเมินแบบกำหนดเองที่ผู้เชี่ยวชาญเฉพาะด้านเขียนสถานการณ์ภารกิจและรูบริกแบบถ่วงน้ำหนัก LLM ผู้ตัดสินจะให้คะแนนคำตอบของตัวแทนแต่ละข้อเทียบกับข้อมูลสดในสเกล 0 ถึง 1 ต่อเกณฑ์ พร้อมเหตุผลเป็นลายลักษณ์อักษร ผลรวมแบบถ่วงน้ำหนักจะถูกตรวจสอบเทียบกับเกณฑ์ผ่านที่กำหนดตายตัว และเวอร์ชันใดของ Shippy ที่ถดถอยในเกณฑ์การประเมินจะไม่ถูกส่งถึงผู้ใช้ปลายทาง.”}},{“@type”:”Question”,”name”:”Shippy จัดการการตัดสินทางกฎหมายเกี่ยวกับกิจกรรมของเรือหรือไม่?”,”acceptedAnswer”:{“@type”:”Answer”,”text”:”ไม่ Shippy หลีกเลี่ยงอย่างชัดเจนในการตัดสินทางกฎหมายว่าเรือกำลังละเมิดกฎหมายใด ๆ หรือไม่ และจะไม่คาดเดาเกินกว่าที่ข้อมูลรองรับ การตัดสินเหล่านั้นถูกปล่อยให้เป็นหน้าที่ของเจ้าหน้าที่วิเคราะห์มนุษย์ ขีดจำกัดเหล่านี้ถูกเขียนไว้โดยตรงในพรอมต์ระบบ — ทำให้ตรวจสอบและปรับได้ — แทนที่จะเป็นนัยอยู่ในกระบวนการ fine-tune โมเดล.”}}]}

บทความนี้จัดทำขึ้นโดยได้รับความช่วยเหลือจากปัญญาประดิษฐ์และผ่านการทบทวนโดยทีมบรรณาธิการแล้ว