เทคโนโลยีการปรับให้เหมาะสมเชิงคณิตศาสตร์สำหรับเรือบรรทุกสินค้า

 (research.google)
1 คะแนน โดย GN⁺ 2024-06-07 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ทีม Operations Research ของ Google Research เปิดตัว Shipping Network Design API สำหรับปรับให้เหมาะสมร่วมกันทั้ง การออกแบบเครือข่าย ตารางเวลา และเส้นทางคอนเทนเนอร์ ของเรือคอนเทนเนอร์แบบประจำเส้นทาง
  • ปัญหานี้ซับซ้อนขึ้นถึงระดับ WorldLarge ที่มีเรือ 500 ลำและท่าเรือ 200 แห่ง เพราะต้องกำหนดพร้อมกันทั้งลำดับการแวะท่าเรือของเรือ เวลาเข้า-ออก และเส้นทางจากต้นทางไปปลายทางของคอนเทนเนอร์
  • แนวทางเริ่มแรกอย่าง dual column generation และ CP-SAT หาโซลูชันที่พิสูจน์ได้ว่าเหมาะสมที่สุดในงานขนาดเล็กและกลางได้ แต่สำหรับปัญหาขนาดใหญ่จำเป็นต้องใช้ฮิวริสติกที่ผสาน large neighborhood search กับ variable neighborhood search
  • ในเบนช์มาร์ก LINERLIB ปริมาณคอนเทนเนอร์ที่จัดการได้ของ WorldSmall, EuropeAsia, Pacific, Mediterranean เพิ่มขึ้นตามลำดับ 35%, 14%, 35%, 32% และจำนวนเรือที่ใช้ลดลง 7%, 15%, 4%, 23%
  • Google มองว่าวิธีนี้เป็นวิธีแรกที่แก้ปัญหาการออกแบบเครือข่ายและตารางเวลาในระดับ WorldLarge ได้ และจะให้บริการ Shipping Network Design API เป็นส่วนหนึ่งของ Operations Research APIs ในอนาคต

ปัญหาการปรับให้เหมาะสมของเครือข่ายขนส่งคอนเทนเนอร์ทางทะเลแบบพร้อมกัน

  • 90% ของสินค้าทั่วโลกเคลื่อนย้ายผ่านทะเล และเรือบรรทุกสินค้าขนาดใหญ่สามารถยาวได้ 0.25 ไมล์ หนัก 250,000 ตัน บรรทุกคอนเทนเนอร์ 12,000 ตู้ และสินค้ามูลค่ารวม 1 พันล้านดอลลาร์
  • เรือบรรทุกสินค้าต่างจากเครื่องบิน รถไฟ และรถบรรทุกตรงที่เดินเรือแทบตลอดเวลา และเคลื่อนที่ตาม เส้นทางวนรอบ บนทะเล
  • เส้นทางและตารางเวลาที่ไม่มีประสิทธิภาพทำให้คอนเทนเนอร์ค้างอยู่ที่ท่าเรือ เรือรออยู่กลางทะเล และกระแสโลจิสติกส์ล่าช้า รวมถึงส่งผลต่อราคาสินค้าด้วย
  • Shipping Network Design API ของ Google นำโซลูชันใหม่สำหรับปัญหานี้มาใช้งาน
    • เร็วกว่าและขยายขนาดได้ดีกว่าความพยายามที่เป็นที่รู้จักก่อนหน้านี้
    • สามารถทำให้กำไรของสายเรือคอนเทนเนอร์เพิ่มเป็นสองเท่า ขนส่งคอนเทนเนอร์ได้มากขึ้น 13% และดำเนินงานด้วยจำนวนเรือน้อยลง 15%

