เพิ่มประสิทธิภาพ API แนะนำคำค้นหาอัตโนมัติ - ตอบกลับภายใน 100ms จากข้อมูล 110,000 รายการ

แนะนำโปรเจกต์

• NewCodes เป็นบริการคัดสรรบล็อกเทคนิคขององค์กร
• สถาปัตยกรรม Spring Boot + PostgreSQL
• พัฒนาฟังก์ชันแนะนำคำค้นหาอัตโนมัติ: คำแนะนำตาม Term, การค้นหาแบบแยกจาโม, การค้นหาแบบพยัญชนะต้น, การแนะนำหน้าองค์กร

พบปัญหาด้านประสิทธิภาพ

• มีข้อมูลสะสมในตาราง Term จำนวน 110,000 รายการ
• เวลาในการตอบสนองของ API เพิ่มขึ้นเกิน 1000ms
• เป้าหมาย: ตอบสนองภายใน 100ms

ความพยายามครั้งที่ 1: เพิ่มดัชนี (1000ms → 700ms)

• สร้างดัชนีเพื่อเพิ่มประสิทธิภาพการค้นหา LIKE แบบ prefix โดยใช้ varchar_pattern_ops
• สร้างดัชนีด้วยตัวเลือก CONCURRENTLY โดยไม่ต้องหยุดให้บริการ
• ใช้ดัชนีกับคอลัมน์ term, decomposed_term, chosung แยกกัน

ความพยายามครั้งที่ 2: ดัชนีสำหรับฟังก์ชัน LOWER (700ms → 110ms)

• พบปัญหา full scan จากการใช้ฟังก์ชัน LOWER()
• สร้างดัชนีแบบอิงฟังก์ชัน (Functional Index)
• ปรับโครงสร้างดัชนีใหม่เป็นรูปแบบ LOWER(ชื่อคอลัมน์) varchar_pattern_ops

ความพยายามครั้งที่ 3: JOIN → EXISTS (110ms → 100ms)

• INNER JOIN ระหว่าง Corporation กับ Article เป็นคอขวดด้านประสิทธิภาพ
• เปลี่ยนเป็นซับคิวรี EXISTS เพื่อลดขอบเขตการสแกน
• ปรับให้ตรวจสอบเพียง "มีข้อมูลอยู่หรือไม่" เท่านั้น

ความพยายามครั้งที่ 4: การทำ Denormalization และ Covering Index (100ms → 90ms)

• เพิ่มคอลัมน์ total_frequency เพื่อตัดการคำนวณแบบ aggregate ออก
• แทนที่การทำงาน GROUP BY และ SUM ด้วยค่าที่คำนวณไว้ล่วงหน้า
• ลดจำนวนครั้งของ I/O ด้วย covering index
• รวม term และ total_frequency ไว้ในดัชนีด้วย INCLUDE clause

ความพยายามครั้งที่ 5: JDBC Template (90ms → 80ms)

• ตัดโอเวอร์เฮดของ JPA/Hibernate
• รันคิวรีโดยตรงด้วย JDBC Template
• สำหรับการอ่านข้อมูลแบบง่าย การข้าม ORM layer ให้ผลดี

แก้ปัญหา Nginx Rate Limiting

• การตั้งค่าเริ่มต้น: จำกัด 2 ครั้งต่อ 1 วินาที, burst 10
• เกิดการล้มเหลวของคำขอจากการทำ debounce 100ms
• ปรับปรุง: อนุญาต 10 ครั้งต่อ 1 วินาที, เปลี่ยน burst เป็น 20
• เปลี่ยน status code จาก 444 → 429

ลดขนาดข้อมูลตอบกลับ

• ลบชื่อฟิลด์ JSON และเปลี่ยนเป็นการตอบกลับแบบอาร์เรย์
• แยกประเภทด้วยตัวเลข (0: Corporation, 1: Theme, 2: Term)
• ลดเวลาในการส่งผ่านเครือข่าย

การประมวลผลแบบขนานด้วย CompletableFuture

• รันการค้นหา Corporation, Theme, Term พร้อมกันอย่างอิสระ
• ใช้เวลาเพียงเท่ากับเวลาตอบสนองสูงสุด เมื่อเทียบกับการรันแบบลำดับ
• เพิ่ม ExecutorService และการจัดการข้อยกเว้น

