1) ความน่าเชื่อถือของบทความน่าสงสัย: มีกลิ่นงานการตลาด/งานที่สร้างโดย AI

ใจความหลัก

• “อันนี้มันเรียบเรียงมาเป็นนิทานสอนใจดีเกินไป” → เลยมีคนสงสัยว่ามันเป็นประโยคที่ปรับมาให้เข้ากับ ‘ละครสอนศีลธรรม’ แบบที่ HN ชอบ
• ในเนื้อหามีลิงก์ไปยังแหล่งข้อมูลแบบเสียเงินแปะเต็มไปหมด จนหลายคนมองว่า “สุดท้ายมันก็เป็นบทความขายของไม่ใช่เหรอ”
• สไตล์การเขียนแบบยัดลิสต์รัวๆ/ใช้อีโมจิ ถูกชี้ว่าเป็นสัญญาณของ “AI slop (คอนเทนต์ AI แบบปั่นหยาบๆ)”

คำพูดตรงแรงๆ (แปล)

“ดูเหมือนทั้งเรื่องมีไว้เพื่อขายแหล่งข้อมูลแบบเสียเงินที่ลิงก์ไว้ และมันก็ให้ความรู้สึกเหมือน AI slop จากการยัดลิสต์มาเต็มไปหมด”
(ต้นฉบับ: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)

สรุปสั้นๆ

• “ก่อนจะเถียงกันว่าเนื้อหาถูกหรือผิด กลิ่นขายของ + กลิ่น AI มันแรงเกินไป” คือปฏิกิริยาอันดับหนึ่ง

2) วิจารณ์ฝั่งผู้นำ/สถาปนิกระบบ: ปัญหาไม่ใช่เทคโนโลยี แต่คือ ‘โครงสร้างการตัดสินใจ’

ใจความหลัก

• หลายคนมองว่าแค่ “ทีม 4 คนแต่มีสถาปนิกระบบ?” ก็เริ่มผิดทางแล้ว
• โดยเฉพาะบทบาทแบบ สถาปนิกที่ไม่เขียนโค้ด/บทบาท DevOps ที่แยกออกมาต่างหาก ถูกมองว่าเป็นทั้ง ‘คอขวด + การออกแบบเพื่อแต่ง CV’
• น้ำเสียงโดยรวมคือไม่ใช่ microservices ที่ทำบริษัทพัง แต่เป็น “โครงสร้างที่ไม่มีใครรับผิดชอบเรื่อง deploy/operate/เก็บกวาดปัญหาอย่างจริงจัง” ต่างหาก

คำพูดตรงแรงๆ (แปล)

“สถาปนิกที่มีหน้าที่กำหนด ‘กฎ’ กับ ‘แพตเทิร์น’ โดยที่ไม่ได้ลงมือทำอะไรจริง แทบจะเป็นไอเดียที่แย่เสมอ แค่โฟกัสที่การปล่อยของก็พอ... ถ้าคนที่ไม่เขียนโค้ดแม้แต่ 10 บรรทัดจะผูกขาดการตัดสินใจ มันก็พังแน่”
(ต้นฉบับ: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)

สรุปสั้นๆ

• มีคนเห็นค่อนข้างมากว่า ไม่ใช่ MSA ที่เป็นปัญหา แต่เป็น ‘การออกแบบบทบาทที่มีอำนาจตัดสินใจแต่ไม่มีความรับผิดชอบ’

3) มุมมองเชิงธุรกิจ: สตาร์ตอัปล้มเหลวเพราะ MSA จริงหรือ?

ใจความหลัก

• มีคอมเมนต์ที่ไม่เชื่อกรอบเรื่องเล่าแบบ “พังเพราะสถาปัตยกรรม” ตั้งแต่ต้น
• ประเด็นหลักคือ ถ้า PMF/ดีมานด์/การล็อกอินลูกค้า อ่อน ไม่ว่าใช้สแตกไหนก็พังได้อยู่ดี
• โดยเฉพาะรายละเอียดอย่าง “ลูกค้าเห็นว่าช้าลงสองวันก็ย้ายออกทันที?” ทำให้มีคนจี้ว่าจริงๆ แล้วคุณค่าของผลิตภัณฑ์มันอาจอ่อนอยู่แล้วหรือเปล่า
• และยังมีการชี้ความขัดแย้งในบทความเองด้วย: บอกว่า “MSA ฆ่าสตาร์ตอัป” แต่บทสรุปกลับเป็น “รอดมาได้?” → เลยยิ่งน่าสงสัยว่าเป็นการเล่าเรื่องเกินจริง

คำพูดตรงแรงๆ (แปล)

“ที่ฆ่าสตาร์ตอัปคือการทำผลิตภัณฑ์ที่คนไม่ต้องการต่างหาก ไม่ใช่สถาปัตยกรรม เรื่องนี้ก็พอๆ กับการบอกว่าเลือก Python แทน Go เลยทำให้สตาร์ตอัปพัง มันฟังไม่ขึ้น”
(ต้นฉบับ: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)

สรุปสั้นๆ