การตัดสินใจสามอย่างที่ LSNDSP ต้องแก้ร่วมกัน

  • Liner Shipping Network Design and Scheduling Problem หรือ LSNDSP จัดการการตัดสินใจสามอย่างพร้อมกัน
    • การออกแบบเครือข่าย: กำหนดว่าเรือจะแวะท่าเรือใดตามลำดับใด
    • ตารางเวลาเครือข่าย: กำหนดว่าเรือจะมาถึงและออกเดินทางเมื่อใด
    • การกำหนดเส้นทางคอนเทนเนอร์: เลือกว่าแต่ละคอนเทนเนอร์จะเดินทางจากต้นทางไปปลายทางผ่านเส้นทางใด
  • บริษัทขนส่งคอนเทนเนอร์ต้องแก้ทั้งสามปัญหา แต่โดยทั่วไปมักจัดการทีละขั้นตามลำดับ
  • การแก้ทั้งสามปัญหาพร้อมกันทำให้ยากขึ้น แต่เพิ่มโอกาสในการหาโซลูชันที่ดีกว่า
  • ผลลัพธ์ของการออกแบบเครือข่ายนำไปสู่ เส้นทางบริการ ที่เรือจำนวนน้อยลำจะปฏิบัติตาม
    • ตัวอย่างเช่น อาจเป็นเส้นทางจากเอเชียตะวันออกผ่านคลองสุเอซไปยังยุโรปใต้
    • เส้นทางบริการจะเผยแพร่พร้อมวันที่ เพื่อให้ผู้ส่งสินค้ารู้ว่าต้องเตรียมคอนเทนเนอร์ที่ไหนและเมื่อใด

ข้อจำกัดจากการเทียบท่า การถ่ายลำ และความล่าช้า

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

วิธีการปรับให้เหมาะสม: จาก column generation ไปจนถึง neighborhood search

  • ปัญหาการปรับให้เหมาะสมทุกปัญหาประกอบด้วย ตัวแปร, ข้อจำกัด ของตัวแปร และ ฟังก์ชันวัตถุประสงค์ ที่ต้องการทำให้ต่ำสุดหรือสูงสุด
    • ตัวอย่าง: เรือและท่าเรือเป็นตัวแปร
    • ตัวอย่าง: จำนวนคอนเทนเนอร์ที่เรือบรรทุกได้เป็นข้อจำกัด
    • ตัวอย่าง: การทำให้จำนวนคอนเทนเนอร์ที่ขนส่งได้สูงสุดเป็นฟังก์ชันวัตถุประสงค์
  • โดยทั่วไปตัวแปรและข้อจำกัดจะแสดงเป็นเมทริกซ์ โดยคอลัมน์แทนตัวแปร และแถวแทนข้อจำกัด
  • เทคนิคทั่วไปในการแยกย่อยปัญหาขนาดใหญ่คือ column generation
    • ในตอนแรกพิจารณาเฉพาะตัวแปรบางส่วน
    • จากนั้นสร้างตัวแปรใหม่ หรือคอลัมน์ใหม่ เพื่อประมาณปัญหาเดิมให้ดีขึ้น
  • Google พัฒนาไลบรารีซอฟต์แวร์ที่วิเคราะห์ปัญหาและคาดการณ์ว่าควรสร้างคอลัมน์ใด
    • ไลบรารีนี้จะเปิดซอร์สผ่าน MathOpt ซึ่งเป็นเฟรมเวิร์กการโปรแกรมเชิงคณิตศาสตร์

ข้อจำกัดของแนวทางพื้นฐานสองแบบ

  • dual column generation มองการออกแบบเครือข่ายและการกำหนดเส้นทางคอนเทนเนอร์เป็นสองปัญหาที่เชื่อมโยงกัน
    • แต่ละปัญหาประกอบด้วยปัญหาหลักสำหรับเลือกตัวเลือกที่ดีที่สุด และปัญหาช่วยสร้างสำหรับค้นหาตัวเลือกที่สมเหตุสมผล
    • ใช้อัลกอริทึมเส้นทางสั้นที่สุดกับแต่ละคู่ปัญหาเพื่อสร้างตัวเลือกที่สมเหตุสมผล
    • จากนั้นใช้ตัวแก้ปัญหา linear programming Glop เพื่อเลือกตัวเลือกที่ดีที่สุดของแต่ละปัญหา
    • ใช้ column generation กับทั้งสองปัญหาพร้อมกัน และให้ผลลัพธ์ระหว่างทางของปัญหาหนึ่งส่งผลต่อความคืบหน้าของอีกปัญหาหนึ่ง
    • สามารถหาโซลูชันที่พิสูจน์ได้ว่าเหมาะสมที่สุด แต่ขยายขนาดได้ดีถึงเพียงปัญหาระดับกลาง
  • มีการลองใช้งานที่อิง CP-SAT ด้วย
    • ใช้ตัวแก้ปัญหา constraint programming CP-SAT ของ Google
    • ทำงานได้ดีถึงเครือข่ายขนาดกลาง แต่ไม่สามารถขยายไปถึงขนาดของปัญหาการขนส่งทางทะเลทั่วโลก
  • ทั้งสองแนวทางหาโซลูชันที่พิสูจน์ได้ว่าเหมาะสมที่สุดในปัญหาขนาดเล็กและกลางได้ แต่ขาดความสามารถในการขยายขนาดสำหรับงานขนาดใหญ่