ผลลัพธ์สุดท้าย

• จากเดิม 1000ms → เหลือ 80ms (เซิร์ฟเวอร์พัฒนา), 40ms (เซิร์ฟเวอร์โปรดักชัน)
• ประสิทธิภาพดีขึ้นมากกว่า 90% โดยประมาณ

ประเด็นการเรียนรู้สำคัญ

• ความสำคัญของการนิยามปัญหาและกำหนดทิศทาง
• สมดุลระหว่างการใช้ AI กับการตรวจทานโดยนักพัฒนา
• ความจำเป็นของการออกแบบจากมุมมองสถาปัตยกรรมโดยรวม
• การเลือกชนิดของดัชนี: ดัชนีเดี่ยว/ดัชนีผสม/covering index
• ต้องระวังการทำให้ดัชนีใช้งานไม่ได้เมื่อมีการใช้ฟังก์ชัน
• ความเข้าใจการทำงานภายในของ JPA
• การวิเคราะห์แผนการทำงานของคิวรีด้วย EXPLAIN

แนวทางปรับปรุงในอนาคต

• ใช้โครงสร้างข้อมูล Trie
• แคชคำที่ถูกค้นหาบ่อย
• ใช้ CDN (ในกรณีให้บริการระดับโลก)

[moderator]

แอดมินขอแจ้งให้ทราบครับ
ขณะนี้การถกเถียงในคอมเมนต์มีแนวโน้มร้อนแรงขึ้น เนื่องจากประเด็นได้พัวพันไปถึงส่วนที่ไม่เกี่ยวกับเนื้อหาทางเทคนิคของโพสต์โดยตรง

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

กรุณาตรวจสอบแนวทางการเขียนคอมเมนต์ในวิธีใช้งานเว็บไซต์อีกครั้ง

• โปรดพูดคุยกันอย่างสุภาพและนุ่มนวล
• โปรดอย่าพุ่งเป้าโจมตีผู้เขียนโพสต์

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

[kunggom]

ครับ เข้าใจแล้ว

[kunggom]

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

• เรื่องราวของการทดลองและปรับปรุงซ้ำๆ ก่อนเปิดตัวบริการใหม่

[kuthia]

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

[kunggom]

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

[nemorize]

เห็นด้วยครับ
ยิ่งไปกว่านั้น พอเห็นประโยคว่า "ตั้งแต่เดือนพฤษภาคม 2025 ผมเริ่มทำมันคนเดียวอยู่ในกองทัพ!" ก็ยิ่งชัดว่าไม่ใช่บล็อกของบริษัทด้วยซ้ำ...

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

GeekNews เป็นพื้นที่ที่มีบรรยากาศว่าไม่ควรแชร์อะไรแบบนี้เหรอครับ?
ถ้าแชร์ประสบการณ์จากการได้ลองทำงานที่ยังไงก็ต้องทำอยู่แล้ว แบบนี้ถือว่าไม่ได้เหรอ?
ประสบการณ์ที่ไม่มีจุดแตกต่าง แชร์ไม่ได้เหรอครับ?
ประสบการณ์ระดับงานลองทำ แชร์ไม่ได้เหรอครับ?

[ifmkl]

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

[kunggom]

ดูเหมือนว่าสาเหตุใหญ่สุดคงเป็นเพราะถูกปักธงว่าเป็นการใช้งานในทางที่ผิดจนโดนมองไม่ดีไปแล้ว
ตัวเนื้อหาของบล็อกเองก็เป็นส่วนต่อเนื่องของการโปรโมตบริการของผู้เขียน ซึ่งบล็อกเทคนิคของบริษัทอื่นก็ไม่ได้ต่างกัน ดังนั้นผมคิดว่าการกีดกันเพียงเพราะเหตุผลนั้นอย่างเดียวเป็นเกณฑ์ที่ค่อนข้างอ่อนไหวทีเดียว
และในประเด็นที่ว่าบทความนี้แสดงให้เห็นถึงความกังวลและความพยายามของผู้เขียนเองหรือไม่ เมื่อสมมติฐานที่ว่าการใส่อินเด็กซ์จะช่วยให้ประสิทธิภาพดีขึ้นถูกหักล้างแล้ว ก็ยังไปตรวจดู execution plan และคำนึงถึง business logic เพื่อค่อย ๆ ปรับปรุงทั้ง query และ schema ซ้ำไปมา จนบรรลุประสิทธิภาพตามเป้าหมายได้ ผมคิดว่านั่นก็นับเป็นความกังวลและความพยายามที่มากพอแล้ว

