ภาพหลอนหมู่ของ LLM ในที่ทำงานของเรา

• บันทึกประสบการณ์ตรงจากสถานที่ทำงานที่กำลังเผชิญ วิกฤตงบประมาณ ซึ่งแม้งบสำหรับงานหลักจะถูกตัด แต่กลับยังมีเงินไหลไปกับ การนำ AI มาใช้ อย่างขัดแย้ง
• ตลอดหลายปีที่ผ่านมา โบนัสถูกยกเลิก การลดคน ลดไลเซนส์ และลดฐานข้อมูลเกิดขึ้นต่อเนื่อง แต่ค่าใช้จ่ายสำหรับ ที่ปรึกษา, เวิร์กช็อป LLM, ไลเซนส์ ChatGPT·Copilot กลับได้รับอนุมัติทันที
• ในการประชุมทั้งองค์กรที่มีผู้เข้าร่วมหลายร้อยคน หลายทีมได้ลองทำโปรเจกต์ LLM แต่ ไม่มีแม้แต่โครงการเดียวที่สำเร็จ
• กรณีใช้งานทั่วไปที่ถูกนำเสนอมีเพียงการถามบอตว่าอารมณ์เป็นอย่างไร, สรุปเมนูอาหารกลางวัน 1 หน้า, หรืออัปโหลดอีเมลน่าสงสัยเข้า ChatGPT ซึ่งล้วนไร้สาระหรือเสี่ยงอันตราย
• ผู้เขียนนิยามปรากฏการณ์นี้ว่าเป็น ภาพหลอนหมู่ที่ควบคุมไม่ได้ และมองว่านี่คือช่วงเวลาแห่ง การพังทลายของความไว้วางใจ เมื่อเห็นชัดว่าสิ่งที่ผู้นำทำได้หากต้องการนั้นที่ผ่านมาแค่ถูกกันไว้โดยตั้งใจ

---

สถานะการเงินที่ขัดแย้งกันและเบื้องหลังการนำ AI มาใช้

• นายจ้างกำลังเผชิญ ปัญหาการเงินเรื้อรัง และตำแหน่งที่ว่างก็ปล่อยหายไปโดยไม่มีการเติมคน
  • เมื่อ 2 ปีก่อน โบนัสของพนักงานที่ผลงานดีถูกยกเลิกถาวร
  • ทรัพยากรจำเป็นถูกตัดลดลง พร้อมแจ้งเพียงว่า "ไปหาทางเอาเอง"
  • หลายแผนกต้องทำงานหนักเกินกำลังโดยไม่มีการเพิ่มคน และเพื่อประหยัดค่าใช้จ่ายจึงมีการ ลบไลเซนส์และฐานข้อมูลสำคัญ
• แต่ท่ามกลางฉากหลังเช่นนี้ ค่าใช้จ่ายด้าน AI กลับเป็นข้อยกเว้นที่ได้รับอนุมัติ
  • มีงบสำหรับ จ้างที่ปรึกษา ที่แนะนำให้ "ทุ่มสุดตัว"
  • มีงบสำหรับ เวิร์กช็อป·สัมมนา LLM ภายนอก หลายปี
  • มีงบสำหรับ ไลเซนส์ทั้ง ChatGPT และ Copilot
• ผู้เขียนชี้ว่าโบนัสพนักงานและงบสนับสนุนการทำงานกำลังไหลไปหาพวกต้มตุ๋น ความเสี่ยงด้านความปลอดภัย เวิร์กช็อปไร้ประโยชน์ และพวกเทคโนฟาสซิสต์

ความล้มเหลวโดยสิ้นเชิงของโปรเจกต์ LLM ระดับทั้งองค์กร

• มีการจัด ประชุมซ้ำ ๆ ให้แต่ละแผนกลงทะเบียนและทดลองโปรเจกต์ LLM แล้วมานำเสนอผล
• แม้จะเข้าร่วมทุกการประชุม แต่ ไม่มีกรณีที่สำเร็จจริงแม้แต่ครั้งเดียว
  • มีคนหลายร้อยคน หลายทีม คนที่กระตือรือร้นกับ AI และโปรเจกต์ทุกรูปแบบเข้าร่วมทดลอง
  • ทุกโปรเจกต์จบลงด้วยข้อสรุปว่า "ใช้ไม่ได้", "ไม่ประหยัดเวลา", หรือ "ยิ่งทำให้ซับซ้อนขึ้น"