ฮิวริสติกสำหรับการขยายสู่ขนาดใหญ่

  • เพื่อเพิ่มความสามารถในการขยายขนาด มีการใช้รูปแบบ local search สองแบบที่มองหาโอกาสปรับปรุงโดยสำรวจ เพื่อนบ้าน รอบโซลูชันเดิม
  • large neighborhood search จะตรึงบางส่วนของโซลูชันไว้ แล้วใช้วิธีข้างต้น
    • ตัวอย่าง: ตรึงเงื่อนไขอย่าง “เรือลำนี้แวะ Los Angeles ทุกวันอังคารเว้นอังคาร”
    • ลดพื้นที่ค้นหาเพื่อเพิ่มความสามารถในการขยายขนาด
  • variable neighborhood search สำรวจเพื่อนบ้านทั้งด้านเครือข่ายและตารางเวลา
    • ทำให้การค้นหาเป็นแบบขนานและกระจายไปยังหลายเครื่อง เพื่อประเมินเพื่อนบ้านจำนวนมากพร้อมกัน
    • สามารถจำกัดพื้นที่ค้นหาไปพร้อมกับสะท้อนความรู้ด้าน Operations Research และอุตสาหกรรมเดินเรือ
  • ทั้งสองแนวทางใช้ วิธีแบบค่อยเป็นค่อยไป โดยล็อกบางส่วนของโซลูชันที่มีแนวโน้มดีไว้ และเริ่มจากโซลูชันที่ดีอยู่แล้วเพื่อปรับปรุงให้ดียิ่งขึ้น
  • ความพยายามก่อนหน้านี้ไม่ได้พิจารณาเวลาขนส่งเพราะทำให้การแก้ปัญหายากขึ้นมาก แต่ Google พบว่าการรวม เวลาขนส่ง เข้าไปช่วยปรับปรุงคุณภาพของโซลูชันได้อย่างมาก

ผลลัพธ์เบนช์มาร์ก LINERLIB

  • การประเมินประสิทธิภาพใช้ LINERLIB ซึ่งเป็นเบนช์มาร์กอุตสาหกรรมสำหรับปัญหาการออกแบบเครือข่ายเดินเรือ
    • เบนช์มาร์กนี้ประกอบด้วยกองเรือ ท่าเรือ และความต้องการคอนเทนเนอร์ในสถานการณ์ขนส่งคอนเทนเนอร์ทางทะเล
  • สถานการณ์ทดสอบรวมถึง WorldSmall, EuropeAsia, WorldLarge
    • WorldLarge มี เรือ 500 ลำ, ท่าเรือ 200 แห่ง และคอนเทนเนอร์ประมาณ 140,000 ตู้
  • เป้าหมายการปรับให้เหมาะสมไม่ใช่เพียงการทำให้จำนวนคอนเทนเนอร์สูงสุดหรือจำนวนเรือต่ำสุด
    • หากทำให้จำนวนคอนเทนเนอร์สูงสุดอย่างเดียว อาจต้องเพิ่มเรือจำนวนมากจนต้นทุนดำเนินงานสูงขึ้น
    • หากทำให้จำนวนเรือต่ำสุดอย่างเดียว อาจได้เวลาจัดส่งที่ยาวอย่างไม่สมจริง เช่น ใช้เรือเพียงลำเดียวขนส่งคอนเทนเนอร์ทั้งหมด
  • LINERLIB สร้างสมดุลด้วย กำไร โดยประมาณ ซึ่งคำนวณจากรายได้จากการส่งมอบตรงเวลาหักด้วยต้นทุนการเดินเรือและต้นทุนการจัดการคอนเทนเนอร์ที่ท่าเรือ
  • เมื่อเทียบกับ baseline วิธีของ Google กำหนดเส้นทางคอนเทนเนอร์ได้มากขึ้นด้วยจำนวนเรือน้อยลง
    • WorldSmall: ปริมาณคอนเทนเนอร์เพิ่มขึ้น 35%, จำนวนเรือลดลง 7%
    • EuropeAsia: ปริมาณคอนเทนเนอร์เพิ่มขึ้น 14%, จำนวนเรือลดลง 15%
    • Pacific: ปริมาณคอนเทนเนอร์เพิ่มขึ้น 35%, จำนวนเรือลดลง 4%
    • Mediterranean: ปริมาณคอนเทนเนอร์เพิ่มขึ้น 32%, จำนวนเรือลดลง 23%
  • ตามสมมติฐานทางเศรษฐศาสตร์ของ LINERLIB อัตรากำไรที่คาดการณ์ก็ปรับดีขึ้นอย่างมากเช่นกัน

