Tối ưu hóa API tự động hoàn thành từ khóa tìm kiếm - phản hồi trong dưới 100ms với 110 nghìn dữ liệu

 (velog.io)
11 điểm bởi newcodes7 2026-01-19 | 26 bình luận | Chia sẻ qua WhatsApp

Giới thiệu dự án

  • NewCodes là dịch vụ tuyển chọn blog kỹ thuật của doanh nghiệp
  • Kiến trúc Spring Boot + PostgreSQL
  • Triển khai tính năng tự động hoàn thành từ khóa tìm kiếm: gợi ý dựa trên Term, tìm kiếm tách jamo, tìm kiếm phụ âm đầu, gợi ý trang doanh nghiệp

Phát hiện vấn đề hiệu năng

  • Bảng Term đã tích lũy 110 nghìn dữ liệu
  • Thời gian phản hồi API tăng lên trên 1000ms
  • Mục tiêu: phản hồi trong vòng 100ms

Thử nghiệm lần 1: thêm chỉ mục (1000ms → 700ms)

  • Tạo chỉ mục tối ưu cho tìm kiếm tiền tố LIKE bằng varchar_pattern_ops
  • Tạo chỉ mục với tùy chọn CONCURRENTLY để không gián đoạn dịch vụ
  • Áp dụng chỉ mục riêng cho các cột term, decomposed_term, chosung

Thử nghiệm lần 2: chỉ mục cho hàm LOWER (700ms → 110ms)

  • Phát hiện vấn đề quét toàn bảng do sử dụng hàm LOWER()
  • Tạo chỉ mục dựa trên hàm (Functional Index)
  • Tái cấu trúc chỉ mục theo dạng LOWER(tên_cột) varchar_pattern_ops

Thử nghiệm lần 3: JOIN → EXISTS (110ms → 100ms)

  • INNER JOIN giữa Corporation và Article là nút thắt cổ chai về hiệu năng
  • Chuyển sang subquery EXISTS để thu hẹp phạm vi quét
  • Tối ưu hóa để chỉ kiểm tra "sự tồn tại của dữ liệu"

Thử nghiệm lần 4: phi chuẩn hóa & chỉ mục bao phủ (100ms → 90ms)

  • Thêm cột total_frequency để loại bỏ phép tính tổng hợp
  • Thay thế các phép toán GROUP BY, SUM bằng giá trị được tính sẵn
  • Giảm số lần I/O bằng chỉ mục bao phủ
  • Bao gồm term và total_frequency trong chỉ mục bằng mệnh đề INCLUDE

Thử nghiệm lần 5: JDBC Template (90ms → 80ms)

  • Loại bỏ overhead của JPA/Hibernate
  • Thực thi truy vấn trực tiếp bằng JDBC Template
  • Trong các tác vụ chỉ đọc đơn giản, việc bỏ qua tầng ORM mang lại hiệu quả

Giải quyết vấn đề Nginx Rate Limiting

  • Cấu hình ban đầu: giới hạn 2 lần mỗi giây, burst 10
  • Phát sinh lỗi request fail do debouncing 100ms
  • Cải thiện: cho phép 10 lần mỗi giây, đổi burst thành 20
  • Đổi status code từ 444 → 429

Giảm kích thước dữ liệu phản hồi

  • Loại bỏ tên trường JSON, chuyển sang phản hồi dựa trên mảng
  • Phân biệt loại bằng số (0: Corporation, 1: Theme, 2: Term)
  • Giảm thời gian truyền tải qua mạng

Xử lý song song với CompletableFuture

  • Chạy đồng thời độc lập các truy vấn Corporation, Theme, Term
  • So với chạy tuần tự, chỉ mất tối đa bằng thời gian phản hồi dài nhất
  • Bổ sung ExecutorService và xử lý ngoại lệ

Kết quả cuối cùng

  • Ban đầu 1000ms → cuối cùng 80ms (máy chủ phát triển), 40ms (máy chủ production)
  • Cải thiện hiệu năng hơn khoảng 90%