• แม้จะมีเวิร์กช็อป, "prompt engineering", custom GPT, เอกสารและเทมเพลตก่อนเตรียมงาน ก็ยังสร้าง ผลลัพธ์ที่ทำซ้ำได้ ไม่สำเร็จ (ไม่ใช่งานด้านโค้ดดิ้ง)
  • ทุกครั้งมันเป็น การพนันที่เละเทะ และต้องเสียเวลามากกับการปรับจูน การลองซ้ำ การตรวจผลลัพธ์ และการแก้ข้อผิดพลาด
  • ปัญหาที่ถูกร้องเรียนมากที่สุดคือการไม่สะท้อนข้อมูลบางเอกสาร, hallucination, และการกรอกหรือแก้ไขเอกสารได้ไม่ถูกต้อง
  • แม้แต่ใน Enterprise license ก็ยังมีข้อจำกัดมากเกินไป

การสาธิตกรณีใช้งานทั่วไปที่ไร้ความหมาย

• ยังมีการประชุมเพื่อนำเสนอ กรณีใช้งานทั่วไป สำหรับงานประจำวัน ซึ่งไม่เกี่ยวกับโปรเจกต์เฉพาะใด ๆ
• มีการ สาธิตอย่างจริงจัง ถึงฟังก์ชันที่ถามบอตว่า "วันนี้รู้สึกยังไงบ้าง?"
  • ไม่ใช่มุกตลกหรือการเสียดสี แต่ถูกนำเสนอในนามของความล้ำอนาคตและความเป็นมนุษย์
  • ผู้เขียนเน้นว่าถ้าเป็นเมื่อ 5 ปีก่อน ข้อเสนอให้จ่ายค่าสมัครหลายพันดอลลาร์เพื่อคุยเรื่องไร้สาระกับบอตคงถูกหัวเราะเยาะ และปฏิกิริยาแบบนั้นก็ยัง ถูกต้องอยู่
• มีการสาธิตกรณีเอา เมนูโรงอาหารในอินทราเน็ต 1 หน้า (ไฟล์ Excel) อัปโหลดเข้า ChatGPT แล้วถามว่า "วันพุธมื้อกลางวันมีอะไร"
  • คำตอบของบอตยาวกว่าการอ่านทั้งชีตเสียอีก
  • การดาวน์โหลด อัปโหลด และเขียนพรอมป์ตกินเวลานานกว่าการอ่านชีตโดยตรง
  • บอตจึงไม่จำเป็นสำหรับ ข้อมูลที่เห็นได้ในพริบตาเดียว
• ในอีกตัวอย่างหนึ่งซึ่ง หัวหน้า IT เป็นผู้เสนอเอง เขาแนะนำให้บันทึกอีเมลสแปม ฟิชชิง หรือเมลพร้อมไฟล์แนบน่าสงสัยไว้บนเดสก์ท็อป แล้วอัปโหลดเข้า ChatGPT เพื่อตรวจสอบ
  • ผู้เขียนชี้ถึงความเสี่ยงของการทำให้พนักงานที่ไม่คุ้นเคยกับเทคโนโลยี บันทึกไฟล์น่าสงสัยลงในโน้ตบุ๊กทำงาน

AI ที่ขยายผล Dunning-Kruger effect

• AI กำลังขยาย Dunning-Kruger effect ของผู้คน ทำให้ทุกสิ่งที่พวกเขาลองดูฉลาดและชอบธรรมขึ้น
  • ผู้คนจึงแสร้งเหมือนกำลังทำสิ่งสำคัญและพลิกวงการ ทั้งที่จริงทำเพียงงานธรรมดาไร้คุณค่า
  • ฝ่ายที่สนับสนุนเทคโนโลยีรู้สึกว่าตัวเองเป็นส่วนหนึ่งของการปฏิวัติครั้งใหญ่ และจินตนาการถึงวันที่คนวิจารณ์จะต้องมาขอโทษ
