5 สิ่งที่ผมได้เรียนรู้ในสัปดาห์นี้
ผมทำเว็บไซต์สารบัญ AI และระบบอัตโนมัติสำหรับ YouTube ในสัปดาห์นี้ผมพบกับปัญหาติดขัดหลายอย่าง และนี่คือ 5 บทเรียนที่ได้จากการปรับปรุงครับ
- ควบคุมค่าใช้จ่าย CI ของคุณ
สคริปต์โพสต์ Bluesky ของผมทำให้เสียเวลาใช้งาน GitHub Actions ไปโดยเปล่าประโยชน์ ทุกครั้งที่มีการโพสต์ มันจะไปกระตุ้นกระบวนการ Build ขนาดใหญ่ในเว็บไซต์ทั้งสามแห่ง ผมต้องเสียเวลาไปถึง 120 นาทีต่อสัปดาห์เพียงเพื่ออัปเดตสถานะง่ายๆ
ผมได้ทำการเปลี่ยนแปลงสองอย่าง:
- เปลี่ยนจากการตั้งค่า Trigger วันละ 3 ครั้ง เป็นวันละ 1 ครั้งแทน
- เพิ่ม Path filter เพื่อไม่ให้การแก้ไขข้อความไปกระตุ้นการ Rebuild เว็บไซต์ทั้งหมด
อย่าปล่อยให้งานเล็กๆ น้อยๆ มาเผาผลาญโควตา Automation ของคุณ รีบแก้ไขนิสัยเหล่านี้ก่อนที่โปรเจกต์ของคุณจะขยายใหญ่ขึ้น
- เพิ่มการควบคุมคุณภาพ (Quality Control) เข้าไปในระบบอัตโนมัติ
ผมพบโพสต์ 17 รายการในคิวที่ฟังดูเหมือนบอท พวกมันใช้คำอย่างเช่น "auto-generated" ซึ่งให้ความรู้สึกที่ไม่เข้ากับแบรนด์ส่วนตัวของผมเลย
ผมจึงเพิ่มขั้นตอน QC เข้าไปใน Pipeline โดยขั้นตอนนี้จะตรวจสอบโพสต์ในเรื่อง:
- ลิงก์เสีย
- ข่าวที่ล้าสมัย
- น้ำเสียงที่ดูเหมือนหุ่นยนต์หรือดูเป็นสแปม
หากโพสต์ใดไม่ผ่านเกณฑ์ มันจะค้างอยู่ในคิวเพื่อรอการตรวจสอบด้วยตัวเอง ตอนนี้ผมโพสต์น้อยลง แต่คุณภาพสูงขึ้นครับ
- ความเรียบง่ายอาจดีกว่าการปรับแต่งให้เหมาะสมที่สุด (Optimization)
ผมลองเอาการทำ AI model routing ออก เดิมทีผมจะส่งงานง่ายๆ ไปยังโมเดลราคาถูก และส่งงานยากๆ ไปยังโมเดลราคาแพง
หลังจากเอา Router ออก ผมพบว่า:
- Latency เท่าเดิม
- ค่าใช้จ่ายเพิ่มขึ้น 8%
- โค้ดเรียบง่ายขึ้นมาก
ค่าใช้จ่ายที่เพิ่มขึ้น 8% นั้นคุ้มค่าเมื่อเทียบกับการไม่ต้องมานั่งไล่แก้บั๊ก (Debug) ข้อผิดพลาดในการ Routing ในสเกลขนาดเล็ก ความซับซ้อนมีต้นทุนที่สูงกว่าส่วนต่างที่ประหยัดได้จาก API
- ระวังเรื่องลิขสิทธิ์ (Licensing)
ผมได้เพิ่มสไลด์รูปภาพในเครื่องมือ YouTube โดยใช้ Openverse ซึ่งผลลัพธ์เริ่มต้นจะมีลิขสิทธิ์แบบ Creative Commons หลายประเภท
หากคุณไม่กรองเฉพาะลิขสิทธิ์แบบ CC0 หรือ PDM คุณอาจเผลอใช้รูปภาพที่ต้องมีการให้เครดิตบนหน้าจอ ซึ่งสำหรับช่องที่สร้างรายได้แล้ว นี่ถือเป็นความเสี่ยงทางกฎหมาย ดังนั้นควรกรองคำขอ API ตั้งแต่ต้นทาง (Upstream) เพื่อหลีกเลี่ยงปัญหาลิขสิทธิ์โดยไม่ตั้งใจ
- เครื่องมือ Monitoring ขึ้นอยู่กับความง่ายในการใช้งาน
ผมได้ทดสอบ Netdata, SigNoz และ OpenObserve
- Netdata ใช้งานง่ายและพร้อมใช้งานได้ทันที
- SigNoz ต้องมีการทำ Instrumentation ในโค้ดของคุณด้วย OpenTelemetry
- OpenObserve ดีมากสำหรับเรื่อง Logs แต่มีช่วงการเรียนรู้ที่ค่อนข้างสูง (Steep learning curve)
สำหรับโครงสร้างพื้นฐานปัจจุบันของผม เครื่องมือเหล่านี้ดูจะเกินความจำเป็นไปหน่อย ผมจึงเลือกใช้การเชื่อมต่อระบบแจ้งเตือนข้อผิดพลาด (Error alerting) แบบง่ายๆ แทน จงเลือกเครื่องมือที่เหมาะกับโครงสร้างพื้นฐานปัจจุบันของคุณ ไม่ใช่เครื่องมือที่ซับซ้อนที่สุด
ที่มา: https://dev.to/morinaga/5-things-i-noticed-this-week-ci-cost-bluesky-qc-and-cc0-licensing-49ig