Nội dung học được chính

  • Tầm quan trọng của việc định nghĩa vấn đề và thiết lập hướng đi
  • Cân bằng giữa việc tận dụng AI và khâu kiểm chứng của lập trình viên
  • Cần thiết kế dưới góc nhìn của toàn bộ kiến trúc
  • Lựa chọn loại chỉ mục: chỉ mục đơn/chỉ mục tổng hợp/chỉ mục bao phủ
  • Cẩn trọng việc vô hiệu hóa chỉ mục khi sử dụng hàm
  • Hiểu cơ chế hoạt động bên trong của JPA
  • Phân tích kế hoạch thực thi truy vấn bằng EXPLAIN

Hướng cải thiện trong tương lai

  • Sử dụng cấu trúc dữ liệu Trie
  • Cache các thuật ngữ được tìm kiếm thường xuyên
  • Tận dụng CDN (khi triển khai dịch vụ toàn cầu)

Bài viết liên quan

26 bình luận

 
moderator 2026-01-21

Tôi là quản trị viên.
Hiện tại, phần thảo luận trong bình luận đang có dấu hiệu trở nên quá nóng khi đan xen cả những nội dung không liên quan đến khía cạnh kỹ thuật của bài viết, nên tôi xin thông báo như sau.

Chúng tôi luôn hoan nghênh các cuộc thảo luận kỹ thuật và phản hồi.
Ý kiến có thể rất đa dạng, nhưng khi viết bình luận, mong mọi người giữ phép lịch sự cơ bản với nhau và tập trung vào tranh luận dựa trên lý lẽ; đồng thời mong việc trao đổi xoay quanh chính nội dung của bài viết hiện tại hơn là nhắm vào cá nhân hay lý lịch của ai đó.

Vui lòng xem lại hướng dẫn viết bình luận trong Cách sử dụng trang.

  • Hãy trao đổi một cách thân thiện và nhã nhặn.
  • Xin đừng công kích tác giả bài viết.

Xin lưu ý thêm rằng, đối với các bài đăng đã bị gắn cờ, việc ghi nhận và xử lý trên hệ thống đã được thực hiện; chúng tôi cũng sẽ tiếp tục cải thiện chính sách vận hành và hệ thống liên quan.
Ngoài ra, nếu có ý kiến hoặc phản hồi về việc vận hành, xin vui lòng liên hệ qua email.
 
kunggom 2026-01-21

Vâng, tôi hiểu rồi.
 
kunggom 2026-01-20

Tôi nghĩ không khí trong phần bình luận có vẻ hơi lạ. Có phải so với lúc mới đăng lên thì tiêu đề hoặc nội dung đã bị thay đổi gì không? Bản thân việc có một bài viết ở mức này được đăng lên cũng không phải là điều gì quá lạ.
Cũng có ý kiến như: "Chắc sẽ không viết những bài như thế này trên blog kỹ thuật của doanh nghiệp đâu." nhưng việc xác định mục tiêu hiệu năng và lặp lại các cải tiến để đạt được mục tiêu đó là nội dung khá thường thấy trên blog kỹ thuật của doanh nghiệp.
Ví dụ, trong số những bài tôi từng xem trước đây có bài như sau.
 
kuthia 2026-01-21

Tôi đồng ý với điều bạn nói.
Nhưng tôi cho rằng tình hình hiện tại là sự chỉ trích đối với thái độ của người dùng đã lạm dụng. Việc bàn về chất lượng bài đăng thế nào dường như đang lệch khỏi trọng tâm.
Phản ứng thiếu thiện chí có lẽ là do bối cảnh người viết từng có tiền sử lạm dụng. Tôi nghĩ việc nói nội dung ra sao là phần thừa không cần thiết.
 
kunggom 2026-01-21

Vì thế nên tôi mới thấy nghi ngờ ở điểm đó.
Nếu mọi người đều phản ứng kiểu như "Người này là kẻ lạm dụng!" thì có lẽ tôi đã không viết bình luận như thế này. Nhưng đa số bình luận lại đang bàn về chất lượng của bài viết gốc, nên tôi thấy điểm đó khá kỳ lạ. Nếu thật sự vấn đề là hành vi lạm dụng, thì chẳng phải việc lôi chất lượng bài viết ra nói hoàn toàn là lời thừa sao?
 