• มีมุมมองหนึ่งอย่างชัดเจนว่า “สถาปัตยกรรมเป็นแค่ข้ออ้าง ส่วน ต้นเหตุจริงอาจเป็นตลาด/ผลิตภัณฑ์/กระแสเงินสด”

4) ข้อคิดทางเทคนิค: คำแนะนำจากประสบการณ์จริงเรื่อง monolith vs MSA (ส่วนที่เป็นประโยชน์จริง)

ใจความหลัก

• “MSA มีภาษีต้นทุนคงที่ (ความซับซ้อนในการปฏิบัติการ)” → หลายคนมีประสบการณ์ตรงว่ามันอาจเป็นหมัดหนักสำหรับทีมเล็ก
• คีย์เวิร์ดสำคัญคือ Premature distribution (กระจายระบบเร็วเกินไป), modular monolith/modulith, และ “จง ‘หาให้ได้’ ก่อนว่าขอบเขตอยู่ตรงไหน”
• เงื่อนไขที่ MSA เริ่มจำเป็นก็ถูกเสนออย่างเป็นจริงเป็นจัง: ตอนที่ทีมใหญ่ขึ้นจนปัญหาเรื่องการชนกันของงาน/deploy/โครงสร้างองค์กรเกิดขึ้นจริง
• ในทางกลับกัน ถ้าเป็นปัญหาเรื่องประสิทธิภาพ/การขยายระบบ หลายคนก็แนะนำว่าโดยมากไม่ใช่ “แก้ด้วย MSA” แต่ควรเริ่มจากดู algorithm/คอขวด/sharding/partitioning ก่อน

คำพูดตรงแรงๆ (แปล)

“ที่ฆ่าสตาร์ตอัปไม่ใช่ microservices แต่คือ ‘การกระจายระบบเร็วเกินไป’ ต่างหาก คุณแยกระบบก่อนที่ขอบเขตจริงจะเกิดขึ้น เลยมีแต่ต้นทุนด้าน latency กับการประสานงาน ควรเริ่มจาก modular monolith แล้วค่อยๆ สร้างขอบเขตให้ชัดก่อนค่อยแยก”
(ต้นฉบับ: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)

สรุปสั้นๆ

• บทเรียนที่ชุมชนเห็นพ้องจริงๆ คือข้อนี้:
  “เริ่มจาก monolith แล้วค่อยแยก service ก็ต่อเมื่อขอบเขตมัน ‘เกิดขึ้นเองตามธรรมชาติ’ เท่านั้น”

สรุปภาพรวมของชุมชนในประโยคเดียว

คนส่วนใหญ่เห็นด้วยกับประโยคว่า “เราไม่ใช่ Netflix” แต่ในขณะเดียวกันก็สงสัยแรงเหมือนกันว่า ตัวบทความเองอาจเป็นเรื่องเล่าแบบขายฝันโรค Netflix (=การตลาด/AI) ก็ได้

เพราะสหรัฐฯ ยังมี IPv4 มากพออยู่เลยครับ ประเทศเราก็เหมือนกัน

เราเตอร์ iptime ไม่รองรับ ipv6 นี่ครับ

พอเห็นราคา IPv4 ก็ได้แต่ถอนหายใจ บอกว่าพอก็จริงหรอก...

จริง ๆ แล้วก็ใช้งานได้ดีกว่าที่คิด แต่พอเรื่องการรองรับจาก third-party ฝั่ง Mac ดีกว่า ก็เลยไม่ค่อยได้ใช้ครับ.. ฮ่าๆ

ขอบคุณสำหรับคำทักท้วงที่ดีครับ!

ดูเหมือนว่าสำนวนว่า "เปลี่ยนให้เป็นปัญหาเชิงโครงสร้าง" อาจจะค่อนข้างเป็นนามธรรมไปหน่อย
สิ่งที่ผมอยากจะสื่อในบทความคือ

Before: "การทำลาเบล = ใช้คน = ต้นทุนแปรผันตามปริมาณงาน"
After: "การทำลาเบล = ไปป์ไลน์ = หลังสร้างระบบเริ่มต้นแล้ว ต้นทุนผันแปรเหลือน้อยที่สุด"

กล่าวคือ เป็นการเปลี่ยนปัญหาต้นทุนแบบครั้งเดียวให้กลายเป็นปัญหาการสร้างระบบ
จะบอกว่า "ได้สร้างโมเดลการทำงานแบบใหม่ขึ้นมา" ก็ถูกต้องเหมือนกันครับ!
ถ้าจะให้แม่นยำกว่านั้น น่าจะพูดได้ว่าเป็นการ "แทนที่แรงงานคนด้วยซอฟต์แวร์ไปป์ไลน์" ครับ 555

สวัสดีครับ ขอบคุณที่อ่านบทความอย่างสนุกนะครับ!

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

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

ข้อที่สองคือเรื่องความเร็วในการประมวลผล
เพื่อให้สามารถประมวลผลชุดข้อมูลขนาดใหญ่ได้ภายในเวลาที่ใช้งานได้จริง การเพิ่มความเร็วลักษณะนี้จึงเป็นสิ่งจำเป็น