[ifmkl]

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

[newcodes7]

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

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

[click]

สงสัยว่าเคยพิจารณาลองใช้ GIN index แทน lower() index หรือเปล่าครับ ไหน ๆ ก็ใช้ raw sql ผ่าน jdbctemplate อยู่แล้ว แบบนี้ลอง FTS ไปเลยเป็นอย่างไรบ้างครับ?

วิธีแบบ asynchronous ที่ใช้ CompletableFuture.supplyAsync() เอง ถ้าไม่ได้ระบุ ExecutorService แยกต่างหาก ก็จะใช้ commonpool ของ forkjoinpool อยู่ดี
ถ้าจำนวนผู้ใช้พร้อมกันมากขึ้นจน commonpool ที่เอามาใช้แทน request thread เต็ม (ประมาณ cpu core - 1) ก็อาจรับไม่ไหวได้ครับ
ส่วนนี้น่าจะแก้ได้ค่อนข้างเรียบร้อยด้วยการเปลี่ยนไปใช้วิธีแบบ reactive หรืออัปเกรดเวอร์ชัน JVM แล้วนำ virtual thread มาใช้ครับ

[newcodes7]

สวัสดีครับ! ก่อนอื่นต้องขอขอบคุณมากจริง ๆ ที่ช่วยคอมเมนต์ให้ฟีดแบ็กมา

ผมพิจารณาแล้วว่า GIN index ไม่จำเป็นในกรณีนี้ครับ! ตอนนี้ใน API แนะนำคำค้นหาแบบ autocomplete เราต้องการเพียงตัว term เองเท่านั้น ไม่ได้จำเป็นต้องรู้ว่า term นั้นอยู่ใน article ใดบ้าง
ในทางกลับกัน สำหรับ API ค้นหา เรากำลังใช้อินเด็กซ์ที่คล้ายกับ GIN index อยู่ โดยใช้ BM25 index ผ่าน paradeDB ซึ่งเป็น extension ของ Postgres
แม้ในโพสต์จะไม่ได้อธิบายไว้ละเอียด แต่ตอนนี้เราได้กำหนด ExecutorService แยกต่างหากเพื่อใช้งานอยู่แล้ว อย่างไรก็ตามอย่างที่คุณแนะนำ เราจะลองพิจารณาแนวทางแบบ reactive หรือ virtual thread ในอนาคตด้วยครับ!!

[newcodes7]

ขออภัยเกี่ยวกับโพสต์นี้และโพสต์ก่อนหน้าด้วยครับ
การกด upvote ด้วยบัญชีที่ไม่ได้ใช้งาน 2 บัญชีเป็นความผิดพลาดและการกระทำที่โง่เขลาของผมเอง

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

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

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

ผมยอมรับในความผิดของตัวเอง และขอชี้แจงผ่านข้อความนี้
จากนี้ไปผมจะใช้งานอย่างเป็นผู้ใหญ่มากขึ้นครับ

[roxie]

:+1:

[winterjung]

