1. ถามชื่อมาสคอตของเว็บ แต่ AI กลับสร้างตัวละครใหม่
เว็บไซต์เล็กแห่งหนึ่งใช้ AI ช่วยเขียนบทความอย่างต่อเนื่อง บางบทความนำบุคลิกของคนไปเปรียบกับตัวละครจากเรื่อง Chiikawa โดยเฉพาะ Hachiware แต่เมื่อมีคนถาม AI อีกตัวเกี่ยวกับมาสคอตของเว็บไซต์ AI กลับตอบราวกับว่าชื่อนั้นเป็น “ฮาจิวาเระจอมยุ่ง” ที่อยู่ในเรื่อง Chiikawa
เดี๋ยวนะ ตัวนี้มาจากไหน?
มาสคอตของเว็บไซต์ถูกย้ายไปทำงานในเรื่องการ์ตูนของคนอื่นแบบไม่ต้องสมัครงาน ไม่ต้องสัมภาษณ์ AI ออกคำสั่งแต่งตั้งให้เรียบร้อย
สิ่งที่ยืนยันได้มีเพียง AI ตอบเช่นนั้นจริง เราไม่รู้ว่ามันอ่านบทความแล้วเข้าใจผิด เดาจากชื่อ หรือแต่งขึ้นมาเอง และไม่มีหลักฐานในเรื่องนี้ว่าตัวละครดังกล่าวมีอยู่ในเนื้อหาอย่างเป็นทางการ คำตอบที่มั่นใจไม่เท่ากับข้อเท็จจริงที่ตรวจสอบแล้ว
2. เบื้องหลังนั้น โรงงานบทความยังทำงานอย่างขยันขันแข็ง
ระบบเขียนบทความ ปรับให้อ่านง่าย สร้างเนื้อหาฉบับเต็มสิบสองภาษา ตรวจสอบ เผยแพร่ และส่งต่อให้คนอ่าน หากขั้นตอนไหนหยุด ก็หาสาเหตุ แก้ไข แล้วตรวจซ้ำ
รายงานความคืบหน้ายาวขึ้นเรื่อย ๆ จนแทบเป็นละคร
AI ตัวที่หนึ่ง: “แก้ปัญหาการเผยแพร่แล้วครับ”
AI ตัวที่สอง: “ผ่านการตรวจทุกข้อแล้วค่ะ”
AI ตัวที่สาม: “พบสาเหตุใหม่ที่ทำให้ระบบหยุดครับ”
หัวหน้า: “เพิ่มทีมซ่อมอีกทีม”
คนอ่าน: “รายงานความคืบหน้าจะยาวกว่าบทความแล้วนะ!”
เรื่องนี้ตลก แต่มีบทเรียนจริงจังว่า บันทึกการแก้ไขสำเร็จ ไม่ได้แปลว่าหน้าเว็บที่คนอ่านเห็นทำงานถูกต้องแล้ว โรงงานบทความจึงอาจต้องเป็นโรงซ่อมด้วย
3. “มีบทความ 1,900 ชิ้นแล้ว?” ต้องถามก่อนว่านับอะไร
คำว่า “จำนวนบทความ” อาจหมายถึงตัวเลขอย่างน้อยห้าประเภท
- บทความต้นฉบับ: เนื้อหาที่มีประเด็นเป็นของตัวเอง
- หน้าแต่ละภาษา: ฉบับแปลของบทความเดียวกัน
- ทำเสร็จแต่ยังไม่เผยแพร่: รอตรวจหรือรอขึ้นเว็บ
- เผยแพร่แล้ว: หน้าที่ผู้อ่านเปิดอ่านได้จริง
- เส้นทางหน้าเว็บ: อาจรวมเมนู แอป และหน้าที่ไม่ใช่บทความ
หากมีต้นฉบับ 1,000 บทความ และเผยแพร่ครบสิบสองภาษา ก็อาจมีหน้าแยกภาษาสูงสุด 12,000 หน้า ไม่ได้หมายถึงความคิดใหม่ 12,000 เรื่อง
บันทึกการทำงานครั้งหนึ่งแสดง เส้นทางหน้าเว็บ 15,862 รายการ แต่ไม่ได้หมายความว่ามีบทความญี่ปุ่นต้นฉบับ 15,862 ชิ้น คำพูดว่า “มีแล้ว 1,900 บทความ” จึงต้องมีวันที่ หน่วยนับ และสถานะเผยแพร่กำกับ ไม่อย่างนั้นตัวเลขจะโตเร็วกว่าความเข้าใจ
4. แล้วคลัง GitHub ก็มีขนาดราว 2.46GB
ข้อมูล GitHub ของกรณีศึกษาที่ไม่เปิดเผยตัวตนระบุขนาด 2,400,972KiB หรือประมาณ 2.29GiB และ 2.46GB เมื่อใช้หน่วยฐานสิบ ณ วันที่ 8 ตุลาคม 2026
“บทความเป็นแค่ตัวหนังสือไม่ใช่เหรอ ทำไมใหญ่ขนาดนี้?”
เพราะคลังอาจมีโปรแกรม ข้อมูลแปล รายชื่อหน้าที่เผยแพร่ ผลการตรวจ รูป เสียง และประวัติการแก้ไขด้วย แต่ ตัวเลขรวมเพียงตัวเดียวไม่บอกว่าอะไรใช้พื้นที่มากที่สุด ต้องตรวจแยกอีกครั้ง อีกทั้งตัวเลข GitHub ไม่จำเป็นต้องเท่ากับขนาดโฟลเดอร์ในคอมพิวเตอร์
บทความ: “ฉันมีแค่ไม่กี่ KB”
ประวัติ: “ฉันเก็บฉบับเก่าไว้หมด”
คำแปล: “ฉันพาเพื่อนมาอีกสิบเอ็ดคน”
คลัง: “ทำไมไม่มีใครบอกก่อน!”
5. คำตอบคือ GitHub Free ไม่ได้คิดเงินทันทีเมื่อเกิน 5GB
สำหรับคลัง Git ปกติ GitHub ไม่ได้ประกาศโควตาฟรีรวมเป็น GB แบบตัวเลขเดียวที่เกินแล้วคิดเงินอัตโนมัติ 5GB เป็นขนาดที่แนะนำอย่างยิ่ง ไม่ใช่จุดเริ่มคิดเงิน
เอกสารทางการบอกว่าคลังควรมีขนาด ต่ำกว่า 1GB จะดีที่สุด และแนะนำอย่างยิ่งให้ต่ำกว่า 5GB อีกเอกสารแนะนำว่าเนื้อหา Git แบบบีบอัดที่เก็บบนดิสก์ ไม่ควรเกิน 10GB แต่นั่นไม่ใช่การรับประกันว่าได้พื้นที่ฟรี 10GB
หากคลังใหญ่หรือมีการทำงานหนักจนกระทบบริการ GitHub อาจขอให้ปรับปรุง ดังนั้นทั้ง “เกิน 5GB ต้องจ่ายเงิน” และ “ฟรีแปลว่าเก็บได้ไม่จำกัด” ล้วนไม่ถูกต้อง
6. ข้อจำกัดจริงแบ่งอยู่คนละส่วน
| สิ่งที่นับ | ข้อจำกัดหรือสิทธิใช้ฟรี |
|---|---|
| คลัง Git ปกติทั้งหมด | ไม่มีเพดานคิดเงินรวมแบบตัวเลขเดียว; ดีที่สุดต่ำกว่า 1GB และแนะนำอย่างยิ่งให้ต่ำกว่า 5GB |
| ข้อมูล Git บนดิสก์ | ขนาดสูงสุดที่แนะนำ 10GB ไม่ใช่จุดเริ่มชำระเงิน |
| ไฟล์ปกติหนึ่งไฟล์ | เกิน 50MiB มีคำเตือน เกิน 100MiB ถูกปฏิเสธ; อัปโหลดผ่านเว็บได้สูงสุด 25MiB |
| ส่งการแก้ไขหนึ่งครั้ง | จำกัด 2GiB |
| Git LFS สำหรับไฟล์ใหญ่ | แผนฟรีมีพื้นที่ 10GiB และปริมาณรับส่ง 10GiB แยกจาก Git ปกติ |
| ไฟล์ผลลัพธ์ของ GitHub Actions | แผนฟรีมีพื้นที่ 500MB และโดยทั่วไปมีเวลาใช้งาน 2,000 นาทีต่อเดือน |
ตัวเลขเหล่านี้ไม่ใช่โควตาก้อนเดียวกัน การใช้ Git LFS หรือ Actions เกินสิทธิขึ้นอยู่กับกติกาคิดเงินและการตั้งงบของแต่ละบริการ คลัง Git ปกติขนาด 2.46GB ไม่ได้แปลว่าใช้พื้นที่ผลลัพธ์ Actions เกิน 500MB และการที่ Git ต่ำกว่า 5GB ก็ไม่ได้ยืนยันว่าโควตาอื่นยังเหลือ
7. ทำไมพื้นที่โตเร็วกว่าจำนวนบทความได้
Git เก็บทั้งไฟล์ปัจจุบันและประวัติการเปลี่ยนแปลง หากระบบเขียนรายชื่อขนาดใหญ่ใหม่ทุกชั่วโมง แม้ฉบับล่าสุดจะเห็นไฟล์เดียว แต่ฉบับเก่าอาจยังอยู่ในประวัติ เมื่อมีการแก้บทความ สร้างคำแปลใหม่ เพิ่มผลตรวจ และบันทึกผลลัพธ์ซ้ำ พื้นที่จึงไม่ได้โตตามจำนวนบทความแบบตรงตัว
อย่างไรก็ตาม Git บีบอัดข้อมูลและจัดเก็บฉบับที่คล้ายกันได้อย่างมีประสิทธิภาพ แก้ไฟล์หนึ่งครั้งไม่ได้แปลว่าพื้นที่เพิ่มเป็นสองเท่าเสมอไป ต้องตรวจว่าส่วนใดใหญ่จริง
ต้นฉบับกับโปรแกรมที่ต้องติดตามการเปลี่ยนแปลงเหมาะกับ Git ส่วนผลลัพธ์ที่สร้างซ้ำบ่อยและสื่อขนาดใหญ่อาจเหมาะกับที่เก็บภายนอกมากกว่า
8. ระบบอาจติดขัดก่อนพื้นที่จะเต็ม
หาก AI หลายตัวแก้ไฟล์ส่วนกลางพร้อมกัน การเขียนข้อมูลอาจชนกันได้ งานซ่อมหนึ่งเสร็จแล้ว แต่อีกงานยังใช้รายชื่อเผยแพร่เก่า บทความพร้อมแล้ว แต่หน้าเว็บจริงยังไม่เปลี่ยน
อย่ารีบสรุปว่า “GitHub เต็ม” เพราะขนาดไฟล์ ความถี่ในการแก้ การทำงานพร้อมกัน และความสำเร็จของการเผยแพร่เป็นคนละปัญหา
ให้ตรวจสี่ขั้น: ต้นฉบับล่าสุดมีอยู่หรือไม่ ผ่านการตรวจหรือไม่ ส่งขึ้นระบบจริงหรือไม่ และหน้าเว็บสาธารณะแสดงข้อความใหม่ตรงฉบับหรือไม่ ค่อยฉลองหลังขั้นที่สี่
9. สี่วิธีดูแลการใช้งานฟรีระยะยาว
วัดก่อนลบ ตรวจไฟล์ใหญ่และประวัติ ไม่ใช่ดูแค่ตัวเลขรวม GitHub ยังแนะนำเครื่องมืออย่าง git-sizer สำหรับช่วยวิเคราะห์
แยกผลลัพธ์ชั่วคราว รายชื่อที่สร้างซ้ำ บันทึกชั่วคราว รูปภาพ และไฟล์เสียง ไม่จำเป็นต้องเก็บทั้งหมดไว้ในประวัติ Git ตลอดไป
ลดการเขียนซ้ำโดยไม่จำเป็น การแก้เล็กน้อยที่ไม่เกี่ยวข้องไม่ควรทำให้สร้างรายชื่อขนาดใหญ่ใหม่ทั้งหมด หากข้อมูลชนกันให้กลับไปอ่านสถานะล่าสุดก่อน
ระวังการเปลี่ยนประวัติ ลบไฟล์จากฉบับล่าสุดแล้ว ไฟล์อาจยังอยู่ในฉบับเก่า การเขียนประวัติใหม่อาจทำให้ผู้ร่วมงานและลิงก์อ้างอิงเสียหาย ต้องสำรองและประเมินผลก่อน
10. สิ่งสำคัญกว่าจำนวนบทความคือคุณค่าที่คนอ่านได้รับ
มีต้นฉบับหลายพันชิ้นและหน้าแปลหลายหมื่นหน้า ก็ไม่ได้รับประกันว่าจะมีคนอ่านเพิ่ม หน้าเว็บถูกค้นพบได้ไหม ข้อมูลถูกต้องไหม แต่ละภาษาเป็นธรรมชาติไหม หรือเพียงแค่เขียนเรื่องเดิมซ้ำ
คำแนะนำทางการของ Google ให้ความสำคัญกับเนื้อหาที่มีคุณค่าและเป็นต้นฉบับสำหรับคนอ่าน และมองว่าการสร้างหน้าคุณค่าต่ำจำนวนมากเพื่อบิดเบือนอันดับค้นหาเป็นปัญหา ไม่ใช่ว่าใช้ AI แล้วผิดทันที แต่การผลิตจำนวนมากโดยไม่ช่วยคนอ่านต่างหากที่เสี่ยง
ส่วน “ฮาจิวาเระจอมยุ่ง” ที่ AI ตั้งขึ้นเองนั้นเป็นมุกได้ แต่ยังใช้เป็นข้อมูลทางการไม่ได้
โรงงาน: “ฉันจะเพิ่มบทความ”
GitHub: “ฉันจะเพิ่มประวัติ”
ฝ่ายตรวจ: “ฉันจะลดข้อผิดพลาด”
AI ค้นหา: “งั้นฉันเพิ่มตัวละคร!”
ทุกคน: “อันนั้นไม่ต้องเพิ่ม!”
สรุป: 5GB ไม่ใช่กำแพงเก็บเงินของ GitHub Free พื้นที่ การเผยแพร่ คุณภาพ และความเข้าใจผิดของ AI ต้องตรวจแยกกัน ความสำเร็จจริงคือเนื้อหาที่ถูกต้องและไปถึงคนอ่าน ไม่ใช่จำนวนไฟล์ที่บันทึกไว้