API และเอกสารที่จะเผยแพร่ต่อไป

  • Google มองว่าวิธีนี้เป็นวิธีแรกที่แก้ ปัญหาการออกแบบเครือข่ายและตารางเวลา ในระดับ WorldLarge ได้
  • ดูผลลัพธ์โดยละเอียดเพิ่มเติมได้ที่ หน้าเบนช์มาร์ก LSNDSP
  • Shipping Network Design API เป็นหนึ่งใน Operations Research APIs ที่จะเพิ่มเข้ามาในอนาคต

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-06-07
ความคิดเห็นบน Hacker News

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

    • เวลาดูปัญหาการเพิ่มประสิทธิภาพในอุตสาหกรรม มักจะเหมือนมีเงินก้อนมหาศาลถูกทิ้งไว้เฉย ๆ แต่ในความเป็นจริง ข้อจำกัดที่ขับเคลื่อนโดยคน ซึ่งไม่ได้ถูกบันทึกเป็นเอกสาร ทำให้งานซับซ้อนขึ้นมาก
      เช่น วิศวกรเยอรมันต่อต้านการล็อกฟังก์ชันของรถก่อนผลิตจริง เพราะถ้าล็อกแล้วจะเอาไปใช้เพื่อความบันเทิงยามว่างไม่ได้ ในแวดวงการแพทย์ ค่าโอทีไหลออกเป็นหลักพันล้านจนดูเหมือนว่าการปรับตารางงานน่าจะทำได้ง่าย แต่ก็มีข้อจำกัดจากสหภาพแรงงานจำนวนมาก และอุปทานการจ้างงานก็ไม่พอ สงสัยว่าโซลูชันของ Google จะสมจริงแค่ไหน มีข้อจำกัดอย่างขีปนาวุธฮูตีรวมอยู่ด้วยไหม จากประสบการณ์ บ่อยครั้งโซลูชันที่ ปรับตัวตามการเปลี่ยนแปลงที่คาดไม่ถึงได้ง่าย มีค่ามากกว่าคำตอบที่พิสูจน์ได้ว่าเหมาะที่สุด
    • ข้อมูล benchmark ที่ใช้ประเมินประสิทธิภาพมาจาก Maersk: https://github.com/blof/LINERLIB
    • ไม่ได้อยู่สายการเดินเรือ แต่ทำงานในภาคการผลิตมา 15 ปี โดยหลัก ๆ ทำด้าน test engineering และ automation รวมถึงคลังสินค้า/การจัดการวัสดุ และการขนส่ง/โลจิสติกส์ด้วย ปริญญาโทของผมเป็นด้าน operations research ในภาคการผลิต
      เห็นด้วยว่าการปรับให้เหมาะที่สุดแบบเป็นวัตถุวิสัยโดยมากค่อนข้างเป็นวิชาการ มักมีเหตุผลเสมอว่าทำไมจึงยากหรือเป็นไปไม่ได้ที่จะทำตามเวอร์ชันที่มีประสิทธิภาพที่สุดของกระบวนการมาตรฐานอย่างตรงตัว บางครั้งเป็นเหตุผล “งี่เง่า” ที่เกิดจากคน และบ่อยครั้งก็เป็นเหตุผลที่สมเหตุสมผลซึ่งสะท้อน externalities เช่น สภาพอากาศ downtime การหยุดชะงักของซัพพลายเชน และความไม่เรียบของสัญญาณอุปสงค์กับการพยากรณ์ตามฤดูกาล ถึงอย่างนั้น ผมก็คิดว่าแทบทุกครั้ง ควรเริ่มจากกระบวนการที่มีประสิทธิภาพที่สุดแล้วค่อยเพิ่มการจัดการข้อยกเว้น ดีกว่าสร้างกระบวนการมาตรฐานจากข้อยกเว้นที่รู้กันอยู่แล้ว ถ้าปล่อยให้ข้อยกเว้นกลายเป็นกฎ การดำเนินงานก็จะมีประสิทธิภาพต่ำกว่าจุดเหมาะที่สุดเสมอ
    • ผมก็ทำงานกับฝั่งเทอร์มินัลและบริษัทขนส่งทางบกเหมือนกัน มีคนมากมายพยายามแก้ปัญหาเชิงวิชาการที่ “ดูเท่” เช่น การปรับแผนการบรรทุกให้เหมาะที่สุด การจัดสรรท่าเทียบเรือ การแบ่งงานเครน แต่สิ่งที่ถูกนำไปใช้จริงมีน้อยมาก
      อุตสาหกรรมนี้ยาก และสหภาพแรงงานท่าเรือก็เข้มแข็งมาแต่เดิม ทำให้ภูมิทัศน์ทางการเมืองยิ่งยากขึ้น ปัญหาที่ดูเหมือนจะแยกส่วนและตั้งชื่อได้สะอาด ๆ ในความเป็นจริงกลับเกี่ยวพันกันหมด และถ้าคาดหวังว่าอัลกอริทึมจะ “เสก” คำตอบให้ผู้ใช้ได้ ก็มักล้มเหลวแทบทั้งนั้น อุตสาหกรรมนี้กลืนผู้เล่นซอฟต์แวร์เก่ง ๆ ที่คิดว่า “ก็แค่รัน traveling salesman problem / constraint solver / แนวทางที่อยากใช้ก็พอไม่ใช่เหรอ?” ได้ง่ายมาก แน่นอนว่าต้องการคนเก่ง แต่ต้องเริ่มอย่างถ่อมตัวและคุยกับผู้ใช้จริงก่อน ดูเหมือนในโปรไฟล์จะไม่มีช่องทางติดต่อ ถ้าอยากแลกเปลี่ยนความคิดกับบริษัทอื่นในอุตสาหกรรมนี้ ก็ส่งอีเมลมาหาผมได้ โดยเฉพาะอย่างยิ่ง เรากำลังทำงานที่น่าสนใจในเซกเมนต์ เทอร์มินัลที่ต่ำกว่า 1 ล้าน TEU ต่อปี ซึ่งมีสัดส่วนการขนส่งหลายรูปแบบสูง
    • อยากทราบว่าช่วยอธิบายงานที่ทำอยู่ตอนนี้ให้ละเอียดขึ้นอีกหน่อยสำหรับคนนอกสายนี้ได้ไหม

  • กำลังอ่าน The Box ซึ่งเล่าประวัติยุคแรกของการทำให้เป็นคอนเทนเนอร์ สนุกมากจริง ๆ
    ขอแนะนำอย่างยิ่งสำหรับคนที่มองหาหนังสืออ่านสนุกที่ผสมวิศวกรรม การออกแบบ ธุรกิจ และประวัติศาสตร์เข้าด้วยกัน มันทำให้ปัญหาเขียนโค้ดเล็ก ๆ ที่ผมเจอดูตลกไปเลย

    • เป็นหนังสือที่ยอดเยี่ยม และเห็นด้วยกับคำแนะนำ
      คงมีคนแย้งเยอะ แต่พูดจากใจจริง ผมคิดว่าอิทธิพลที่ ตู้คอนเทนเนอร์ทะเล 20 ฟุต มีต่อโลกนั้นมากกว่าอิทธิพลที่โมเดลภาษาขนาดใหญ่อาจจะทำได้ในอนาคตเสียอีก ลองอ่านหนังสือเล่มนั้นก่อน แล้วค่อยมาบอกว่าทำไมผมถึงผิด แน่นอนว่าผมไม่ได้ผิด
    • บทความ Wikipedia ของ “The Box”: https://en.m.wikipedia.org/wiki/The_Box_(Levinson_book)
    • ที่ Flexport เคยแจกหนังสือเล่มนี้ให้พนักงานใหม่ อย่างน้อยเมื่อไม่กี่ปีก่อนก็เป็นแบบนั้น

  • ดูเหมือนว่าในกองเรือขนาดใหญ่มาก การเพิ่มประสิทธิภาพคอนเทนเนอร์ ยังเป็นปัญหาที่ยังแก้ไม่ตก ไม่เคยรู้มาก่อน
    ถ้า operations research ของ Google ช่วยเพิ่มอัตราการใช้งานได้ 10–20% เมื่อเทียบกับโซลูชันเดิม ก็ถือว่าน่าทึ่งมาก

    • ฟังดูเหมือน packing problem ผมไม่ได้รู้ลึกในสาขานี้ แต่เท่าที่รู้ไม่มีคำตอบทั่วไป
      https://en.wikipedia.org/wiki/Packing_problems

  • อยากรู้มากว่าจะมีใครใช้ API endpoint ที่เปิดเผยนี้จริงไหม: https://developers.google.com/optimization/service/shipping/...
    ถึงอย่างนั้นก็ค่อนข้างเจ๋ง

    • จากประสบการณ์ทำงานเชิงวิชาชีพที่ Google Cloud ระหว่างปี 2015–2023 operations research API แบบนี้มัก 1) เป็นเชิงวิชาการ และ 2) มีลักษณะถูกใช้เชิงพาณิชย์โดย solution architect และวิศวกรของ Google Cloud เมื่อต้องสร้างโซลูชันธุรกิจแบบปรับแต่งเฉพาะลูกค้าที่รันบน GCP
      ตัวอย่างเด่นคือ Route Optimization API ก็ถูกทีม operations research ขององค์กรเปิดเผยในลักษณะนี้ และภายหลังโซลูชัน Fleet Engine ก็ถูกสร้างทับบนสิ่งนั้น โดยอาศัย input จากลูกค้า alpha บางราย ผมคิดว่าก่อนที่ operations research API จะถูกเปิดเผยผ่าน Google Cloud ก็ยังไม่มี SLA หรือการรับประกันความน่าเชื่อถือ ดังนั้นนอกจากใช้เชิงวิชาการแล้ว ไม่ควรใช้ นี่เป็นความเห็นเล็ก ๆ ของผม
      https://developers.google.com/maps/documentation/transportat...
    • การไม่ลองใช้อาจเป็นเรื่องไม่รับผิดชอบเสียด้วยซ้ำ สงสัยว่านี่คือรูปแบบทั้งหมดของปัญหาและข้อจำกัดที่ผู้วางแผนต้องเผชิญหรือไม่ Flexport เป็นบริษัท รายได้ 3.3 พันล้านดอลลาร์ ที่ตั้งอยู่ใน SF และอยู่ในสาขานี้
    • สุสานของ Google[1] โตเร็วขึ้นเรื่อย ๆ เลยต้องระวังกับประกาศใหม่ ๆ ของ Google API แบบนี้น่าจะเป็นปัญหาใหญ่เป็นพิเศษเมื่อต้องหาอะไรมาทดแทนในอนาคต
      [1]: https://killedbygoogle.com/

  • ถ้าไม่ได้คำนึงถึง demurrage ก็ไม่แน่ใจว่าคุ้มค่าที่จะลองจริง ๆ หรือไม่
    https://developers.google.com/optimization/service/reference...

  • Omega Tau Podcast ทำเอพิโสด[0] ที่ดีมากเกี่ยวกับการขนส่งตู้คอนเทนเนอร์ และครอบคลุมทั้งการปรับเหมาะการจัดวางตู้คอนเทนเนอร์กับการวางแผนเส้นทาง แนะนำอย่างยิ่ง
    [0]: https://omegataupodcast.net/146-container-shipping/

  • ประโยคที่ว่า “ต่างจากเครื่องบิน เรือบรรทุกสินค้าปฏิบัติการแทบจะตลอดเวลา” ยังมีจุดให้ถกเถียงได้อยู่บ้าง
    เรือบรรทุกสินค้ามีการบำรุงรักษาระหว่างเดินเรืออยู่มากก็จริง แต่นอกเหนือจากนั้นผมมองว่าความต่างเล็กกว่านั้นมาก ที่ท่าเรือ เรือจะวนรอบด้วยการขนถ่ายและบรรทุกสินค้าเป็นเวลาหลายวัน และบางครั้งก็ต้องรอหลายชั่วโมงหรือหลายวันเพื่อรอท่าเทียบเรือ จากกรณี Delta A350 ถ้าหักเวลาหมุนเวียน 3 ชั่วโมงที่สนามบินออก ก็แทบจะเคลื่อนที่ตลอด 24 ชั่วโมง: https://www.flightradar24.com/data/aircraft/n513dz

    • ผมคิดว่าระหว่างขนถ่ายสินค้าก็เรียกว่า “กำลังปฏิบัติการ” ได้เหมือนกัน

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

    • หลายคนไม่ชอบให้เวลาทำงานเปลี่ยนไปมากนัก
      คุณอาจเติมกะในคืนที่พนักงานครึ่งหนึ่งไปดู Taylor Swift ได้ แต่ถ้าเรียกคนเหล่านั้นออกมา กะถัดไปของพวกเขาก็ต้องให้ใครสักคนมาแทนอีก แล้วพอทำต่อ ๆ กันไปก็จะกลายเป็นตารางงานที่ต่างไปโดยสิ้นเชิง ประกอบด้วยคนที่ไม่เคยทำงานร่วมกันเลยสักครั้ง ถ้าใส่ข้อจำกัดเพิ่มก็อาจแก้ได้ แต่แค่เขียนข้อจำกัดทั้งหมดออกมาและจัดลำดับความสำคัญก็ไม่ใช่เรื่องง่ายแล้ว คนเราไม่ใช่ บล็อกเลโก้
    • นี่เป็นปัญหาที่ผมอยากแก้จริง ๆ ผมได้ยินเรื่องแบบเดียวกันจากแทบทุกคนที่จัดตารางงาน
      ผมมีพื้นฐานด้านการวิจัยดำเนินงาน จึงรู้สึกแปลกอยู่เสมอ ปัญหาเหล่านี้ดูเรียบง่ายพอจะสร้างแบบจำลองและแก้ด้วย solver ทั่วไป และแม้ไม่ใช้เทคนิคขั้นสูงก็ดูมีคุณค่ามาก ปัญหาคือโดยรวมแล้วการวิจัยดำเนินงานเข้าถึงได้ยาก solver ส่วนใหญ่ที่มีการสนับสนุนดีบังคับให้กำหนดปัญหาในพาราไดม์ทางคณิตศาสตร์ ซึ่ง “คนทั่วไป” เห็นแล้วก็รู้สึกหนักใจทันที มีโซลูชันสำเร็จรูปสำหรับปัญหาจัดตารางงานทั่วไปอยู่เหมือนกัน แต่ถ้าไม่ได้เริ่มใช้ตั้งแต่แรก แต่ละธุรกิจก็จะมีรูปแบบเฉพาะของตัวเอง ทำให้นำมาใช้เต็มรูปแบบได้ยาก ระบบอาจไม่รองรับรูปแบบนั้น หรือไม่รู้ว่าจะยัดมันเข้าไปในเครื่องมือได้อย่างไร แม้จะตั้งใจอยากแก้ตารางงานให้ดีขึ้น คอร์สที่หาเจอก็มักสมมติว่ามีพื้นฐานการเขียนโปรแกรมหรือคณิตศาสตร์ค่อนข้างมาก ผมคิดว่าน่าจะทำ สภาพแวดล้อมการสร้างแบบจำลองแบบ no-code สำหรับปัญหาจัดตารางงาน ที่ “คนทั่วไป” ซึ่ง Excel ไม่พอใช้แต่ก็จ้างผู้เชี่ยวชาญด้านการวิจัยดำเนินงานไม่ได้ สามารถใช้ได้
    • นี่เป็นปัญหาที่สำคัญจริง ๆ และมีซอฟต์แวร์จำนวนมากที่จัดการเรื่องนี้อยู่แล้ว
      แทบทุกระบบ HR/การจัดการกำลังคนขนาดใหญ่มีตัวเลือกที่เกี่ยวข้องอยู่ เช่น https://www.workday.com/en-us/products/workforce-management/... และ https://www.oracle.com/human-capital-management/workforce-ma... และยังมีผู้ให้บริการเฉพาะทางอีกมาก อย่างไรก็ตาม อย่างที่คนอื่นบอก ระบบเหล่านี้ก็เคยมีข้อถกเถียง เพราะบางส่วนถูกใช้ในลักษณะที่ไม่คำนึงถึงความจำเป็นตามปกติของมนุษย์ เช่น จัดให้ทำงานต่อเนื่องกัน เปลี่ยนตารางด้วยการแจ้งล่วงหน้าสั้น ๆ หรือไม่สามารถคำนึงถึงสถานการณ์จริงอย่างการเลี้ยงลูกที่ผู้จัดการที่เป็นมนุษย์อาจนำมาพิจารณาได้
    • กลุ่มการวิจัยดำเนินงานเดียวกันมีตัวอย่างการจัดตารางสำหรับร้านอาหาร: https://developers.google.com/optimization/service/schedulin...
    • ผมมีพื้นฐานด้านการปรับเหมาะเชิงจัดหมู่อยู่บ้าง เลยเคยคิดว่าจะลองทำซอฟต์แวร์ในสายนี้หรืออย่างการวางแผนตารางเรียนของโรงเรียน
      แต่ปัญหาคือแต่ละที่ทำงานมีข้อจำกัดต่างกัน เช่น ในกะหนึ่งต้องมีคนที่ปฐมพยาบาลได้อย่างน้อย 1 คน, Alice กับ Bob เข้ากันไม่ได้, ห้ามทำงานวันเสาร์ 2 สัปดาห์ติดกัน, กะเปลี่ยนทุก 2 สัปดาห์, ต้องมีเวลาพักระหว่างกะอย่างน้อย 12 ชั่วโมง เป็นต้น เครื่องมือที่ยืดหยุ่นพอให้องค์กรจำนวนมากใช้ได้ สุดท้ายก็น่าจะซับซ้อนจนใช้งานยากเกินไป

  • ยังสงสัยอยู่เหมือนกันว่า แผนการบรรทุกสินค้า ของเรือประเภทนี้เป็นอย่างไร
    น่าจะเป็นปัญหาที่ต้องแก้แบบประมาณในขั้นตอนถัดจากการวางแผนเส้นทางของตู้คอนเทนเนอร์แต่ละตู้ แผนการบรรทุกสินค้าจะมาทีหลัง และมีข้อจำกัดที่ขึ้นกับสถานการณ์มากกว่ามุมมองระดับระบบโดยรวมอย่างมาก ต่อให้มองแบบมองโลกในแง่ดีคร่าว ๆ ปั้นจั่นหน้าท่าเรือก็เคลื่อนย้ายได้ 30–50 ครั้งต่อชั่วโมง มี 2 หรือ 4 ตัวต่อเรือหนึ่งลำ และถ้ามากก็มี 6 ตัว โดยต้องค่อย ๆ แกะเป็นชั้น ๆ เหมือนเปลือก เรือ Ultra Large Container Vessel คือ 14,501 TEU ขึ้นไป, New Panamax คือ 10,000–14,500 TEU, Post-Panamax คือ 5,101–10,000 TEU, Panamax คือ 3,001–5,100 TEU ถ้าคิดว่า 24,000 TEU เท่ากับตู้คอนเทนเนอร์ 40 ฟุต 12,000 ตู้ ก็จะเป็น 4 ตัว × 50 ตู้ต่อชั่วโมงต่อปั้นจั่น × 24 ชั่วโมงต่อวัน = ประมาณ 1,200 ตู้คอนเทนเนอร์ต่อวัน
    https://en.wikipedia.org/wiki/Stowage_plan_for_container_shi...
    นอกจากความพร้อมใช้งานที่ท่าเรือแล้ว แผนการบรรทุกสินค้าบนเรือยังมีเกณฑ์ที่ต้องยอมรับได้เรื่องน้ำหนัก การทรงตัว ไฟฟ้า และมูลค่าสินค้า ในบทความพูดถึงการออกจากท่าเรือก่อนกำหนด เลยสงสัยเรื่อง overhead แบบนี้และลองคำนวณคร่าว ๆ ดู

    • มีการบรรยายที่นักวิจัยจาก Technical University of Denmark (DTU) อัปโหลดไว้ทางออนไลน์ ซึ่งค่อนข้างดีสำหรับเป็นบทนำของ ปัญหาการจัดวางสินค้า: https://www.youtube.com/watch?v=9ltz4G-lPdg
      ในฐานะคนที่เกี่ยวข้องกับงานด้านนี้จริง ๆ มีหลายวิธีที่จะทำให้งานของตัวเองง่ายขึ้น การวางแผนเป็นบล็อกตามฝาครอบระวางเรือแต่ละส่วน และการจัดกลุ่มตู้คอนเทนเนอร์ตามปลายทาง ขนาด และน้ำหนักแล้วถือว่าสามารถทดแทนกันได้ ถือเป็นเรื่องพื้นฐาน จากนั้นก่อนเริ่มงาน หากส่งแผนจากเรือไปยังเทอร์มินัล เทอร์มินัลก็รู้ตำแหน่งตู้คอนเทนเนอร์ในลานอยู่แล้ว จึงสามารถทำการปรับให้เหมาะสมและจัดย้ายใหม่ได้ หากตัดสินใจมองข้ามรายละเอียดของตู้คอนเทนเนอร์แต่ละตู้แล้วโฟกัสเฉพาะกลุ่ม แผนการบรรทุกสินค้าจะง่ายขึ้นมาก ผลลัพธ์ออกมาใกล้เคียงกันมากโดยใช้แรงงานน้อยกว่ามาก และเทอร์มินัลก็มีความยืดหยุ่นในการปรับการดำเนินงานให้เหมาะสมมากขึ้น