nemorize 2026-01-20

Tôi đồng ý.
Thậm chí nhìn vào câu "Từ tháng 5 năm 2025 tôi đã bắt đầu tự mình làm trong quân đội!" thì có vẻ đây cũng không phải blog doanh nghiệp...

Dĩ nhiên khó mà phủ nhận rằng nội dung được chia sẻ là "công việc đương nhiên phải làm",
và cũng đúng là "không có câu chuyện về điểm khác biệt, chỉ ở mức bài thực hành cá nhân",

Nhưng GeekNews vốn là một nơi có bầu không khí kiểu không nên chia sẻ những thứ như thế này sao?
Nếu chia sẻ trải nghiệm từng làm những công việc đương nhiên phải làm thì không được sao?
Những trải nghiệm không có điểm khác biệt thì không được chia sẻ sao?
Những trải nghiệm chỉ ở mức bài thực hành thì không được chia sẻ sao?
 
ifmkl 2026-01-20

Có thể lúc đó bạn đã cảm thấy như vậy. Lý do tôi để lại bình luận như bên dưới là vì hai điểm. Thứ nhất, bài đăng show gn đầu tiên đã bị gắn cờ vì hành vi lạm dụng. Một ngày sau, tác giả tóm tắt bài viết trên velog của mình rồi đăng lại bài mới, nhưng liệu bản thân nội dung đó có thực sự là thứ đáng để được đăng lên không? Nếu hỏi rằng có thể thấy được những trăn trở và nỗ lực của chính tác giả hay không, thì cũng giống như ý kiến của những người khác, tìm kiếm là lĩnh vực mà kỹ thuật nhìn chung đã khá phổ biến; hơn là phần kỹ thuật, nội dung bài blog đó được viết vòng vo và tôi cho rằng nó nằm trên phần kéo dài của việc quảng bá cho chính dịch vụ của mình, nên tôi đã để lại bình luận đó.
 
kunggom 2026-01-20

Có lẽ việc bị gắn cờ lạm dụng và bị mất thiện cảm là yếu tố lớn nhất.

Bản thân nội dung bài blog là phần nối dài cho việc quảng bá dịch vụ của chính mình thì các blog kỹ thuật của những công ty khác cũng vậy, nên tôi nghĩ việc chỉ vì thế mà loại trừ là một tiêu chí khá nhạy cảm.

Ngoài ra, xét ở khía cạnh bài viết này có cho thấy sự trăn trở và nỗ lực của chính tác giả hay không, thì khi giả thuyết rằng thêm index sẽ cải thiện hiệu năng bị bác bỏ, việc tiếp tục xem xét execution plan, cân nhắc business logic, rồi cải thiện lặp đi lặp lại bằng cách thay đổi query hoặc schema để đạt được mục tiêu hiệu năng, theo tôi, đã là đủ sự trăn trở và nỗ lực rồi.
 
ifmkl 2026-01-19

Tôi cũng đã vào blog đọc bài gốc rồi. Tôi cảm thấy có phần chênh lệch giữa tiêu đề và nội dung thực tế. Những chức năng anh triển khai hay hướng cải thiện mà anh nói đến thực ra đều là các phần đã được hiện thực và phản ánh trong nhiều dự án mã nguồn mở có sẵn từ trước; còn phần anh làm là nâng cấp chức năng tìm kiếm vốn ban đầu chỉ được triển khai rất đơn giản trong chính dịch vụ của mình. Nhưng nếu chỉ nhìn tiêu đề thì lại tạo cảm giác như thể anh đã cải tiến thuật toán một cách quy mô lớn vậy,, Bài trước của anh cũng từng bị gắn cờ là quảng bá, nên tôi nghĩ khi viết bài có lẽ anh cần cân nhắc thêm một chút.
 
newcodes7 2026-01-19