ข้อที่สามคือการเพิ่มความแม่นยำ
การ crop กลับช่วยเพิ่มความแม่นยำในการตัดสินของ VLM ได้ด้วย ในภาพเต็มมักมีทั้งฉากหลังที่ซับซ้อน ตัวละครหลายตัว ข้อความ ของตกแต่ง ฯลฯ รวมอยู่ด้วย ทำให้ VLM อาจสับสนว่าควรพิจารณาวัตถุใด ตัวอย่างเช่น อาจไม่ชัดเจนว่าสิ่งที่ต้องพิจารณาคือตัวละครบนโปสเตอร์ในฉากหลัง ตุ๊กตาหลัก หรืออีกตัวละครที่อยู่ข้าง ๆ ตรงกันข้าม หากใช้การ crop จะสามารถแยกเฉพาะวัตถุเป้าหมายออกมาได้อย่างชัดเจน ทำให้ VLM โฟกัสและตัดสินเฉพาะวัตถุนั้นได้

แน่นอนว่าปัญหาการตรวจไม่พบหรือการตรวจผิดของ YOLO ไม่ได้ถูกแก้ได้อย่างสมบูรณ์ อย่างไรก็ตาม เราบรรเทาปัญหานี้ด้วยการตั้งค่า confidence threshold ของ YOLO ไว้ที่ 0.5 เพื่อเพิ่ม recall จากนั้นใช้ขั้นตอน CLIP filtering และการตรวจสอบของ Verifier เพื่อคัดกรองผลตรวจผิดออก อีกทั้งเนื่องจากเราประมวลผลข้อมูลปริมาณมาก แม้จะมีบางส่วนที่ตรวจไม่พบ ก็ยังสามารถรวบรวมข้อมูลคุณภาพสูงได้ในปริมาณที่เพียงพอในเชิงสถิติ

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

สวัสดีครับคุณ winterjung ขอบคุณที่สนใจงานของผมครับ ค่า reliability ใช้ค่า confidence ที่ VLM (GPT-4o) ส่งกลับมาโดยตรงครับ อย่างที่คุณบอกไว้ ข้อจำกัดคือเกณฑ์ที่ GPT-4o ใช้คำนวณ confidence นั้นไม่ชัดเจนและไม่สามารถทำซ้ำได้ แต่ในมุมมองเชิงปฏิบัติ ผมตั้งสมมติฐานว่าค่า confidence ที่ VLM ส่งกลับมามีความแม่นยำในระดับหนึ่ง และจึงออกแบบให้ขั้นตอนตรวจสอบสุดท้าย (Verifier) ตัดสินใจว่าจะตรวจสอบหรือไม่ด้วย threshold ครับ

ผมไม่รู้มาก่อนเลยว่าโมเดล got-4o-mini มีค่าโทเค็นสำหรับอินพุตรูปภาพแพงเกินไป ขอบคุณมากที่บอกครับ ผมแก้ในโค้ดเรียบร้อยแล้วครับ ฮ่าๆ

ให้ความรู้สึกเหมือนด่าเพื่อจะได้ด่า

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

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

เหมือนจะเป็นบทความอธิบายของ Show GN: 자연어 명령을 Intent → Effect → Snapshot으로 실행하는 AI Task 데모 ที่โพสต์ไว้ใน ShowGN นะครับ

เห็นชื่อเรื่องแล้วคงไม่ค่อยอยากกดเข้าไปอ่านกันเท่าไหร่… แต่สำหรับผม นี่เป็นหนึ่งในบทความว่าด้วยความสัมพันธ์สหรัฐฯ-จีนที่อ่านสนุกที่สุดเท่าที่ได้อ่านมาในช่วงนี้

อันนี้น่าสนุกดีนะ…

แล้วการสนทนานั้นต่างจาก issue อย่างไร? issue ไม่ได้หมายถึงแค่ “บั๊ก” เท่านั้น ไม่ว่าจะเป็นบั๊ก ข้อเสนอฟีเจอร์ หรือ PR... ถ้ามีประเด็นให้ถกเถียงกัน นั่นก็คือ issue
ถ้าไม่มีคุณค่าพอให้ถกเถียง ก็ปิดมันได้

แบบนี้แหละถึงไม่ชอบโฆษณา..

ปีที่แล้วเคยติดตั้งบนโน้ตบุ๊ก Galaxy Book แต่ไม่แน่ใจว่าเป็นปัญหาความเข้ากันได้หรือเปล่า เพราะเครื่องค้างบ่อยมาก

Rich - ไลบรารี Python สำหรับจัดรูปแบบเทอร์มินัลให้สวยงาม น่าจะดีที่สุดแล้วครับ

แต่ถ้าต้องการเฉพาะฟังก์ชันตาราง ก็มีอย่าง PrettyTable หรือ Tabulate เหมือนกันครับ

ดูสะดวกดีนะ สำหรับ Python มีอะไรบ้างครับ?

ว้าว น่าทึ่งเหมือนกันที่เริ่มจากญี่ปุ่น ผมนึกว่าเรื่องแบบนี้ยุโรปหรืออเมริกาน่าจะมาก่อน