ไล่ตระกูล INT ที่ต้องเอามาประกอบกับ sensor ตั้งแต่ OSINT HUMINT GEOINT MASINT ยัน FININT พร้อมเครื่องมือภาคสนามอย่างแอป Gather แพลตฟอร์มแบ่งปันข้อมูลอย่าง IORIS ฟอร์มตรวจค้น ไปจนถึงการหลอมทุกอย่างออกมาเป็น heat map ความเสี่ยง
ฮัลโหลโหม๋ ตอนที่ 4 เราเพิ่งปิดกันไปด้วยประโยคที่ค่อนข้างกวนว่า คำว่า dark ไม่เคยเป็นคุณสมบัติของเรือ แต่เป็นคุณสมบัติของช่องว่างในระบบเรา แล้วก็ทิ้งท้ายไว้ว่าพอระบบชี้มาที่เรือลำหนึ่งได้แล้ว คำถามถัดไปที่ตามมาทันทีคือ ใครเป็นเจ้าของ มันมาทำอะไรแถวนี้ และเคยทำแบบนี้มาก่อนกี่ครั้ง
ลองไล่ของที่เรามีในมือจากสี่ตอนที่ผ่านมาดูนะฮะ — ตอนที่ 1 เป็น Signal Chain กับ AIS, ตอนที่ 2 เป็นเรดาร์ชายฝั่งกับกล้อง EO/IR, ตอนที่ 3 เอาทุกอย่างมาหลอมจนเรือหนึ่งลำเหลือหมุดเดียว และตอนที่ 4 เป็น RF, SAR, EO/IR จากวงโคจร บวก Machine Learning ทั้งกอง
ทั้งสี่ตอนคืนของออกมาหน้าตาเดียวกันหมด คือ จุดหนึ่งจุดที่มีพิกัด มีเวลา และมีวงความไม่แน่นอน ซึ่งเก่งมากในการตอบว่า "มีอะไรอยู่ตรงนั้น" แต่ถ้าถามว่าเจ้าของเป็นใคร จดทะเบียนที่ไหน ปีที่แล้วเคยโดนตรวจมากี่รอบ — ไม่มี sensor ตัวไหนในกองนั้นตอบได้สักตัว เพราะคำตอบพวกนั้นไม่ได้ลอยอยู่ในคลื่นวิทยุหรือฝังอยู่ในพิกเซล มันอยู่ในทะเบียน ในเอกสาร และในหัวของคน
ตอนที่ 5 เลยว่าด้วยของที่เหลือทั้งหมดนั่นแหละ ทั้งตระกูล INT ที่ต้องเอามาประกอบ เครื่องมือของแต่ละตระกูล แพลตฟอร์มที่เอาไว้แบ่งปันกันข้ามหน่วยงาน ไปจนถึงฟอร์มบ้านๆ ที่เจ้าหน้าที่กรอกบนเรือที่กำลังโคลง ตอนนี้โค้ดมีก้อนเดียวและเป็น JSON ด้วยซ้ำ ที่เหลือเป็นแผนภาพกับตัวอย่างล้วนๆ
วงการข่าวเขาแบ่งข้อมูลตาม วิธีที่ได้มันมา ไม่ได้แบ่งตามเนื้อหา แล้วลงท้ายด้วย INT ซึ่งย่อมาจาก intelligence เหมือนกันหมด ทีนี้พอเอาไม้บรรทัดอันนี้มาทาบกับสี่ตอนที่ผ่านมา จะเห็นว่าเราวนอยู่ในกล่องไม่กี่ใบเอง
แปลว่าสี่ตอนที่ลงแรงกันมาทั้งหมด จริงๆ แล้วคือ SIGINT บวก IMINT บวก MASINT นิดหน่อย จบ ที่เหลือของโลกนี้เรายังไม่ได้แตะเลยสักตระกูล
นึกภาพห้องตรวจของหมอก็ได้ ฟิล์ม X-ray บอกว่ากระดูกตรงนี้ร้าว ผลเลือดบอกว่าค่าตัวนี้สูงผิดปกติ เครื่องวัดบอกว่าความดันเท่าไหร่ — ของพวกนี้คือ sensor ทั้งดุ้น แต่ที่หมอต้องรู้ให้ได้ว่า คนไข้คนนี้แพ้ยาอะไร กินยาอะไรค้างอยู่ และปีที่แล้วเคยผ่าอะไรมา ไม่มีเครื่องไหนในห้องนั้นตอบให้ มันมาจากการนั่งซักประวัติกับแฟ้มเก่าที่โรงพยาบาลเก็บไว้เท่านั้น
ไล่ทีละตระกูลพร้อมของที่ต้องมีในมือ
ทีนี้ของทั้งหกกองนี้ไม่ได้อยู่กันเฉยๆ มันหมุนอยู่ในวงเดียวกัน คือ Intelligence Cycle ที่เล่าไว้ในบทความ MDA ตั้งแต่ตอนโน้น ห้าขั้นเป๊ะ — ตั้งโจทย์, ไปเก็บ, เอามาเรียง, วิเคราะห์, แล้วส่งต่อ พอส่งต่อเสร็จก็เกิดคำถามใหม่ วนกลับขั้นหนึ่ง
จุดที่คนทำระบบพลาดกันบ่อยสุดคือ เราเก่งขั้นเดียว คือ Collection เรามีความสุขมากกับการต่อ sensor เพิ่ม ดูด feed เพิ่ม เก็บทุกอย่างเข้าฐานข้อมูล แต่ขั้นแรกกับขั้นสุดท้ายเรามักไม่แตะ ขั้นแรกคือ Planning & Direction ที่ต้องตอบให้ได้ว่า "ตกลงเราอยากรู้อะไร" ถ้าตอบไม่ได้ คำว่า "เก็บไว้ก่อน เผื่อได้ใช้" จะกลายเป็นนโยบายเดียวที่เรามี ส่วนขั้นสุดท้ายคือ Dissemination ที่แปลว่าของต้องไปถึงคนที่ต้องใช้ ทันเวลาที่เขายังใช้ได้ รายงานสวยงามที่ส่งถึงมือหลังเรือออกจากพื้นที่ไปแล้วสามวัน มีค่าเท่ากับไม่ได้ทำ
อีกเรื่องที่โครงการชอบลืมคือ แต่ละแหล่งมีราคาไม่เท่ากัน เหมือนตอนจะซื้อรถมือสองสักคัน เลื่อนดูรูปในประกาศฟรี โทรถามเจ้าของเก่าก็ฟรี แต่ถ้าจะยกขึ้นแท่นให้ช่างไล่ตรวจทั้งคัน อันนั้นจ่ายตังค์บวกเสียวันหยุดไปหนึ่งวัน — ภาพ SAR หนึ่งฉากก็คิดเงินเป็นภาพ การส่งเรือออกไปตรวจค้นหนึ่งเที่ยวมีทั้งค่าน้ำมัน เวลา และความปลอดภัยของคนบนเรือ ขั้น Planning ที่ดีจึงไม่ใช่การสั่งเก็บทุกอย่าง แต่คือการเลือกว่าคำถามข้อนี้คุ้มที่จะใช้ตระกูลไหนตอบ
มาถึงตระกูลที่ตอนที่แล้วติดค้างไว้ว่าจะเล่ายาวๆ ตอนนี้
เหตุผลที่ HUMINT ยังไม่ตายแม้ดาวเทียมจะเยอะขนาดไหนมีสามข้อ หนึ่งคือมันถูกที่สุดในกองทั้งหมด ชาวประมงออกทะเลอยู่แล้วทุกวันโดยที่เราไม่ต้องจ่ายค่าวงโคจร สองคือมันตอบ "ทำไม" ได้ ซึ่งเป็นคำถามที่ไม่มี sensor ตัวไหนตอบได้เลย และสามคือมันเห็นของที่อยู่ ข้างใน เรือ ดาวเทียมเห็นแค่หลังคา แต่คนที่ขึ้นไปยืนบนดาดฟ้าเห็นทั้งของในห้องเย็น เครื่องมือประมงที่พับเก็บอยู่ และสภาพความเป็นอยู่ของลูกเรือ
ปัญหาคลาสสิกของ HUMINT ไม่ใช่การหาคน แต่คือ ข้อมูลตายอยู่บนกระดาษ ภาพที่เจอกันทั่วโลกคือเจ้าหน้าที่จดลงแบบฟอร์มกระดาษกลางทะเล กลับถึงฝั่งอีกสองวัน แล้วอีกสัปดาห์ถึงมีคนเอามาพิมพ์เข้า Excel ระหว่างทางลายมือหายไปหนึ่งตัว พิกัดที่จดจากจอ GPS ตกไปหนึ่งหลัก และรูปถ่ายอยู่ในมือถือส่วนตัวของคนที่ย้ายหน่วยไปแล้ว พอถึงวันที่มีคนถามว่าปีที่แล้วเราตรวจเรือในอ่าวนี้ไปกี่ลำ คำตอบคือเงียบ
ของที่เข้ามาแก้ตรงนี้คือชุดเครื่องมือที่เรียกกันว่า FIST (Field Information Supporting Tools) — อุปกรณ์เก็บข้อมูลภาคสนามที่อาจจะเป็นแค่มือถือเครื่องหนึ่งที่ลง App ที่บางครั้งจะเรียกว่า Gather ไว้ ให้คนเก็บข้อมูลกรอกตรงจุดที่เกิดเรื่อง แล้วส่งขึ้น server แบบ sync เมื่อมีสัญญาณ ไม่ใช่ตอนกรอก
หลักคิดของงานแบบนี้มีคำเดียวคือ offline-first ซึ่งแปลตรงตัวว่าออกแบบโดยถือว่า "ไม่มีเน็ต" เป็นสถานะปกติ ไม่ใช่กรณีผิดพลาด ของที่ต้องมีคือ
ส่วนเรื่องฟอร์ม เลาอยากให้จำประโยคเดียวคือ ฟอร์มที่กรอกยาก เท่ากับข้อมูลมั่ว ไม่ใช่เท่ากับข้อมูลน้อยนะ คนหน้างานไม่ได้เลิกกรอก เขากรอกอะไรก็ได้ให้มันผ่านไปต่างหาก ซึ่งแย่กว่าเยอะ
เพราะงั้นฟอร์มที่จะไปอยู่บนเรือที่โคลงต้องปุ่มใหญ่พอจะกดด้วยนิ้วโป้งมือเดียวขณะอีกมือจับราว ต้องเป็นตัวเลือกให้กดมากกว่าช่องให้พิมพ์ ต้องเติมค่าที่กรอกซ้ำทุกครั้งไว้ให้ล่วงหน้า และข้อสำคัญที่สุดคือ อย่ามี required field ที่คนหน้างานตอบไม่ได้จริงๆ ถ้าบังคับให้ใส่หมายเลข IMO ของเรือที่ไม่มีหมายเลข IMO สิ่งที่จะได้กลับมาคือเลข 0000000 ทั้งฐานข้อมูล เห้ย แล้วปีหน้าจะมีคนเอาไปทำสถิติด้วยนะ
ของแถมที่ต้องติดไปกับทุกระเบียนโดยที่คนกรอกไม่ต้องทำอะไรคือ พิกัด GPS พร้อมค่าความแม่น เวลาที่เก็บเป็น UTC, ตัวตนของผู้กรอก, รูปพร้อม EXIF และ เวอร์ชันของฟอร์ม ข้อสุดท้ายคนลืมกันเยอะมาก แต่วันที่ฟอร์มเปลี่ยนคำถามข้อ 7 จาก "พบเครื่องมือผิดประเภทหรือไม่" เป็น "ระบุชนิดเครื่องมือที่พบ" ตัวเลขสถิติย้อนหลังจะเปลี่ยนความหมายทันทีโดยไม่มีใครรู้ตัว
หน้าตาของสิ่งที่วิ่งขึ้น server ก็ไม่ได้หวือหวาอะไร ประมาณนี้
{
"form": "boarding-v3",
"id": "9f2c7a10-c3d1-4a77-8e21-0bb5a2f9",
"captured_at": "2026-09-21T02:14:37Z",
"synced_at": null,
"by": "officer-042",
"pos": { "lat": 7.8412, "lon": 98.2731, "acc_m": 6 },
"answers": {
"gear_type": "purse_seine",
"crew_count": 14,
"logbook_onboard": false
},
"photos": ["local/IMG_0421.jpg"]
}สังเกตสองฟิลด์นะฮะ id ที่เครื่องตั้งเองตั้งแต่ยังไม่มีสัญญาณ กับ synced_at ที่ยังเป็น null แปลว่าของชิ้นนี้ "มีอยู่จริงแล้ว" ตั้งแต่ตอนกรอก แค่ยังไม่มีใครบนฝั่งรู้เท่านั้นเอง
ของพวกนี้ฟังดูเรียบร้อยดีตอนยังอยู่ในเอกสารออกแบบ แต่โปรเจกต์แนวนี้มักโดนตีกลับด้วยท่าเดิมๆ สามท่าตั้งแต่รอบแรกที่เอาลงหน้างาน ท่าแรกคือฟอร์มยาวเกินจนกรอกบนเรือที่กำลังโคลงไม่ไหว ทางออกเกือบทุกครั้งคือหั่นให้เหลือเท่าที่ต้องรู้จริงๆ แล้วเปลี่ยนช่องพิมพ์เป็นปุ่มใหญ่ๆ ที่กดด้วยนิ้วโป้งข้างเดียวได้ ท่าที่สองคือคิว sync บวมตอนเรือหลายลำกลับเข้าเขตมีสัญญาณพร้อมกัน เครื่องหนึ่งส่งไม่สำเร็จก็ส่งซ้ำ อีกเครื่องส่งซ้ำตาม สุดท้ายปลายทางได้ของซ้ำกันเป็นกอง ซึ่งแก้ที่ฝั่ง server ล้วนๆ คือต้อง idempotent ยึด id ที่เครื่องตั้งมาเป็นตัวตัดสิน ส่งกี่รอบก็ได้ระเบียนเดียว ส่วนท่าที่สามเป็นเรื่องความรู้สึกมากกว่าเทคนิค คือคนใช้ไม่ไว้ใจว่าของที่กรอกไปมันถึงฝั่งจริง แล้ววิธีที่เขาแก้กันเองคือถ่ายรูปหน้าจอเก็บไว้ หรือจดใส่กระดาษคู่ไปด้วย ซึ่งวนกลับไปหาปัญหาเดิมที่เราพยายามหนีตั้งแต่ต้น ทางแก้ไม่ได้ซับซ้อน แค่ต้องมี ack ที่มองเห็นด้วยตาเปล่า — ค้างอยู่กี่ใบ ขึ้นไปแล้วกี่ใบ ฝั่งรับยืนยันกลับมาแล้วหรือยัง
เก็บข้อมูลเก่งแค่ไหน ถ้ามันจบอยู่ในเครื่องเราคนเดียวก็ได้ภาพครึ่งเดียวอยู่ดี เพราะเรือลำเดียวออกจากน่านน้ำเราไปโผล่บ้านคนอื่นได้ในไม่กี่ชั่วโมง กล้องหน้าบ้านตัวเดียวเห็นแค่หน้าบ้านตัวเอง อยากรู้ว่ารถคันที่เพิ่งวิ่งผ่านไปมาจากทางไหนก็ต้องเปิดกลุ่มไลน์ทั้งซอยถามกัน
ตัวอย่างที่เป็นของสาธารณะและเล่าได้เต็มปากคือ IORIS ย่อมาจาก Indo-Pacific Regional Information Sharing ซึ่งเดิมทีตัว I ตัวแรกคือ Indian Ocean มันเป็นเว็บแพลตฟอร์มสำหรับแบ่งปันข้อมูลและประสานงานทางทะเลข้ามหน่วยงานและข้ามประเทศ พัฒนาขึ้นภายใต้โครงการ CRIMARIO ของสหภาพยุโรป
ประวัติย่อๆ ของมันน่าสนใจสำหรับคนทำระบบมาก
ฟีเจอร์ที่มีก็ตรงไปตรงมา — ห้องแชทกับระบบแจ้งเตือน, แผนที่, การทำเครื่องหมายและงานสกัดกั้นเรือ, แลกเปลี่ยนไฟล์, ฟอร์ม, คลังเอกสาร และข้อมูล AIS จากดาวเทียม ส่วนฝั่งผู้ใช้ ข้อมูลช่วงราวปี 2021 ระบุว่ามีหน่วยงานราวสิบเก้าแห่งจากสิบสองประเทศและองค์กรระดับภูมิภาคใช้งานอยู่ ทั้งฝั่งแอฟริกาตะวันออก ตะวันออกกลาง หมู่เกาะในมหาสมุทรอินเดีย ไปจนถึงศูนย์ประสานงานทางทะเลระดับภูมิภาคหลายแห่ง
ถ้าเอารายการฟีเจอร์มาเรียงเป็นภาพการใช้งานก็ประมาณนี้ — เปิดเคสขึ้นมาหนึ่งเรื่อง คนที่เกี่ยวข้องคุยกันในห้องแชทของเคสนั้นโดยมีระบบแจ้งเตือนคอยสะกิดคนที่ต้องรู้ ส่วนแผนที่คือที่ที่ทุกคนเห็นของชุดเดียวกัน ปักหมุด marker ลงไปได้ มีชั้นข้อมูล AIS จากดาวเทียมวิ่งอยู่ และถ้าต้องสกัดกั้นเรือลำไหนก็มีเครื่องมือ vessel intercept ให้ทำงานกันต่อบนแผนที่ใบเดิม ของที่แลกกันไปมาก็เป็นไฟล์กับฟอร์มที่กรอกแล้วตกลงไปอยู่ในคลังเอกสารของเคสนั้น ไม่ใช่กระจัดกระจายอยู่ในแชทส่วนตัวของใครสักคน และที่เด็ดก็คือเหมือนกันเปิดกระทู้ (ดูโบราณเนอะ) แล้วไปปักหมุดอยู่บนแผนที่ ให้คนที่สามารถเข้าถึงได้ตามภารกิจนั้นๆ มาตอบ คล้ายๆ กับ C2 ย่อยๆ
สามข้อที่ผมว่าเป็นบทเรียนของคนทำระบบ
ข้อแรก ความเป็นกลางสำคัญกว่าฟีเจอร์ คำว่า neutral ที่เขาเน้นตลอดไม่ใช่คำสวยๆ ในโบรชัวร์ แต่มันคือเหตุผลที่แพลตฟอร์มแบบนี้เกิดได้ เพราะถ้าห้องกลางเป็นของประเทศใดประเทศหนึ่ง อีกสิบเอ็ดประเทศจะคิดหนักก่อนกดส่งข้อมูล ต่อให้ระบบดีแค่ไหน ปัญหาที่แท้จริงของการแชร์ข้อมูลข้ามชาติไม่เคยเป็นเรื่องเทคนิค
ข้อสอง ไม่ต้องบังคับให้ใครทิ้งระบบเดิม โมเดลที่ใช้ได้จริงคือมีห้องกลางไว้เจอกันเป็นเคสๆ ไป ใครมีระบบของตัวเองก็ใช้ต่อไป แล้วเอาเฉพาะเรื่องที่ต้องร่วมมือกันมาเปิดห้อง อันนี้คิดแบบเดียวกับ CISE ของยุโรปที่เคยเล่าไว้ในบทความ MDA เลย คือไม่ตั้งกองกลางแล้วเถียงกันว่าใครเป็นเจ้าของ
ข้อสาม ฟีเจอร์แรกในลิสต์คือแชท ไม่ใช่แผนที่ อันนี้เลาว่าบอกอะไรบางอย่างที่คนทำระบบไม่ค่อยอยากได้ยิน เราชอบคิดว่าคุณค่าของระบบอยู่ที่จอ Common Operational Picture สวยๆ แต่สิ่งที่คนทำงานจริงต้องการตอนตีสามคือ ช่องทางคุยกับคนอีกฝั่งที่ถือข้อมูลอีกครึ่งหนึ่งอยู่ แผนที่เป็นแค่ของที่เอาไว้ชี้ประกอบตอนคุยกัน
เรื่องการแลกเปลี่ยนข้อมูลข้ามประเทศนี่มีรายละเอียดอีกเยอะมาก ทั้งมาตรฐานข้อมูล สิทธิ์ ความไว้ใจ และคำถามคลาสสิกว่าให้ข้อมูลเขาไปแล้วเราได้อะไรกลับมา ขอยกไปเล่าเต็มๆ ตอนหน้า
กลับมาที่สามเสาของ MDA ที่ตั้งไว้ตั้งแต่บทความแรก คือ Situational Awareness (ตอนนี้ในทะเลมีอะไร), Threat Awareness (อันไหนน่าจะมีพิษ) และ Response Awareness (ถ้ามีพิษจริง เรามีอะไรส่งไปได้) ฟอร์มตรวจค้นอยู่ในเสาที่สามเต็มๆ และเป็นเสาที่ไม่มีใครอยากทำ เพราะไม่มีจอสวยๆ ให้อวดใคร
การตรวจค้นหนึ่งครั้งคือจุดที่ข้อมูลทั้งระบบมาบรรจบกับความเป็นจริง เรือตรวจการณ์วิ่งไปถึง เทียบลำ ส่งชุดตรวจขึ้นไป แล้วสิ่งที่เจ้าหน้าที่กรอกกลับมาคือคำตอบที่ sensor ทั้งกองเดาไว้ตั้งหลายชั่วโมง ของที่อยู่ในฟอร์มโดยทั่วไปก็ประมาณนี้
ทีนี้ผลตรวจกลายเป็น "ข้อมูล" ยังไง มันให้ของสามอย่างที่หาจากที่อื่นไม่ได้เลย
อย่างแรกคือ ground truth ซึ่งคือสิ่งที่ทั้งระบบขาดแคลนที่สุด โมเดลตอนที่ 4 เดาว่าจุดขาวนั้นน่าจะเป็นเรือประมงขนาดกลาง ฟอร์มที่กรอกกลับมาบอกว่าที่แท้เป็นเรือบรรทุกน้ำมันขนาดเล็ก — นั่นคือหนึ่งแถวของชุดข้อมูลสำหรับเทรนรอบหน้า ที่ซื้อจากที่ไหนก็ไม่ได้
อย่างที่สองคือ ประวัติที่ผูกกับตัวเรือ ลำนี้ถูกตรวจครั้งที่สี่ในสองปี สามครั้งแรกไม่พบอะไร ครั้งนี้เอกสารไม่ครบ ประวัติแบบนี้ทำให้คำถาม "เคยทำมาก่อนไหม" ตอบได้จริงๆ สักที
อย่างที่สามคือ สถิติเชิงพื้นที่และเวลา ที่จะไปเป็นวัตถุดิบของหัวข้อถัดไป
และกฎข้อเดียวที่ผมอยากขีดเส้นใต้สามทีคือ ต้องบันทึกตอนตรวจแล้วไม่เจออะไรด้วย ไม่ใช่กรอกเฉพาะวันที่จับได้ เพราะถ้าเก็บแต่ผลบวก สิ่งที่จะได้ไม่ใช่แผนที่ความเสี่ยง แต่คือแผนที่ความขยันของเจ้าหน้าที่ ตรงไหนออกตรวจบ่อยก็แดงจัด ตรงไหนไม่เคยมีใครไปเลยก็ขาวสะอาด แล้วปีถัดไปเราก็จะส่งเรือไปตรงที่แดง ซึ่งแดงเพราะเราไปบ่อย วนเป็นงูกินหางไปเรื่อยๆ
อันนี้คือหน้าตาอีกด้านของประโยคจากตอนที่แล้วที่ว่า "ไม่เจอ" ไม่เท่ากับ "ไม่มี" เป๊ะเลย ต่างแค่คราวนี้ช่องว่างไม่ได้เกิดจากดาวเทียมยังไม่บินผ่าน แต่เกิดจากไม่มีใครกดบันทึกตอนที่ผลออกมาว่าไม่มีอะไร
ลองนึกภาพสถานการณ์สมมติกันเล่นๆ สักฉาก ชุดตรวจขึ้นไปบนเรือลำหนึ่ง แล้วเลขทะเบียนที่อ่านจากป้ายข้างลำดันไม่ตรงกับที่ระบบขึ้นให้ ชื่อเรือที่ทาสีไว้ก็คนละชื่อกับในทะเบียน ถ้าฟอร์มมีช่องทะเบียนมาให้ช่องเดียว สิ่งที่เจ้าหน้าที่จะทำคือเลือกกรอกอันใดอันหนึ่งแล้วเดินไปข้อถัดไป ซึ่งแปลว่าของมีค่าที่สุดของทริปนั้นหายไปต่อหน้าต่อตาตรงนั้นเอง ฟอร์มที่ดีจึงต้องเปิดทางให้บอกง่ายๆ ว่าค่าที่ตาเห็นกับค่าที่ระบบบอกมันไม่ตรงกัน กดปุ่ม "ไม่ตรง" ทีเดียว แล้วมีช่องหมายเหตุสั้นๆ กับปุ่มถ่ายรูปป้ายจริงต่อท้ายให้เสร็จในจังหวะเดียว เท่านี้ระเบียนหนึ่งใบก็เปลี่ยนจากข้อมูลธรรมดาเป็นเบาะแส แทนที่จะกลายเป็นช่องว่างที่ไม่มีใครรู้ด้วยซ้ำว่าเคยมีอยู่
ของสนุกของเครื่องมือชุดนี้คือ พอมันเป็นแค่ "แอปกรอกฟอร์มที่ติดพิกัดกับเวลามาด้วย" มันก็ไม่ได้ผูกกับงานจับผิดเรือเลยสักนิด เปลี่ยนฟอร์มอย่างเดียว งานก็เปลี่ยนเลย
Maritime Spatial Planning คือการวางแผนว่าพื้นที่ทะเลผืนหนึ่งจะให้ใครใช้ทำอะไรตรงไหน เพราะทะเลผืนเดียวกันมีทั้งเรือประมง เส้นทางเดินเรือพาณิชย์ ท่องเที่ยวดำน้ำ ฟาร์มทะเล แหล่งพลังงาน พื้นที่ซ้อมรบ และเขตอนุรักษ์ ซึ่งทุกกลุ่มอยากได้ที่เดิมหมด งานนี้จะตัดสินอะไรได้ต้องมีข้อมูลว่าตรงไหนมีอะไรอยู่จริง
ตัวอย่างที่ชัดที่สุดคือการเก็บข้อมูลสัตว์ทะเลหายาก พะยูน เต่าทะเล โลมา วาฬ ฉลามวาฬ ปะการังบางชนิด ฟอร์มก็เปลี่ยนจาก "ตรวจค้นเรือ" เป็น "พบอะไร กี่ตัว ตรงไหน กี่โมง ทำอะไรอยู่ สภาพน้ำเป็นยังไง แนบรูปมาด้วย" คนกรอกก็เปลี่ยนจากเจ้าหน้าที่ชุดตรวจ เป็นเจ้าหน้าที่อุทยาน นักวิจัย ชาวประมง ไกด์ดำน้ำ ไปจนถึงนักท่องเที่ยวที่อยากช่วย ซึ่งวงการเรียกว่า citizen science
ข้อดีคือ record ที่ได้หน้าตาเหมือนกันเป๊ะกับของฝั่งตรวจค้น — มีพิกัด มีเวลา มีผู้รายงาน มีรูป มีค่าความมั่นใจ ไหลลงท่อเดิม ขึ้นแผนที่ตัวเดิม ใช้ระบบสิทธิ์ชุดเดิม ไม่ต้องสร้างโลกใหม่
แต่มีสองเรื่องที่ต้องระวังหนักกว่างานฝั่งเรือ
เรื่องแรกคือ bias ของการสังเกต ข้อมูลแบบนี้จะเจอเยอะตรงที่คนไปเยอะ ไม่ใช่ตรงที่สัตว์อยู่เยอะ แผนที่ที่ได้ออกมาแดงจัดแถวจุดดำน้ำยอดนิยมเป็นเรื่องปกติมาก เพราะที่นั่นมีคนถือมือถือเยอะที่สุด ทางแก้คือต้องเก็บ effort ควบคู่ไปด้วย คือออกสำรวจกี่ชั่วโมง ครอบคลุมพื้นที่เท่าไหร่ เห็นหรือไม่เห็นก็ต้องรายงาน — ซึ่งก็คือกฎ "บันทึกตอนไม่เจอด้วย" จากหัวข้อที่แล้วคำต่อคำ
เรื่องที่สองคือบางข้อมูลเปิดสาธารณะไม่ได้ ตำแหน่งรังเต่าที่แม่นระดับสิบเมตร หรือจุดที่พบสัตว์หายากเป็นประจำ ถ้าเปิดหมดมันจะกลายเป็นแผนที่นำทางให้คนไปเก็บไข่หรือไปล่าเสียเอง ทางที่ทำกันคือแยกชั้นสิทธิ์ และทำเวอร์ชันสาธารณะที่ จงใจหยาบลง เช่นปัดพิกัดเป็นตารางกิโลเมตร หรือแสดงเป็นความหนาแน่นรายพื้นที่แทนหมุดรายตัว
ผลลัพธ์ปลายทางคือชั้นข้อมูลที่เอาไปทาบกับของฝั่งเรือได้ทันที เช่นพอเอาแหล่งหญ้าทะเลไปวางทับกับเส้นทางเรือเร็วที่วิ่งประจำ แล้วเห็นว่ามันพาดผ่านกันพอดี ข้อเสนอที่ตามมาก็ไม่ใช่เรื่องดราม่าอะไร แค่ขยับร่องน้ำสองร้อยเมตร หรือกำหนดช่วงความเร็วในฤดูที่สัตว์เข้ามาหากิน
พูดจริงๆ นี่คือสิ่งที่นักดูนกทำกันมาเป็นร้อยปีแล้วนะครับ — จดว่าเจอตัวอะไร ตรงไหน กี่โมง กี่ตัว แล้วก็จดวันที่ไปนั่งรอทั้งเช้าแล้วไม่เจออะไรเลยด้วย เก็บข้อมูลชุดเดียวกัน เปลี่ยนแค่เป้าหมาย
ตอนที่ 3 เราหลอมข้อมูลจาก sensor หลายตัวที่มาพร้อมกันในเวลาเดียวกัน ตอนที่ 4 เราเอา detection ที่ไม่มีชื่อไปทาบกับ track ที่มีชื่อ คราวนี้เป็นการหลอมข้ามชนิดข้อมูลและข้ามเวลา ซึ่งหลวมกว่าเยอะ แต่ก็ตอบคำถามคนละแบบ
ของที่เอามากองรวมกันได้แก่ จุดและผลของการตรวจค้น, เส้นทางเรือย้อนหลัง, เหตุการณ์ผิดปกติอย่างช่วงเงียบของสัญญาณกับจุดนัดพบกลางทะเลจากตอนที่แล้ว, รายงานภาคสนามจากแอป, ข้อมูลเปิดเรื่องทะเบียนและเจ้าของ แล้วก็ชั้นข้อมูลสภาพแวดล้อมทั้งเขตอนุรักษ์ ร่องน้ำ แนวเคเบิล และลมฟ้าอากาศ
แล้วถ้าเราเอาพวกนี้มา plot บนแผนที่ดู โดยเฉพาะ event ต่างๆ ที่เก็บได้ เราจะเห็นเรื่องราวทั้งหมดในทะเลต่อๆ กัน ข้อมุลที่ update มานอกเหนือจากที่ได้จาก sensor และสามารถร่วมด้วยช่วยกันจนจบเหตุการณ์ทางทะเลนั้นๆ ได้เลย
ท่าทำ heat map ก็บ้านๆ มาก ตัดทะเลเป็นตาราง จะเป็นสี่เหลี่ยมหรือหกเหลี่ยมก็ตามสะดวก นับว่าแต่ละช่องเกิดอะไรกี่ครั้ง แล้วระบายสี แต่มีสองข้อที่ถ้าข้ามไปจะได้แผนที่สวยๆ ที่ผิดทั้งใบ
ข้อแรก ต้องหารด้วยความพยายาม นับดิบๆ ได้แผนที่ความขยันตามที่บ่นไว้หัวข้อที่แล้ว ตัวหารที่ถูกคือจำนวนครั้งที่เข้าไปดูตรงนั้น ชั่วโมงลาดตระเวน หรือจำนวนภาพดาวเทียมที่ครอบเซลล์นั้น พอหารแล้วจุดแดงมักจะขยับออกไปไกลฝั่งกว่าเดิม ซึ่งตรงกับสามัญสำนึกว่าของผิดกฎหมายมันไปเกิดตรงที่คนไม่ค่อยไป
ข้อสอง ต้องหั่นตามเวลา heat map ก้อนเดียวที่รวมข้อมูลทั้งปีแทบไม่บอกอะไรเลย เพราะพฤติกรรมในทะเลผูกกับฤดู ลมมรสุม ข้างขึ้นข้างแรม และกลางวันกลางคืนอย่างแรง แผนที่หน้ามรสุมกับหน้าลมสงบควรเป็นคนละใบ
ส่วนสถิติที่ผู้บังคับบัญชาถามจริงๆ ไม่ใช่แผนที่สวย แต่เป็นตัวเลขไม่กี่ตัว เช่นเดือนนี้ออกตรวจกี่ครั้ง, อัตราการพบของผิดต่อหนึ่งเบาะแสที่ระบบชี้ ซึ่งเป็นตัวเดียวที่บอกตรงๆ ว่าโมเดลกับกติกาที่เราเขียนไว้ใช้ได้จริงไหม, เวลาเฉลี่ยตั้งแต่จอขึ้นแดงจนมีคนไปถึงหน้างาน และพื้นที่ที่ไม่เคยถูกตรวจเลยตลอดทั้งปี ข้อสุดท้ายนี่แหละที่มักทำให้ห้องประชุมเงียบไปพักหนึ่ง
แล้วก็ขอลากกลับไปเรื่อง Data Lake ที่ปิดท้ายตอนที่แล้ว รายงานภาคสนามคือของดิบอีกชนิดที่ต้องไหลลงทะเลสาบเป็นด่านแรก เก็บตามที่มันถูกกรอกมาจริงๆ พร้อม lineage ว่าใครกรอก เมื่อไหร่ ด้วยฟอร์มเวอร์ชันไหน ที่ต้องย้ำเพราะข้อมูลจากคนมีคุณสมบัติที่ข้อมูลจาก sensor ไม่มี — คนจำผิดได้ เข้าใจผิดได้ และโกหกได้ เพราะงั้นการเก็บว่า "ใครบอก" จึงสำคัญพอๆ กับ "บอกว่าอะไร" นักข่าวสายสืบสวนเข้าใจข้อนี้ดีกว่าหลายระบบ เพราะเขาจดตลอดว่าใครเป็นคนบอกและบอกตอนไหน แหล่งที่พูดถูกมาสิบครั้งกับแหล่งที่เพิ่งเปิดปากครั้งแรก น้ำหนักไม่เท่ากันตั้งแต่ก่อนจะเริ่มเขียนแล้ว
ลองเอาทุกอย่างในบทความนี้มาต่อกันเป็นเรื่องเดียวดู ย้ำว่าสมมติล้วนๆ อ่ะ ไม่ใช่เคสจริง
ดาวเทียม SAR รอบเช้าคืนภาพมา แล้วโมเดลชี้จุดสว่างจุดหนึ่งกลางเขตที่ห้ามทำการประมง นั่นคือชิ้นแรก เป็น IMINT ต่อมาระบบพยายามทาบกับ track ที่มีอยู่แล้วทาบไม่ติดสักลำ ตกเข้ากองที่สามที่เรียกว่า dark candidate จากตอนที่แล้ว แต่สถานี RF ชายฝั่งได้ยินเรดาร์เดินเรือดังอยู่แถวนั้นพอดี — ชิ้นที่สอง เป็น SIGINT แล้ว signature ของเครื่องส่งตัวนั้นดันเคยถูกบันทึกไว้เมื่อสองปีก่อน ตอนที่เจ้าของมันยังเปิด AIS อยู่ ชิ้นที่สามมาแล้ว เป็น MASINT
พอได้ชื่อมา ทีมก็เปิดทะเบียนสาธารณะ เจอว่าเรือลำนี้เปลี่ยนธงสามครั้งในสองปี ชิ้นที่สี่ OSINT ตามด้วยการสาวไปที่บริษัทเจ้าของ แล้วพบว่าจดทะเบียนที่อยู่เดียวกับอีกห้าบริษัทที่ถือเรือคนละลำ ชิ้นที่ห้า FININT ระหว่างนั้นชาวประมงในพื้นที่ก็ส่งรายงานเข้ามาทางแอปว่าเมื่อคืนเห็นเรือหน้าแปลกจอดอยู่แถวนั้นจริง ชิ้นที่หก HUMINT
สุดท้ายเรือตรวจการณ์ออกไปขึ้นตรวจ แล้วฟอร์มกลับมาบอกว่าเครื่องมือประมงบนเรือไม่ตรงกับที่ขออนุญาตไว้ — ชิ้นที่เจ็ดซึ่งเป็น HUMINT อีกชิ้น และเป็นชิ้นเดียวในกองนี้ที่เป็น ground truth
ประเด็นที่อยากให้จับคือ ไม่มีชิ้นไหนพิสูจน์อะไรได้ด้วยตัวเอง จุดสว่างบนภาพก็แค่จุดสว่าง เปลี่ยนธงสามครั้งก็ไม่ผิดกฎหมาย จดที่อยู่ซ้ำกันก็ไม่ผิด ชาวประมงอาจจำวันผิด แต่พอเจ็ดชิ้นชี้ไปทางเดียวกัน มันกลายเป็นเหตุผลที่ดีพอจะส่งเรือออกไปหนึ่งเที่ยว ซึ่งเป็นสิ่งเดียวที่เราต้องการจากระบบจริงๆ
ของที่ระบบชี้เป้าอยู่ในเคสข้างบนเขาเรียกรวมๆ ว่า IUUF ย่อจาก Illegal, Unreported and Unregulated Fishing สามคำนี้ไม่เหมือนกันนะครับ — Illegal คือทำสิ่งที่กฎหมายห้ามตรงๆ เช่นไม่มีใบอนุญาตหรือเข้าเขตหวงห้าม, Unreported คือจับแล้วไม่แจ้ง หรือแจ้งน้อยกว่าที่จับจริง ซึ่งทำให้ตัวเลขที่ใช้คำนวณโควตาทั้งประเทศเพี้ยนไปหมด, ส่วน Unregulated คือทำในพื้นที่หรือด้วยเรือที่ไม่มีกติกาครอบ เช่นเรือไร้สัญชาติในทะเลหลวง
แล้วทำไมคนที่ไม่ได้อยู่ในวงการทะเลต้องสนใจ เพราะมันไม่ได้จบที่ปลา
ทั้งหมดนี้คือสะพานไปยังเสาที่สองของ MDA คือ Maritime Threat Awareness และผมอยากให้เข้าใจตรงกันว่ามันไม่ใช่กล่องดำที่พ่นคำตอบว่าเรือลำนี้ผิด สิ่งที่มันทำจริงๆ คือ จัดคิว ว่าเรือตรวจการณ์ลำที่ว่างอยู่ตอนนี้หนึ่งลำ กับเป้าน่าสงสัยสี่สิบเป้า ควรไปหาใครก่อน โดยบอกด้วยว่าเพราะอะไรและมั่นใจแค่ไหน
ระบบยกมือ คนตัดสิน กฎข้อนี้ใช้มาตั้งแต่ตอนที่ 1 และจะไม่เปลี่ยนไปจนจบซีรีส์
ถ้าจะเก็บกลับบ้านข้อเดียวจากตอนนี้ เลาขอข้อนี้ครับ — sensor ทั้งกองตอบได้แค่ว่ามีอะไรอยู่ตรงไหน ส่วนคำว่าใครกับทำไม ต้องไปเอามาจากทะเบียน เอกสาร และคน และตลกดีตรงที่ตระกูลซึ่งถูกที่สุดในระบบกับตระกูลที่แพงที่สุดในระบบ ดันเป็นตระกูลเดียวกัน คือ HUMINT — ถูกเพราะคนอยู่ตรงนั้นอยู่แล้ว แพงเพราะทุกครั้งที่ส่งคนไปหาคำตอบ มีชีวิตคนอยู่ในสมการนั้นด้วย
ความผิดพลาดที่เห็นบ่อยสุดในโครงการแนวนี้คือทุ่มงบเก้าสิบเปอร์เซ็นต์ไปกับ sensor และจอ เหลืออีกสิบเปอร์เซ็นต์ให้ช่องกรอกฟอร์มที่คนหน้างานต้องใช้ทุกวัน แล้วก็มาแปลกใจกันตอนปลายปีว่าทำไมไม่มีข้อมูลภาคสนามให้เอามาหลอมเลยสักแถว
สามกฎที่อยากให้ติดไปด้วย
ตลกตรงที่สามข้อนี้ไม่มีข้อไหนต้องใช้เทคโนโลยีเลยสักข้อ สมุดปกอ่อนกับดินสอก็ทำได้ มันเป็นเรื่องวินัยในการจดล้วนๆ ระบบจะแพงแค่ไหน ถ้าข้ามสามข้อนี้ไป สิ่งที่ได้คือฐานข้อมูลก้อนใหญ่ที่ตอบคำถามของคนทำงานไม่ได้สักข้อ
ใครเคยทำแอปเก็บข้อมูลภาคสนามแบบ offline-first มาบ้าง เจอปัญหา sync ท่าไหนกันบ้าง หรือใครเคยออกแบบฟอร์มให้คนหน้างานใช้แล้วโดนตีกลับรอบแรก มาเล่าสู่กันฟังได้เลย ผมว่าเรื่องพวกนี้สนุกกว่าเรื่อง sensor อีกนะ
ตอนที่ 6 จะเป็นตอนสุดท้ายของซีรีส์ ว่าด้วยการแลกเปลี่ยนข้อมูลระหว่างประเทศ IORIS ในตอนนี้เป็นแค่ตัวอย่างเดียว ของจริงมีทั้งมาตรฐานข้อมูลที่ต้องตกลงกัน สิทธิ์ที่ต้องคุมให้ได้ ความไว้ใจที่สร้างกันเป็นสิบปี และคำถามที่ตอบยากที่สุดข้อหนึ่งของงานสายนี้ คือให้ข้อมูลเขาไปแล้วเราได้อะไรกลับมา
ตามหาเรือที่ดับ AIS ด้วย RF Detection ชายฝั่ง RF จากดาวเทียม ดาวเทียม SAR และ EO/IR แล้วให้ Machine Learning ชี้เป้าบนภาพ ก่อนเอา detection ที่ไม่มีชื่อกลับมาจับคู่กับ track ที่หลอมไว้ตอนที่แล้ว
หลอมเป้าจาก AIS เรดาร์ และกล้อง ให้เรือลำเดียวที่โผล่สี่หมุดเหลือหมุดเดียว ตั้งแต่ gating กับ association ไปจนถึงการหั่น window ตอนเป้าเป็นพัน แล้ววาด tiled map กับเป้าทั้งกองเองด้วย WebGPU
แกะทางออกข้อมูลสามแบบของเรดาร์ชายฝั่ง ทั้ง NMEA 0183 NMEA 2000 และ ASTERIX CAT048 แล้วต่อด้วยกล้อง EO/IR ที่สั่งผ่าน ONVIF ให้คลิกเป้าบนแผนที่แล้วหมุนไปเอง