Nếu bạn đã cảm thấy như vậy thì tôi xin lỗi. Tôi nghĩ rằng mỗi người sẽ có kỳ vọng khác nhau khi đọc tiêu đề. Tuy vậy, đúng là cần viết tiêu đề sao cho rõ ràng nhất có thể để nội dung mà người đọc kỳ vọng được thống nhất hơn. Tôi sẽ lưu ý điều này.

Ngoài ra, mong bạn hãy xem bài này tách biệt với bài trước. Ở bài trước, tôi đã dùng 2 tài khoản không sử dụng để thử upvote nên bị gắn cờ. Đây hoàn toàn là lỗi của tôi, và tôi muốn nói rõ rằng đó không phải là vấn đề của bản thân bài viết.
 
click 2026-01-19

Không rõ anh/chị đã cân nhắc thử dùng chỉ mục GIN thay cho chỉ mục lower() chưa. Dù sao cũng đã dùng raw SQL bằng JdbcTemplate, vậy nhân tiện thử FTS thì sao?

Cách bất đồng bộ dùng CompletableFuture.supplyAsync() nếu không chỉ định riêng ExecutorService thì cũng sẽ dùng commonPool của ForkJoinPool, nên
nếu số người dùng truy cập đồng thời tăng đến mức commonPool dùng thay cho request thread bị lấp đầy (số lõi CPU - 1) thì có thể sẽ không chịu nổi.
Phần này có lẽ sẽ được giải quyết gọn gàng hơn nếu chuyển sang mô hình reactive hoặc nâng phiên bản JVM để đưa virtual thread vào.
 
newcodes7 2026-01-19

Xin chào! Trước hết, mình thực sự cảm ơn bạn đã để lại bình luận góp ý.

Mình đánh giá rằng GIN index không cần thiết trong trường hợp này! Hiện tại, API gợi ý tự động hoàn thành từ khóa tìm kiếm chỉ cần chính term. Không cần biết term đó thuộc những article nào. Ngược lại, trong API tìm kiếm, mình đang sử dụng một loại index tương tự GIN index. Mình tận dụng paradeDB, một extension của Postgres, để dùng BM25 index. Trong bài viết không đề cập chi tiết, nhưng hiện tại mình đang chỉ định và sử dụng riêng ExecutorService. Tuy vậy, như bạn đã nói, về sau mình cũng sẽ cân nhắc cách tiếp cận reactive hoặc virtual thread!!
 
newcodes7 2026-01-20

Trước hết, tôi xin gửi lời xin lỗi liên quan đến bài viết này và cả bài viết trước.
Việc tôi dùng 2 tài khoản không sử dụng để upvote là lỗi của tôi và là một hành động thiếu suy nghĩ.

Vì mong dự án mà tôi đã dồn nhiều công sức trong thời gian dài được nhiều người chú ý hơn, tôi đã có hành động sai trái.
Nhưng dù có lý do như vậy đi nữa thì sự thật là không thể lấy đó để biện minh cho việc vi phạm quy định.
Do những lượt upvote mà tôi tùy tiện tạo ra, có lẽ bài viết của ai đó đã phải tụt hạng, và trật tự của trang cũng đã bị xáo trộn.

Ngoài ra, việc tôi đăng một bài viết mới khác ngay vào ngày hôm sau khi bị gắn cờ cũng rất dễ gây hiểu lầm.
Nói thật là vì không có chế tài hạn chế sử dụng trang riêng nào nên tôi đã nghĩ không biết có phải là vẫn có thể đăng ngay hay không. Đó là suy nghĩ nông cạn của tôi.
Giờ nghĩ lại, bất kể có bị xử lý hay không, tôi lẽ ra cũng nên tự kiềm chế.
Nếu đặt mình ở phía ngược lại để suy nghĩ, thì ngay cả tôi cũng sẽ không có thiện cảm nếu có ai đó làm y hệt như vậy trong một không gian mà tôi yêu thích.