อ่านได้เพลินมากครับ ตอนแรกนึกว่าเป็นบทความแนวแค่ใส่ดัชนีธรรมดา ๆ หรือเปล่า? แต่ไม่ได้หยุดแค่นั้น ยังลองหลายวิธีแล้วนำมาแชร์ด้วย ตรงนี้ดีมากครับ ต่อไปอย่างที่บอกไว้ ลองใช้ trie ก็น่าจะดี หรืออาจปรับปรุงต่อด้วยการให้น้ำหนักกับ term ที่กำลังเป็นเทรนด์จากการถูกค้นหาล่าสุดบ่อย ๆ มากขึ้นก็ได้ครับ!
มีอยู่จุดหนึ่งที่ผมสงสัยคือ เห็นว่าคุณ query ทั้ง term และ decomposed term ด้วยเงื่อนไข or แต่ในเมื่อ decomposed term ครอบคลุมมากกว่า ก็เลยคิดว่า query แค่ฟิลด์นี้อย่างเดียวก็น่าจะพอหรือเปล่าครับ เช่น ต่อให้ query เป็น “neng” ก็จะแยกเป็น “nieong” เลยคิดว่าน่าจะค้นหา “Naver” ได้อยู่แล้ว ส่วนกรณีที่ term จริงเป็น “neng” เอง ก็น่าจะค้นหาเจอเหมือนกันครับ

[newcodes7]

อย่างที่คุณบอกไว้ แค่ค้นหาด้วย decomposed term ก็เพียงพอแล้วครับ/ค่ะ ตอนนี้เมื่อเป็นแบบนี้ term ก็เป็นเงื่อนไขที่ไม่จำเป็น แต่ดูเหมือนว่าผม/ดิฉันจะไม่ได้คำนึงถึงจุดนี้ ขอบคุณมากครับ/ค่ะ เลยได้แก้ไขแล้ว!

[skageektp]

รู้สึกอยู่นิด ๆ เหมือนกันว่าเนื้อหานี้อาจจะไม่ค่อยใช่สิ่งที่คนที่เข้ามาดู GeekNews อยากอ่านกันสักเท่าไร~

[kunggom]

ผมไม่เข้าใจจริง ๆ ว่ามันยิ่งใหญ่อะไรนัก
จำนวนเรคอร์ดก็ไม่ใช่ระดับ 1 ล้านหรือ 10 ล้านรายการเสียหน่อย แต่เป็นขนาดที่เกิน 1 แสนมานิดหน่อย ซึ่งก็ระบุไว้ชัดเจนตั้งแต่ในชื่อเรื่องแล้ว ดังนั้นการคาดหวังว่าจะมีการปรับแต่งอะไรแบบใหญ่โตแทนที่จะยึดพื้นฐานให้แน่น มันเองก็ดูแปลก ๆ ไม่ใช่หรือครับ? ผมเลยสงสัยว่าตกลงคาดหวังอะไรที่ยิ่งใหญ่นักกันแน่
ผมก็ไม่ค่อยเข้าใจว่าการโพสต์บทความที่เล่าเป็นขั้นเป็นตอนในการค่อย ๆ ปรับให้ถูกต้องทีละอย่างบนพื้นฐานที่มั่นคง ในสถานะที่ DB ยังไม่ได้ถูกปรับแต่งอย่างเหมาะสม ทำไมถึงต้องถูกมองว่าเป็นการเรียกกระแสขนาดนั้น
ในความเห็นของผม บรรยากาศแบบ排他ที่ทำนองว่า 'ถ้าไม่ใช่อะไรที่ดีที่สุด ก็ไม่ควรเอามาลงที่นี่ตั้งแต่แรก' นั้นเป็นสิ่งที่ไม่ดี

[crawler]

> การคาดหวังว่าจะมีการปรับแต่งประสิทธิภาพอะไรใหญ่โต แทนที่จะยึดพื้นฐานให้แน่นตั้งแต่ตรงนั้น มันก็ดูแปลก ๆ อยู่ไม่ใช่หรือครับ?

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

สิ่งที่มักถูกแนะนำให้เป็นพอร์ตโฟลิโอชิ้นแรกสำหรับนักพัฒนามือใหม่ก็คือการทำเว็บบอร์ดครับ

ถ้ามองแบบง่าย ๆ มันก็ไม่ซับซ้อน
โพสต์ข้อความขึ้นไป แล้วให้แสดงในรายการได้ก็จบแล้ว ถ้าทำแบบง่ายมาก ๆ อาจไม่ต้องมีฐานข้อมูลฝั่งแบ็กเอนด์ด้วยซ้ำ