• ผู้เขียนกังวลกับปรากฏการณ์ที่คนมีความรับผิดชอบและมีความสามารถกลับกลายเป็น กระบอกเสียงประชาสัมพันธ์ของบริษัท AI โดยไม่มีเหตุผลชัดเจน
  • คนที่มีคุณสมบัติเหมาะสมกลับลดตัวเองลงไปเทียบเท่านักขายตรงที่ออกมาโฆษณาสรรพคุณผงซักฟอกเกินจริง

ไฮป์ล้วน ๆ และการพังทลายของความไว้วางใจ

• แม้จะไม่มีปัญหาเฉพาะที่ต้องแก้ และพนักงาน อย่างน้อย 90% ก็ไม่ได้ทำงานที่จะได้ประโยชน์จาก Copilot หรือเครื่องมือคล้ายกัน แต่การนำมาใช้ก็ยังถูกผลักดัน
  • มีการสร้างปัญหาขึ้นมาในที่ที่เดิมไม่มี เพื่อใช้ token และทำให้ค่าสมัครดูสมเหตุสมผล
  • ผู้เขียนมองว่านี่คือการกระทำเพื่อเอาไปแสดงต่อผู้บริหารว่า "อย่างน้อยก็ได้ลองแล้ว"
• การใช้งานทั้งหมดถูกทำให้ชอบธรรมด้วยคำว่า "การสำรวจ" และ "การเล่น" ขณะที่ การเสียเวลา การสิ้นเปลืองงบ และอำนาจที่อยู่เบื้องหลัง ถูกลดทอนความสำคัญ
• มีการตั้งคำถามถึงความเร็วในการนำ AI มาใช้
  • องค์กรที่พูดเสมอว่าไม่มีเงิน กลับอนุมัติเทคโนโลยีที่ไม่เสถียรและมี ต้นทุนเริ่มต้นมหาศาล ได้ทันที
  • เทคโนโลยีใหม่ที่เคยไม่สามารถผ่านเข้าไปในภาครัฐได้ คราวนี้กลับได้รับความสนใจทั้งหมด
  • องค์กรที่ปกติต้องใช้เวลาหลายปีถึงหลายสิบปีในการเปลี่ยนแปลง กลับสร้างทั้งโครงสร้างพื้นฐาน AI และศักยภาพระดับองค์กรได้ ในพริบตา
• นี่คือช่วงเวลา หน้ากากหลุด ที่เผยให้เห็นว่าความเปลี่ยนแปลงอันเชื่องช้าขององค์กรไม่ใช่ค่าปกติพื้นฐาน แต่เป็น การออกแบบโดยตั้งใจ
  • อุปสรรคเหล่านั้นไม่ได้เป็นเรื่องจำเป็นโดยเนื้อแท้ แต่เป็นเรื่องโกหกตามอำเภอใจ
  • สำหรับพนักงาน นี่คือ ช่วงเวลาที่ทำลายความไว้วางใจลงอย่างสิ้นเชิง

โจทย์ต่อจากนี้

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

[cnaa97]

ถึงจะยังไม่มีผลลัพธ์ แต่อาจเป็นความพยายามที่จะพยุงองค์กรและเอาชีวิตรอดต่อไปไม่ทางใดก็ทางหนึ่งก็ได้...

[brilliant08]

ถ้าความพยายามนั้นถูกชี้ว่า "เงินทุนกำลังไหลไปหาพวกนักต้มตุ๋น ความเสี่ยงด้านความปลอดภัย เวิร์กช็อปไร้ประโยชน์ และพวกเทคโนฟาสซิสต์" ก็คงไม่ใช่ความพยายามที่ทำได้ดีนัก

[GN⁺]

ความคิดเห็นจาก Lobste.rs