Trong suốt thời gian qua, kể từ khi bắt đầu phát triển, tôi vẫn luôn nghĩ một cách vô điều kiện rằng việc “chia sẻ” là điều tốt và đã thực hành như vậy.
Nhưng qua lần này, tôi nhận ra rằng có những không gian phù hợp để chia sẻ và cũng có những thời điểm phù hợp để chia sẻ.
Tôi cũng cảm thấy rằng nếu mình là người mới bước vào một không gian mà ai đó đang dành tình cảm và sự quan tâm, thì trước hết cần phải tôn trọng đối phương hết mức có thể.
Vì vậy, lẽ ra tôi nên đọc nội quy sử dụng trước, quan sát bầu không khí của trang và không làm những điều đi ngược lại với điều đó.

Tôi thừa nhận lỗi lầm của mình và xin được giải trình theo cách này.
Từ lần sau, tôi sẽ cố gắng sử dụng trang một cách chín chắn hơn.
 
roxie 2026-01-24

:+1:
 
newcodes7 2026-01-21

Đúng như bạn nói, chỉ cần truy vấn bằng decomposed term thôi là đã đủ. Sau khi có cái này thì term là một điều kiện không cần thiết, nhưng có vẻ tôi đã không cân nhắc đến điều đó. Nhờ bạn mà tôi đã sửa lại. Cảm ơn bạn!
 
skageektp 2026-01-20

Có cảm giác là nội dung này hơi... không thật sự đúng kiểu thứ mà những người vào GeekNews muốn xem thì phải?
 
kunggom 2026-01-20

Tôi thực sự không hiểu có gì mà phải làm quá lên như vậy.
Số lượng bản ghi đâu phải 1 triệu hay 10 triệu, mà ngay từ tiêu đề đã ghi rõ quy mô chỉ hơn 100 nghìn một chút; trong tình huống đó, thay vì bám sát những điều cơ bản, bản thân việc lại đi kỳ vọng vào một kiểu tối ưu hóa gì đó thật hoành tráng chẳng phải đã hơi kỳ lạ sao? Tôi khá tò mò rốt cuộc người ta đã mong đợi điều gì ghê gớm đến thế.
Tôi cũng không rõ vì sao một bài viết trình bày quá trình chỉnh từng thứ một theo những điều cơ bản, trong bối cảnh DB còn chưa được tối ưu đúng cách, lại bị xem như thể đang cố câu tương tác đến vậy. Theo tôi, bầu không khí mang tính loại trừ kiểu "thứ gì không phải tốt nhất thì ngay từ đầu không nên đăng ở đây" là có hại.
 
crawler 2026-01-20

> Chẳng phải ngay từ việc kỳ vọng một kiểu tối ưu hóa gì đó thật hoành tráng, thay vì bám sát những điều cơ bản, đã là hơi kỳ lạ rồi sao?

Con người chỉ nhìn thấy nhiều đến mức mình biết.
Để dễ hình dung, lúc này tôi đang nghĩ đến ví dụ về việc làm một diễn đàn.

Với lập trình viên mới bắt đầu, làm diễn đàn từng là một trong những dự án portfolio đầu tay được khuyên làm rất nhiều.

Nếu nghĩ đơn giản thì nó rất dễ.
Đăng bài lên, hiển thị trong danh sách là xong. Nếu làm thật đơn giản thì thậm chí có khi còn không cần cả DB backend.

Nhưng con người chỉ thấy được đến mức mình biết.
Nếu làm một diễn đàn một cách nghiêm túc thì từ DB, chức năng bình luận, đăng nhập, rồi phát triển đăng nhập thành xác thực OAuth hay JWT, cho đến ngay cả chức năng viết bài đơn thuần cũng có đính kèm ảnh và video, hỗ trợ định dạng bài viết, rồi bảo mật bắt đầu từ XSS.

Cùng một đoạn văn bản nhưng tùy vào kiến thức nền của người đọc mà hình ảnh họ vẽ ra trong đầu có thể khác nhau rất nhiều.

Tôi hiểu khi nhìn tiêu đề thì bạn kunggom đã hình dung kiểu tự động hoàn thành nào.

Nhưng mỗi độc giả đều đã sống những cuộc đời khác nhau, và rốt cuộc những tính năng mà họ tưởng tượng ra cũng sẽ rất khác nhau.