แต่คนเราจะมองเห็นได้เท่าที่ตัวเองรู้ครับ
ถ้าจะทำเว็บบอร์ดแบบจริงจัง ก็เริ่มตั้งแต่ DB ไปจนถึงฟีเจอร์คอมเมนต์ ระบบล็อกอิน แล้วต่อยอดล็อกอินเป็น OAuth หรือ JWT แม้แต่ฟังก์ชันเขียนโพสต์ธรรมดาก็ยังมีการแนบรูปและวิดีโอ รองรับการจัดรูปแบบข้อความ รวมถึงเรื่องความปลอดภัยตั้งแต่ XSS เป็นต้น

ต่อให้เป็นข้อความเดียวกัน ภาพที่แต่ละคนวาดขึ้นในหัวก็อาจต่างกันมากตามพื้นฐานความรู้ของผู้อ่าน

ผมเข้าใจครับว่าคุณ kunggom จินตนาการถึงระบบ autocomplete แบบไหนจากชื่อเรื่อง

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

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

[kunggom]

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

[crawler]

ผมไม่ได้คิดว่า kunggom เป็นนักพัฒนาที่ขาดความรู้พื้นฐานถึงขั้นไม่สามารถเข้าใจอุปมาเรื่องบอร์ดที่ผมพูดถึงได้

ตอนนี้ความเห็นที่ต่างกันน่าจะมาจากการรับรู้ต่อผู้ใช้ที่ Abusing กันตั้งแต่ต้น ดังนั้นผมจะพูดเป็นครั้งสุดท้ายครับ

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

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

แล้วตอนนี้ผมกำลังพูดถึงแค่หัวข้อเท่านั้น
> ตามบทความต้นฉบับ โปรเจ็กต์นี้ ~

ผมกำลังพูดถึงภาพที่จินตนาการจากการเห็นหัวข้อ ซึ่งส่วนนี้ไม่จำเป็นต่อบทสนทนาของเราในตอนนี้ครับ

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

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

> และถ้าคุณคิดจริง ๆ ว่าการที่คนที่ถูกจับได้ว่า abuse กลับมาเขียนโพสต์อีกในวันถัดไปเป็นปัญหา

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

[kunggom]

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

ผมเข้าใจจุดยืนที่วิพากษ์วิจารณ์การ abuse นะครับ แต่ประโยคสุดท้ายเหมือนค่อย ๆ เปลี่ยนประเด็นจากความไม่ชำนาญทางเทคนิคไปเป็นเรื่องการละเมิดกฎชุมชนอย่างแนบเนียน และดูเหมือนเป็นความพยายามแบบไทเก็กที่ค่อนข้างฝืน ๆ ในการบอกว่า "จะใช้ตรรกะและข้ออ้างของคุณมาหักล้างตัวคุณเอง" เลยทำให้ผมค่อนข้างผิดหวัง
ถ้าคุณวิจารณ์แค่เรื่อง abuse ตั้งแต่แรกเสียเลย น่าจะมีน้ำหนักกว่าเสียอีก ถ้าเป็นอย่างนั้นจริง ต่อให้บทความข้างต้นมีเนื้อหาอย่างที่คุณบอกว่าคาดหวังไว้แต่แรกจริง ๆ เช่นการปรับแต่ง vector embedding บน DBMS สมัยใหม่ หรือแม้จะใช้ "ชื่อเรื่องที่ถ่อมตัว" ก็ตาม ก็คงยังมีปฏิกิริยาในเชิงเป็นปฏิปักษ์ต่อประวัติการ abuse ช่วงหลังของผู้เขียนอยู่ดี และในส่วนนั้นผมก็ไม่มีข้อโต้แย้งอะไรเลย เพราะมันแทบไม่เกี่ยวกับเนื้อหาทางเทคนิคอยู่แล้ว