• ที่ทำงานของฉันก็ไม่ได้แย่ขนาดนี้ แต่ทิศทางเหมือนกัน ไม่มีงบสำหรับการจ้างคนใหม่หรือขึ้นเงินเดือน แต่มีเงินสำหรับ ที่ปรึกษาธุรกิจ, ไลเซนส์ซอฟต์แวร์ COTS ระดับองค์กรราคาแพง, และ subscription AI เสมอ

  • ฟังดูเหมือนทำงานในหน่วยงานรัฐบาลที่ตั้งอยู่ในสหรัฐฯ นอกวงการรัฐบาลแล้วคนมักไม่ค่อยใช้คำว่า COTS
    ต่อให้ตัดความประชดออกไปนิดหน่อย แม้แต่ในองค์กรที่แข็งตัวน้อยกว่ารัฐบาล ก็ยังเป็นเรื่องปกติที่งบสำหรับ “ซื้อของ” จะหาได้ง่ายกว่างบสำหรับ “จ่ายให้พนักงาน”

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

  • เมื่อไม่กี่เดือนก่อน ฉันก็ได้ยินเรื่องคล้ายกันมากจากเพื่อนใน FAANG ตอนนั้นเป็นช่วงที่ tokenmaxxing กลายเป็นนโยบาย
    ไม่ได้แปลว่า FAANG ปลอดจากความไร้ความสามารถระดับร้ายแรง แต่หมายความว่าบรรยากาศแบบ “โอ้ มันสรุปอีเมลกับเมนูมื้อกลางวันให้ได้ด้วยเหรอ?!” แพร่หลายกว่าที่คิดมาก

• โดยรวมแล้วฉันคิดว่าประสบการณ์ของตัวเองออกไปทางบวกมากกว่านิดหน่อย

  1. ถ้าใช้อย่างไม่รับผิดชอบ coding agent จะทำลาย codebase ได้ มันใช้ได้โอเคกับต้นแบบเล็ก ๆ ที่ใช้ครั้งเดียว หรือใช้แทน SaaS ห่วย ๆ แบบสุด ๆ แต่ไม่เหมาะกับระบบที่จริงจัง Claude Fable ก็แค่สร้าง ความโกลาหลที่ใหญ่กว่าเดิมมาก เท่านั้น
  2. ถ้าจะใช้อย่างรับผิดชอบ ต้องมีวินัยในตัวเองและมีคนที่เหมาะสม ซึ่งในกรณีนั้น coding agent ก็ช่วยได้อยู่ คอขวดยังคงเป็นเรื่องที่คนต้องเข้าใจโค้ดและปรับความเข้าใจให้ตรงกับผู้มีส่วนได้ส่วนเสียอยู่ดี ดังนั้นมันจึงไม่ได้พลิกโลกอย่างที่หลายคนคิด แต่ถ้ามันหายไปทั้งหมดก็คงเสียดายนิดหน่อย เพราะฉันไม่อยากเขียนโค้ดทดสอบฉบับร่างเพื่อรับมือกับ vendor API แปลก ๆ ด้วยตัวเอง
  3. งาน data mining จากเอกสารจำนวนมากหลายประเภท แสดงให้เห็นชัดว่า LLM ราคาถูกและประมวลผลได้ปริมาณมากมีข้อดีจริง ถ้ายอมรับอัตราความผิดพลาดได้
  4. ผู้จัดการชอบ use case ของ AI ที่ราคาสมเหตุสมผลและใช้งานได้จริง
     แต่พอเดินผ่านสนามบินแล้วเห็นโฆษณา AI ที่เล็งกลุ่มผู้บริหาร ก็รู้เลยว่าสถานการณ์ข้างนอกมันหนักจริง ๆ
  • ในบางแง่ มันทำให้นึกถึงการถกเถียงเรื่อง static type vs dynamic type ถ้าเป็นทีมที่เหมาะสมและมีประสบการณ์มากพอ ก็สามารถทำงานได้อย่างมีประสิทธิภาพมากด้วยภาษาอย่าง Clojure แต่ถ้าคนเริ่มใช้ภาษาแบบผิด ๆ และพยายามทำตัวฉลาดเกินไป มันก็อาจกลายเป็นความยุ่งเหยิงน่าสยดสยองที่ดูแลรักษาไม่ได้
    การใช้ LLM ก็ให้ความรู้สึกคล้ายกันมากในแง่นั้น ถ้าเข้าใจว่าเครื่องมือทำอะไรได้และควรนำไปใช้อย่างมีประสิทธิภาพอย่างไร มันก็ช่วยประหยัดเวลาได้จริง แต่ถ้าเอาแต่ปั๊มโค้ดออกมาให้เร็วที่สุด สุดท้ายก็จะกลายเป็นความยุ่งเหยิงที่แทบเจาะเข้าไปทำความเข้าใจไม่ได้