Tôi cũng hiểu bạn viết bình luận này với dụng ý gì.
Tôi cũng đồng ý với ý kiến đó, nhưng tôi tin rằng bạn cũng biết đó là lời nói không thực sự phù hợp với hoàn cảnh của người viết bài lúc này.
 
kunggom 2026-01-20

Liệu bạn có thể giải thích thêm một chút về đoạn "đó là nhận xét không thực sự phù hợp với hoàn cảnh của người viết bài này" được không?
Theo bài gốc, dự án đó được nêu rõ là "một dự án cá nhân, không phải dịch vụ có lưu lượng cực lớn hoặc cần tạo ra doanh thu". Vì vậy, nếu có đưa vào một kiểu tối ưu hóa gì đó khá hoành tráng thì cũng có thể suy đoán rằng đó chỉ là vì tò mò cá nhân hay những lý do tương tự, chứ không phải vì lý do thực dụng. Do đó, tôi không nghĩ việc không đầu tư đến mức độ nỗ lực kỹ thuật như vậy là điều gì quá lạ; chính vì thế tôi không hiểu vì sao phản ứng của một số người lại tiêu cực mạnh đến vậy. Mà những con số được trích trong tiêu đề cũng đâu có mâu thuẫn với nội dung bài viết.
 
crawler 2026-01-21

Tôi không nghĩ kunggom là một lập trình viên thiếu kiến thức nền đến mức không thể hiểu được phép ví von về bảng tin mà tôi đã nói.

Có vẻ như khác biệt trong quan điểm hiện tại bắt nguồn từ cách nhìn nhận về người dùng abusing, nên tôi xin nói lần cuối.

Điều tôi kỳ vọng là tìm kiếm ngữ nghĩa.
Tìm kiếm ngữ nghĩa hoàn toàn không phải là một chủ đề thiếu tính thực tế trong làn sóng AI hiện nay, và tôi tin là bạn cũng biết rằng ngay cả cá nhân cũng hoàn toàn có thể tự triển khai được.

Ngay từ đầu, khi chúng ta nhấn vào tiêu đề thì cũng không phải là nhấn trong trạng thái đã hiểu bối cảnh của người viết, nhưng ý tôi là ngay cả khi đó không phải là một dịch vụ có lưu lượng truy cập khổng lồ hoặc cần phải tạo ra doanh thu thì vẫn hoàn toàn có thể triển khai được.

Và tôi hiện chỉ đang nói về tiêu đề.
> Theo bài viết gốc thì dự án đó ~

Tôi đang nói về hình ảnh mà tôi tưởng tượng ra khi nhìn tiêu đề, nên phần đó hiện không cần thiết trong cuộc trao đổi của chúng ta.

> Tình huống của người viết bài này lúc này
Có lẽ tôi hiểu kunggom đang nghĩ gì về người viết bài rồi. Có vẻ như bạn xem họ là một lập trình viên mới vào nghề, một người mà dù viết gì cũng phải được thông cảm.

Như tôi đã nói hôm qua, nếu họ không bị flagged thì tôi cũng đã đồng ý với điều đó, nhưng từ thời điểm họ thao túng lượt đề xuất cho bài viết của mình thì câu chuyện này không còn ý nghĩa nữa.

> Và nếu bạn thực sự cho rằng việc một người bị phát hiện abusing lại tiếp tục viết bài vào ngày hôm sau là có vấn đề

Ở trên bạn đã nói như vậy.
Nếu một người đã bị flagged mà vẫn có tự do viết bài, thì cũng có tự do để phê bình điều đó.
Như chính bạn đã nói, nếu bạn cho rằng việc nói nghiêm khắc hơn một chút với người đã bị flagged trong phần bình luận là có vấn đề, thì thay vì chỉ ra trong bình luận, hãy thử kiến nghị với ban vận hành xem sao.
 
kunggom 2026-01-21

Ý của bạn là bạn tưởng họ sẽ chia sẻ kinh nghiệm tối ưu hóa cho kiểu dịch vụ có thể gợi ý ứng viên tìm kiếm rất chuẩn ngay cả khi người dùng nhập linh tinh, chẳng hạn bằng cách đưa embedding vào.
Nếu là như vậy thì có lẽ đó phải là điều người ta kỳ vọng từ một tiêu đề kiểu như "gợi ý từ khóa tìm kiếm" hơn, nhưng tôi hiểu bạn đã mong đợi điều gì.