สิ่งที่ผมคัดค้านคือ ทำไมรูปแบบนั้นถึงแสดงออกมาในลักษณะของการชี้ว่ามันเป็น "ความไม่ชำนาญทางเทคนิค" หากการ abuse เป็นพฤติกรรมที่ยอมรับไม่ได้ ก็แน่นอนว่าควรถูกตำหนิโดยไม่เกี่ยวกับเนื้อหาอยู่แล้ว ถ้าอย่างนั้นมีเหตุผลอะไรที่ต้องใส่คำวิจารณ์เกี่ยวกับเนื้อหาลงไปด้วยล่ะ? แต่คอมเมนต์ที่นี่กลับแทบทั้งหมดมีนัยว่าเนื้อหานั้นอ่อนทางเทคนิค ทั้งที่คุณ crawler เองก็เปรียบเทียบกับผมว่าเป็นเหมือน "การทำเว็บบอร์ดของนักพัฒนามือใหม่" และยังบอกว่า "จะเห็นได้เท่าที่รู้" อีกด้วย แบบนี้มันก็น่าตั้งข้อสงสัยไม่ใช่หรือว่าเรื่อง abuse นั้นอาจเป็นเพียงประเด็นรองที่ถูกหยิบมาต่อท้ายทีหลัง

ถ้าตามเนื้อหาคอมเมนต์นั้น ต่อให้บทความต้นฉบับเป็นเนื้อหาประเภทที่คุณ crawler คาดหวังจริง คุณก็คงวิจารณ์เพราะการ abuse อยู่ดี ไม่อย่างนั้น หรือว่าถึงจะมีการ abuse แต่ถ้าโดยส่วนตัวคุณรู้สึกว่าชอบเนื้อหาของบทความ ก็ไม่จำเป็นต้องใช้เสรีภาพในการพูดอย่าง "เข้มงวด" งั้นหรือ?
ดังนั้นผมขอถามอีกครั้ง ถ้าคุณวิจารณ์ผู้เขียนต้นฉบับเพราะการ abuse จริง ๆ แล้ว ทำไมคอมเมนต์ของคุณถึงเน้นวิจารณ์เนื้อหาเป็นหลัก แทนที่จะวิจารณ์เรื่อง abuse?

[kunggom]

มีหลักฐานเกี่ยวกับส่วนที่ว่า "ขัดขวางเสรีภาพในการพูดของผู้อื่น" ไหมครับ? ตรงนี้ผมไม่ค่อยเข้าใจเท่าไร เพราะไม่ใช่ว่าผมมีอำนาจดูแลพื้นที่นี้จนสามารถปิดกั้นไม่ให้คนอื่นเขียนโพสต์หรือคอมเมนต์ได้เสียหน่อย และในความเป็นจริงคุณก็ยังเขียนคอมเมนต์ยาว ๆ แบบนี้ได้อยู่ไม่ใช่หรือครับ
ถ้าการแค่เขียนคอมเมนต์คัดค้านความเห็นของคนอื่นถือเป็นการปิดกั้นเสรีภาพในการพูดของผู้อื่น งั้นก็ต้องถือว่าคุณ crawler กำลังละเมิดเสรีภาพในการพูดของผมอยู่ตอนนี้ด้วยไม่ใช่หรือครับ? ถ้าไม่ใช่ แบบนั้นในเชิงตรรกะก็ไม่ใช่มาตรฐานสองชั้นหรอกหรือครับ?

และอย่างที่คุณ crawler ก็ยอมรับเอง สุดท้ายแล้วการจะเข้าข่าย abuse หรือไม่นั้นไม่ได้สำคัญต่อเกณฑ์การตัดสินเลย
นี่ไม่ขัดแย้งกับข้อความที่ว่า "อย่างที่ผมพูดเมื่อวาน ถ้าไม่ได้ถูก flagged ผมก็คงเห็นด้วยกับเรื่องนั้นเหมือนกัน แต่ตั้งแต่วินาทีที่มีการปั่นคะแนนแนะนำให้กับโพสต์ที่เขียนไว้ การพูดเรื่องนี้ก็ไม่มีความหมายแล้ว" หรอกหรือครับ?
ตอนนี้ดูเหมือนว่าประเด็นและข้ออ้างกำลังเปลี่ยนไปเรื่อย ๆ จึงอยากให้ยึดให้คงที่สักอย่างเดียวครับ

[kunggom]