Tôi hiểu lập trường chỉ trích hành vi lạm dụng, nhưng câu cuối cùng lại khiến tôi hơi thất vọng vì nó có vẻ lén chuyển trọng tâm từ sự non tay về mặt kỹ thuật sang vấn đề vi phạm quy tắc cộng đồng, như một kiểu thử "lấy chính logic và lập luận của bạn để phản bác bạn" khá vụng về.
Nếu ngay từ đầu bạn chỉ tập trung phê phán đúng một chuyện là lạm dụng thì đã thuyết phục hơn. Nếu thực sự là vậy, thì kể cả bài viết kia đúng là có chứa những nội dung mà bạn nói mình vốn kỳ vọng, như tối ưu hóa vector embedding trên DBMS hiện đại, hoặc kể cả có dùng một "tiêu đề khiêm tốn", thì phản ứng thù địch nhắm vào lịch sử lạm dụng gần đây của tác giả vẫn sẽ xuất hiện, và về điểm đó tôi hoàn toàn không có ý kiến gì. Vì đó vốn là chuyện không mấy liên quan đến nội dung kỹ thuật.

Điều tôi phản đối là: tại sao biểu hiện đó lại được bộc lộ dưới dạng chỉ trích về "sự non tay kỹ thuật"? Nếu lạm dụng là hành vi không thể chấp nhận, thì đương nhiên phải bị chỉ trích bất kể nội dung ra sao. Nếu vậy thì có lý do gì để lồng cả phê bình về nội dung vào đó không? Thế nhưng các bình luận ở đây thì hầu như đều mang sắc thái cho rằng nội dung còn non về mặt kỹ thuật. Chính bạn cũng ví nó với kiểu "một lập trình viên mới vào nghề làm bảng tin" và nói với tôi rằng "chỉ thấy được đến đâu là do biết đến đó". Nếu vậy thì chẳng phải cần phải nghi ngờ xem vấn đề lạm dụng thực ra chỉ là chuyện phụ, được gắn thêm vào sau đó hay sao?

Theo đúng nội dung bình luận của bạn, thì ngay cả nếu bài gốc đúng là loại nội dung mà bạn kỳ vọng, bạn vẫn sẽ chỉ trích chỉ riêng vì hành vi lạm dụng. Hay là chẳng lẽ, dù có lạm dụng đi nữa, nhưng nếu cá nhân bạn lại thấy thích nội dung bài viết thì sẽ không cần thực hiện quyền nói một cách "nghiêm khắc"?
Vì vậy tôi xin hỏi lại. Nếu quả thực bạn đang chỉ trích tác giả bài viết gốc vì hành vi lạm dụng, thì tại sao bình luận của bạn lại chủ yếu xoay quanh việc phê bình nội dung thay vì chính hành vi lạm dụng đó?
 
kunggom 2026-01-21

Có căn cứ nào cho phần nói rằng tôi đã "cản trở quyền tự do ngôn luận của người khác" không? Tôi hơi không hiểu điểm này. Đâu phải tôi có quyền quản trị không gian này để có thể ngăn người khác viết bài hay bình luận. Thực tế thì chẳng phải ông vẫn đang viết được một bình luận dài như thế này đó sao.
Nếu việc chỉ đơn thuần đăng một bình luận phản đối ý kiến của người khác cũng bị xem là ngăn cản quyền tự do ngôn luận của họ, thì cũng phải coi rằng crawler đang xâm phạm quyền tự do phát biểu của tôi lúc này. Nếu không thì về mặt logic chẳng phải là tiêu chuẩn kép sao?