ผมมองว่าการรุมตำหนิเป็นหมู่คณะกับบทความที่เกี่ยวข้องกับหัวข้อของคอมมูนิตี้มากพอและไม่ใช่ AI slop ว่า "บทความนี้ต่ำกว่ามาตรฐานจนไม่เหมาะกับระดับของคอมมูนิตี้เรา" (หรืออย่างน้อยก็ทำให้ดูเหมือนเป็นเช่นนั้น) อาจเป็นสิ่งที่เป็นอันตรายต่อการเติบโตและการคงอยู่ของคอมมูนิตี้ยิ่งกว่าการปั่นโหวตเสียอีก เพราะมันอาจทำให้ภาพลักษณ์ภายนอกของคอมมูนิตี้ดู排他的และส่งผลให้ขัดขวางการไหลเข้าของผู้ใช้ใหม่ที่มีศักยภาพอย่างมาก

แน่นอนว่าไม่ได้หมายความว่าไม่ควรวิจารณ์ แต่ผมคิดว่าบรรยากาศแบบนี้อย่างน้อยก็ดูแปลกอยู่พอสมควร เพราะสิ่งที่เห็นร่วมกันมีเพียงความผิดหวังที่เนื้อหาไม่เป็นไปตามที่ตัวเองคาดหวัง ขณะที่การวิเคราะห์และฟีดแบ็กที่ดูสร้างสรรค์จริง ๆ กลับมีอยู่เพียงส่วนน้อย

และถ้าคุณคิดว่าการที่คนซึ่งถูกจับได้ว่า abuse กลับมาโพสต์อีกครั้งในวันถัดไปเป็นปัญหาจริง ๆ ลองใช้โอกาสนี้เสนอให้ทีมผู้ดูแลเพิ่มกฎที่เกี่ยวข้องอย่างเป็นทางการดีไหมครับ? เท่าที่ผมทราบ ตอนนี้ก็มีบทลงโทษอยู่ในระดับหนึ่งแล้ว แต่ดูเหมือนว่าคุณจะคิดว่ายังไม่เพียงพอ

[ifmkl]

ผมกลับไม่ค่อยเข้าใจนะครับ คุณกำลังมองว่านี่เป็นการโพสต์ขึ้นมาเพื่อรุมวิจารณ์กันอย่างเป็นระบบหรือเปล่า? ผมว่าข้ออ้างของคุณนี่แหละกลับทำให้ความคิดเห็นที่แต่ละคนสามารถแสดงออกได้ถูกมองในแง่ลบมากกว่าเสียอีกนะครับ? ต่อไปนี้ถึงจะเป็นแค่บทความแนวบันทึกการพัฒนา (ผมตั้งเป้าหมายเพื่อปรับปรุงการวาดดาวด้วย printf แล้วก็ปรับปรุงจนได้ใช้ for ครับ!) ก็หวังว่าคุณจะมองด้วยความอบอุ่นแบบเดียวกันนะครับ

[bandcrownie]

ดูเหมือนว่าคุณเองก็มักจะไปโปรโมตตัวเองในแกลเลอรีของเว็บอื่นเหมือนกัน เช่น Age of the Six Dragons หรือ Web Three Kingdoms Musou Chronicle
จากที่เห็นว่าคุณเอางานที่ยังทำไม่เสร็จมาใช้เป็นเหมือนของให้ลองชิม และหลังจากนั้นก็ทิ้งโปรเจกต์นั้นได้อย่างง่ายดาย ผมก็เลยรู้สึกว่าแล้วมันต่างจากโพสต์นี้ตรงไหนกัน.. ทำไมถึงใช้มาตรฐานที่เข้มงวดกับคนอื่นล่ะ

เพราะคิดว่า DC Inside เป็นที่ที่เด็ก ๆ มาเล่นกัน จะทำตามใจยังไงก็ได้ แต่ GeekNews เป็นที่ที่คุณผูกพัน เลยทนไม่ได้ถ้ามีใครมาทำให้สกปรกอย่างนั้นเหรอ

ไม่ได้อยากพูดแบบมีเหตุผลอะไรเป็นพิเศษหรอก แค่รู้สึกว่าอาการมาตรฐานสองชั้นนี่มันแปลกใหม่ดีเลยพูดขึ้นมา ดังนั้นถ้าคุณจะเถียง ก็ถือว่าคุณพูดถูกครับ สู้ ๆ กับการปั่นยอดนะครับ.

[tensun]

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