Và như chính crawler cũng đã thừa nhận, rốt cuộc việc có phải lạm dụng hay không hoàn toàn không quan trọng trong tiêu chí phán đoán.
Điều này chẳng phải mâu thuẫn với câu "Như tôi đã nói hôm qua, nếu không bị gắn cờ thì tôi cũng đã đồng ý với điều đó, nhưng từ thời điểm bài viết được thao túng lượt đề xuất thì câu chuyện này không còn ý nghĩa nữa" sao?
Có vẻ như ông đang liên tục thay đổi luận điểm và chủ trương, nên tôi mong ông hãy cố định vào một điều thôi.
 
kunggom 2026-01-20

Tôi cho rằng việc cùng nhau chỉ trích (hoặc trông như đang làm vậy) rằng “bài này không đạt chất lượng, không phù hợp với đẳng cấp của cộng đồng chúng ta” đối với những bài viết có liên quan đầy đủ đến chủ đề của cộng đồng và không phải là AI slop, có lẽ còn gây hại cho sự phát triển và duy trì của cộng đồng hơn cả việc thao túng phiếu bầu. Bởi điều đó có thể khiến hình ảnh đối ngoại của cộng đồng trở nên khép kín, từ đó cản trở nghiêm trọng việc thu hút người dùng mới tiềm năng.

Tất nhiên, điều này không có nghĩa là không nên phê bình. Nhưng ít nhất thì tôi thấy bầu không khí như thế này hơi kỳ lạ. Điểm chung chỉ là sự thất vọng vì nội dung không đúng như họ kỳ vọng, còn những phân tích và phản hồi mang tính xây dựng thì lại rất ít.

Và nếu thực sự bạn cho rằng việc một người bị phát hiện lạm dụng rồi ngay ngày hôm sau lại tiếp tục đăng bài là một vấn đề, thì nhân dịp này thử chính thức kiến nghị ban điều hành bổ sung quy định liên quan xem sao? Tôi biết là hiện đã có chế tài ở một mức độ nào đó, nhưng có vẻ bạn cho rằng như vậy vẫn là chưa đủ.
 
ifmkl 2026-01-20

Tôi thì ngược lại, thấy khó mà hiểu được. Chẳng lẽ bạn đang cho rằng bài này được đăng lên để cả nhóm cùng nhau có tổ chức mà chỉ trích sao? Chính lập luận của bạn mới giống như đang nhìn những ý kiến mà mỗi cá nhân có thể đưa ra theo hướng tiêu cực thì phải? Sau này, kể cả có đăng những bài kiểu như nhật ký phát triển (đặt mục tiêu cải thiện việc vẽ ngôi sao bằng printf, rồi cải thiện và dùng vòng lặp for!) thì cũng mong bạn vẫn nhìn nhận với sự ấm áp như vậy.
 
bandcrownie 2026-01-20

Có vẻ như bạn cũng thường xuyên tự quảng bá ở gallery của các site khác, như thời Lục Long hay web Tam Quốc Vô Song Truyện.
Khi nhìn thái độ đưa sản phẩm còn dang dở của mình ra để "nhúng thử" rồi sau đó dễ dàng bỏ mặc dự án đó, tôi thấy cũng chẳng khác gì mấy với bài viết này.. vậy mà tại sao lại áp dụng tiêu chuẩn khắt khe với người khác như thế.

Vì DC là chỗ con nít chơi nên muốn làm gì thì làm cũng được, còn GeekNews là nơi bạn quý mến nên nếu người khác làm bẩn thì không chịu nổi sao.

Tôi cũng không định nói cho có logic gì đâu, chỉ là thấy kiểu đạo đức giả này khá mới lạ nên mới nói vậy thôi, nên nếu bạn muốn phản bác thì bạn đúng. Chúc lạm dụng vui vẻ.
 
tensun 2026-01-20

API tự động hoàn thành tìm kiếm được đặt tiêu đề như thể là một dịch vụ đã được tối ưu, nhưng nội dung thực ra chỉ là tối ưu hóa truy vấn DB.
Nếu là mục đích thương mại thì chỉ cần tối ưu Oracle là đã đủ làm được, còn tự động hoàn thành thì đã có rất nhiều dịch vụ sẵn rồi. Không thấy nói gì về điểm khác biệt, nội dung cũng chỉ ở mức bài thực hành cá nhân.
Khá khó chịu khi đọc.