- Khi chạy lặp lại agent tuyển dụng ATS mã nguồn mở của HackerRank với cùng một CV và cùng một lệnh, điểm số dao động từ 66 đến 99 điểm, và với ngưỡng loại 85 điểm thì 65% trường hợp bị loại
- Công cụ này phân tích CV PDF và gọi LLM 6 lần để cấu trúc hóa thông tin cơ bản, kinh nghiệm, học vấn, kỹ năng, dự án, thành tích, rồi bổ sung cả thông tin GitHub để đánh giá theo thang 100 điểm + tối đa 20 điểm thưởng
- Điểm kỹ năng kỹ thuật gần như ổn định với 98/100 lần là 8/10, nhưng phần đánh giá dự án cho thấy độ biến động lớn, lúc thì nhận xét “thiếu độ phức tạp kiến trúc”, lúc thì “thể hiện triển khai thực tế”
- Không chỉ mô hình mặc định gemma3:4b với temperature 0.1 mà ngay cả ở temperature 0 vẫn còn tính không xác định; ngay cả khi đổi sang Gemini, với ngưỡng loại 60 điểm vẫn xuất hiện tỷ lệ bị loại 28%
- Hạng mục kinh nghiệm lại cho thấy vấn đề ngược lại: ngay cả CV cũ chỉ có một kỳ thực tập cũng nhận 25/25 điểm, cho thấy cách chấm điểm bằng LLM có thể trở thành bộ lọc mang tính may rủi hơn là công cụ phân biệt chất lượng ứng viên
Cùng một CV nhưng mỗi lần lại nhận điểm khác nhau
- ATS mã nguồn mở của HackerRank là hiring-agent, trở thành đối tượng thử nghiệm sau khi được chú ý trên LinkedIn và Reddit
- Điểm ở lần chạy đầu tiên là 90/100, nhưng sau khi xóa câu lệnh in phục vụ debug rồi chạy lại với cùng CV và cùng lệnh thì kết quả là 74/100
- Khi tắt
DEVELOPMENT_MODEvà chạy lặp 100 lần, dải điểm mở rộng từ 66 đến 99 điểm - Nếu ngưỡng qua vòng của công ty là 85 điểm, thì chính cùng một CV cũng có 65% xác suất bị loại
Pipeline đánh giá và cấu trúc phân bổ điểm
- Công cụ phân tích CV PDF thành văn bản rồi gọi LLM nhiều lần để cấu trúc hóa thông tin ứng viên
- Thông tin cơ bản
- Kinh nghiệm
- Học vấn
- Kỹ năng
- Dự án
- Thành tích
- Công cụ quét hồ sơ GitHub và các repository nổi bật, sau đó gắn thêm thông tin này làm ngữ cảnh bổ sung trước khi đưa toàn bộ dữ liệu vào một lượt đánh giá bằng LLM
- Mô hình mặc định là gemma3:4b chạy cục bộ, với temperature đặt là 0.1
- Điểm tối đa là 100, cộng thêm tối đa 20 điểm thưởng
- Đóng góp mã nguồn mở: 35 điểm
- Dự án cá nhân: 30 điểm
- Kinh nghiệm công việc: 25 điểm
- Kỹ năng kỹ thuật: 10 điểm
- Kinh nghiệm startup, website portfolio, blog kỹ thuật, v.v.: tối đa 20 điểm thưởng
Hạng mục ổn định và hạng mục dao động
- Kỹ năng kỹ thuật gần như nhất quán, với 98/100 lần đều ra 8/10
- Việc xác định có kỹ năng như React hay không gần với một checklist, nên ít chỗ cho phán đoán chủ quan của LLM
- Ngược lại, hạng mục dự án lại cho thấy khác biệt rất lớn giữa các lần chạy
- Ở một lần chạy, dự án bị đánh giá là “thiếu độ phức tạp kiến trúc”
- Ở lần khác, lại được đánh giá là “thể hiện triển khai thực tế”
- Temperature 0.1 tuy là mức thấp nhưng kể cả khi giảm xuống 0 thì vấn đề vẫn không biến mất
- Trong GitHub issue mở vào tháng 10/2025, ngay cả ở temperature 0 thì 6 lần liên tiếp vẫn cho các điểm 27, 34, 32, 34, 34, 30
Đổi mô hình nhưng sự bất ổn vẫn còn
- Vì gemma3:4b là mô hình chạy cục bộ, ảnh hưởng từ mô hình cũng được kiểm tra riêng
- Khi dùng Gemini, phân bố điểm thu hẹp hơn, nằm trong khoảng 48 đến 64 điểm
- Tuy vậy, nếu ngưỡng loại là 60 điểm thì ứng viên vẫn có 28% xác suất bị loại bất kể nội dung CV của mình
- Điểm mã nguồn mở trở nên nhất quán hơn, nhưng điểm dự án vẫn dao động mạnh
Vấn đề ngược ở điểm kinh nghiệm: ổn định nhưng vô dụng
- Hạng mục kinh nghiệm cho ra 25/25 điểm ở mọi lần chạy
- Ngay cả trường hợp chỉ có một kỳ thực tập như CV cũ cũng vẫn nhận 25/25 điểm
- Mục Production trong prompt đánh giá chỉ có hai dòng
- Phân tích kinh nghiệm công việc thực tế, thực tập và production trong các mục
workvàvolunteer - Cân nhắc thêm cho vai trò founder, co-founder và kỹ sư giai đoạn đầu ở startup
- Phân tích kinh nghiệm công việc thực tế, thực tập và production trong các mục
- Không có tiêu chí, ví dụ hay mốc chuẩn nào để phân biệt 15 điểm với 25 điểm
- Kết quả là kỳ thực tập của một kỹ sư junior, 10 năm kinh nghiệm hệ thống phân tán của một principal engineer, và CV dùng trong bài thử đều có thể cùng nhận 25/25 điểm
Rủi ro thực tế trong sàng lọc CV
- Dùng LLM để phân tích CV thành dữ liệu có cấu trúc hoặc kiểm tra ứng viên có biết Python hay không là trường hợp sử dụng tương đối phù hợp
- Nhưng việc quyết định kinh nghiệm của ứng viên là 18 hay 24 điểm lại tạo ra kết quả gần như một vibe-check
- Cấu trúc chấm điểm trong đó mã nguồn mở và dự án chiếm tổng cộng 65% trọng số cũng có thể làm méo mó quyết định tuyển dụng
- Một ứng viên có 2 kỳ thực tập và dự án mã nguồn mở có thể được đánh giá cao hơn kỹ sư đã tạo ra S3 với 30 năm kinh nghiệm
- Một kỹ sư đã làm những công việc quan trọng nhưng không để lại dấu vết trên GitHub có thể mất hơn một nửa số điểm
- Các kỹ sư có quyền đưa công cụ AI vào khâu sàng lọc CV cần lưu ý rằng một công cụ không phân biệt được chất lượng có thể chỉ trở thành thiết bị để loại ứng viên
Đính chính
- Dòng 1 của template resume_evaluation_criteria.jinja có cụm “Software Intern”
- Cụm này không được tài liệu hóa và cũng không được tham chiếu ở nơi khác trong repository
- Chính template đó về sau lại cộng điểm thưởng cho các vai trò founder, co-founder và kỹ sư startup giai đoạn đầu
- Ngay cả khi thêm rõ prompt Senior SWE rồi chạy lại, kết quả vẫn không thay đổi, và các chiều chấm điểm hoạt động không phụ thuộc vào cấp độ vị trí
1 bình luận
Ý kiến trên Hacker News
Có nhiều người đáng ngạc nhiên là không biết LLM vận hành như một quá trình thuần xác suất, nên những bài viết đào sâu như thế này thật đáng hoan nghênh
Tôi đang tìm việc, và có khi đây là lý do dạo này khó nhận được cuộc gọi phản hồi đến vậy. Có vẻ hồ sơ chỉ bị ném vào một hố đen LLM nào đó, và chẳng ai thực sự biết nó hoạt động ra sao
Phần trong bài nói “temperature 0.1 — được xem là giá trị thấp nên hướng mô hình tới đầu ra mang tính quyết định” là không chính xác. Temperature không phải công tắc bật/tắt tính quyết định, mà là giá trị ảnh hưởng đến phân phối lấy mẫu; nó chỉ làm phân phối nhọn hơn, nhưng vẫn là một phân phối
Nói chính xác hơn, bản thân temperature 0 không tồn tại. Về mặt toán học, khi temperature tiến gần 0, phân phối ngày càng nhọn hơn, mẫu có khả năng cao nhất gần như tiến tới vô hạn, còn các mẫu còn lại gần như tiến về 0
Trong triển khai thực tế,
temperature=0không dùng công thức áp dụng cho các giá trị khác 0, mà thường là một nhánh riêng trong câu lệnhifđể chọn mẫu phổ biến nhất nhằm tránh phép chia cho 0Tuy nhiên, do xử lý theo batch hoặc sai số dấu phẩy động tùy cách triển khai, bản thân phân phối xác suất thường thay đổi giữa các lần chạy, và kết quả là mẫu cũng thay đổi
Hai người xem cùng một hồ sơ có thể đi đến cùng một kết luận, và hai bệnh nhân có cùng triệu chứng cùng biểu hiện lâm sàng cũng có thể mắc hai bệnh khác nhau
Tôi không thấy thuyết phục lắm với cách giải thích rằng AI đời cũ chủ yếu chết vì chi phí duy trì knowledge base; tôi cho rằng cốt lõi đúng hơn là thiếu một hệ thống suy luận phổ quát để xử lý bất định
Cá nhân tôi thấy chuyện Spock cứ nói kiểu “Thuyền trưởng, xác suất sống sót trong nhiệm vụ này là 21%” giống một trò đùa lặp đi lặp lại. Theo góc nhìn Bayes, ngay cả phân phối xác suất cũng có phân phối xác suất, nên cách nói “khả năng sống sót trong nhiệm vụ này là β(5,1)” gần đúng hơn
Theo nghĩa đó, việc đưa hồ sơ vào cỗ máy ấy 100 lần rồi xem phân phối xác suất của điểm số cũng không phải chuyện quá kỳ lạ
[1] Dù vậy, tôi đúng là kiểu kẻ điên nằm trên giường dùng máy tính bảng để sắp xếp ảnh rồi cứ làm tiếp cho đến khi hệ thị giác hỏng luôn
Tuy nhiên, nếu là MoE thì đầu vào trùng lặp cũng phải giống nhau trong toàn bộ batch. Các phần tử lân cận trong batch có thể ảnh hưởng đến việc chọn chuyên gia
Kernel phải mang tính quyết định, và trong các mô hình suy luận không được có công tắc mức nỗ lực ở cấp hệ thống phản ứng với những thứ như tải toàn cụm
Tóm lại, trên hạ tầng cloud hiện có thì temperature 0 có lẽ cũng không quyết định, nhưng với suy luận ở edge thì có thể khá ổn định và mang tính quyết định
Về cách nói 0.1 mang tính quyết định hơn, tôi thấy đó là một tóm tắt khá hợp lý. Chẳng phải ở temperature 0.1 ta sẽ lấy mẫu theo hướng “câu trả lời của temperature 0” thường xuyên hơn nhiều so với temperature 0.9 sao?
Tôi đã nghe câu “muốn có kết quả nhất quán thì hãy đặt temperature về 0” không biết bao nhiêu lần
Có một vài lý do khiến điều đó có thể không đúng, nhưng trong trường hợp chạy mô hình local như tác giả đã làm, tôi nghĩ các lý do đó không áp dụng
Nếu cộng cả xu hướng AI “ưa thích” mã do AI tạo ra với các thiên kiến khác, cách làm này rất có khả năng là cực kỳ bất hợp pháp ở EU vì vi phạm luật chống phân biệt đối xử theo nhiều cách
Việc lọc ngẫu nhiên vì có quá nhiều CV nhìn chung có thể được xem là được phép. Nhưng nó phải thực sự ngẫu nhiên và độc lập với nội dung CV
Với AI, tính ngẫu nhiên không độc lập với việc đánh giá CV thực tế, nên không áp dụng được
Nói chung không thể bảo đảm AI không áp dụng thiên kiến có hệ thống, và trên thực tế cũng có nhiều dấu hiệu cho thấy khả năng đó là cao
Con người có thể được huấn luyện và chỉ thị bỏ qua thiên kiến. Dĩ nhiên cách đó cũng không vận hành ổn định, nhưng ít nhất nó tạo ra cấu trúc trong đó trách nhiệm về thiên kiến bất hợp pháp được chuyển cho nhân viên tuyển dụng đã làm trái chỉ thị
Ngược lại, khi dùng AI, người dùng phải chịu trách nhiệm bất kể đã chỉ thị gì. Về mặt kỹ thuật cũng có thể “cho thấy hoặc chứng minh” rằng một AI cụ thể bị thiên kiến mạnh trong một bối cảnh cụ thể. Với nhân viên con người thì về mặt kỹ thuật cũng có thể, nhưng trên thực tế gần như không khó
Rốt cuộc, rủi ro pháp lý chuyển từ mức “cá biệt và phần lớn có thể phủ nhận” sang phạm vi thiên kiến có thể được chứng minh một cách có hệ thống. Nói cách khác, nếu biết một công ty dùng AI trong tuyển dụng, mọi người có thể tấn công họ một cách có hệ thống về mặt pháp lý
Tức là chỉ xét về mặt toán học, nhiều khả năng điều này sẽ tương quan theo cách nào đó với chủng tộc, giới tính và các nhóm được bảo vệ khác ở Mỹ
Vì vậy ngay cả ở Mỹ, chỉ cần một vụ kiện tốt cũng có thể khiến nó trở thành bất hợp pháp. Không nhất thiết phải thắng kiện; chỉ cần trụ đủ lâu ở tòa cũng có thể khiến các công ty khác sợ dùng thứ này
Tôi không muốn ở vị thế bị đơn phải chứng minh bộ lọc AI của mình hoàn toàn tuân thủ mọi quy định tuyển dụng. Đó sẽ là một cơn ác mộng
[1]: https://gwern.net/everything
Rút CV thứ tư trong chồng hồ sơ rồi đề nghị việc làm cho người đó là một cách ra quyết định tuyển dụng ngu ngốc nhưng hoàn toàn công bằng
Nhưng AI rất giỏi nắm bắt thiên kiến, nên nếu bảo nó lọc CV, sẽ không ngạc nhiên nếu nó dựa vào những yếu tố tuyệt đối không nên dùng làm tiêu chí, như tên ứng viên
Có thể mọi CV ghi rằng từng sửa lỗi chính tả trong một dự án mã nguồn mở lớn đều được cho qua, còn CV chỉ ghi dự án cá nhân thì bị loại với xác suất 60%. Khi đó bạn sẽ mất nhiều ứng viên tốt hơn là ứng viên kém
Tôi đồng ý rằng vì nó hoạt động như một cỗ máy đánh bạc phi lý nên có thể có tác động phân biệt đối xử gián tiếp ngoài ý muốn. Nhưng có lẽ sẽ không dễ chứng minh rằng nó phân biệt đối xử vì “tôn giáo hoặc tín ngưỡng, khuyết tật, tuổi tác, xu hướng tính dục”. Có thể làm được, nhưng luật sư sẽ phải tốn nhiều công sức để chứng minh trước tòa
Phần thú vị hơn là EU AI Act. Phần này vẫn chưa có hiệu lực cho đến ngày 2/12/2027, nhưng các hệ thống AI dùng cho tuyển dụng hoặc lựa chọn thể nhân, đặc biệt là hệ thống dùng để đặt quảng cáo tuyển dụng có nhắm mục tiêu, phân tích·lọc hồ sơ ứng tuyển và đánh giá ứng viên, rõ ràng là hệ thống AI rủi ro cao
Điều đó không có nghĩa là bị cấm, nhưng về sau LLM có thể bị loại khỏi các trường hợp sử dụng AI rủi ro cao. Vì chúng có thể thuộc Article 6 không có ngoại lệ
Trong bối cảnh các tiêu chuẩn vẫn chưa được công bố, tôi hoàn toàn không biết làm thế nào để tuân thủ phần sau của Article 10 khi dùng LLM cho những việc như vậy
“(f) xem xét các thiên kiến có thể ảnh hưởng đến sức khỏe và an toàn của con người, tác động tiêu cực đến các quyền cơ bản, hoặc dẫn đến phân biệt đối xử bị cấm theo luật EU. Đặc biệt trong trường hợp đầu ra dữ liệu ảnh hưởng đến đầu vào của các tác vụ trong tương lai
(g) các biện pháp thích hợp để phát hiện, ngăn ngừa, giảm thiểu các thiên kiến có thể có đã được xác định theo (f)”
Hiện tại, tôi cho rằng với LLM thông thường thì về mặt kỹ thuật là bất khả thi, ngay cả khi nhà cung cấp mô hình hợp tác hoàn toàn. Các mô hình nhỏ hơn có thể có khả năng kiểm toán có ý nghĩa
EU AI Act rốt cuộc có thể loại bỏ mọi cách tiếp cận kiểu vibe coding “có dùng LLM nhưng không thật sự biết vì sao dùng” trong các trường hợp sử dụng rủi ro cao ở Annex III, và điều đó có vẻ hợp lý
https://eur-lex.europa.eu/eli/reg/2024/1689/oj/eng
“Chủ thể dữ liệu có quyền không bị đặt dưới một quyết định chỉ dựa trên xử lý tự động, bao gồm profiling, gây ra hiệu lực pháp lý đối với mình hoặc ảnh hưởng đáng kể tương tự đến mình”
Các ngoại lệ trong 22(2) khó có thể áp dụng. Khó lập luận rằng điều đó thực sự cần thiết, và trong bối cảnh tuyển dụng thì sự đồng ý hầu như không được coi là hợp lệ. Nếu có luật cụ thể của EU hoặc của quốc gia thành viên cho phép thì có thể, nhưng cần có cơ sở pháp lý riêng
Đến mức này thì có lẽ cứ áp dụng luôn câu đùa “tôi không muốn tuyển người xui xẻo, nên nhắm mắt vứt đi một nửa CV” cũng được
Cách này có lợi cho những sinh viên đủ năng lực nhưng xuất thân kém giàu có hơn, thay vì những sinh viên có điều kiện để tối ưu theo các tiêu chí đánh giá CV thủ công ngày càng phức tạp khi đó
Một chiến dịch có tổ chức kiểu “định chọn bác sĩ tương lai bằng trò may rủi sao?” đã diễn ra, và cuối cùng phương thức bốc thăm bị âm thầm bãi bỏ
Một nửa ứng viên còn lại đã dùng mất một phần may mắn trong vòng tuyển chọn này, nên trung bình họ sẽ kém may mắn hơn nửa đã bị vứt đi
Trong vài thập kỷ qua, đào tạo và giáo dục đã mở rộng mạnh, số người tìm việc tiếp tục tăng, nhưng việc tạo thêm việc làm không theo kịp tốc độ đó
Khi hàng chục ứng viên đổ vào một vị trí trống, nhà tuyển dụng vẫn có thể chọn được người đủ năng lực dù sàng lọc CV một cách tệ hại hoặc vứt đi một nửa
“Tôi có 65% khả năng bị loại. Cùng một CV hoàn toàn giống nhau, chỉ khác vận may” — kết quả này, từ góc nhìn của người từng vận hành pipeline tuyển dụng cho các vị trí kỹ thuật trong vài năm gần đây, thật ra là một con số tuyệt vời
Nói vậy tôi khách quan mà thấy không thích, nhưng đúng là sự thật
Xác suất đưa nhân sự kỹ thuật vào vòng tiếp theo mà không cần nỗ lực là 35% ư? Ngay cả khi thêm các câu hỏi sàng lọc chuyên biệt theo domain, tôi từng thấy hơn 100 ứng viên mỗi giờ. Vậy tức là mỗi giờ có 35 ứng viên “đã được sàng lọc”
Có lọc được ứng viên hợp lệ không? Có. Nhưng vẫn có một pool ứng viên lớn gấp 35 lần mức cần thiết chứ? Đáng tiếc là cũng đúng
Vì số lượng ứng viên quá nhiều, khi AI không can thiệp thì xác suất được chuyển sang vòng tiếp theo thực ra còn thấp hơn nhiều. Nếu bạn không nộp ngay lập tức, lại còn không dùng bot AI để nộp, thì trước bạn đã có hơn 50 người, và một tech lead mệt mỏi lúc nào đó phải đọc tới CV của bạn
Thưởng giới thiệu tồn tại là có lý do
Thông qua công nghệ mới nhất, chỉ cho 1% hồ sơ tốt nhất* đi tiếp
*theo chỉ số độc quyền, không công khai và không tất định của chúng tôi, có thể là
Math.randommà cũng có thể khôngMột cổng làm giảm lượng CV đổ vào chỉ hữu ích khi mức giảm đó có tương quan với chất lượng. Nếu không, nó chỉ khiến quy trình tuyển dụng kéo dài lê thê, hoặc cuối cùng buộc phải hạ tiêu chuẩn tuyển dụng một cách không cần thiết
Kiểu như “John Schmidt”, “John J. Schmidt”, “John J. J. Schmidt”, “John Jacob J. Schmidt”, “J. J. Jingleheimer Schmidt”
Nếu 50 người nộp đầu tiên đều là bot, tại sao lại đọc CV theo thứ tự nộp hồ sơ?
Điều đáng lo hơn là, nếu các hệ thống khác cũng hoạt động như ATS này, thì có vẻ chúng đang phán xét dựa trên các yếu tố có thể loại hàng loạt ứng viên khá ổn hoặc giỏi
Ví dụ, tổ hợp dự án cá nhân và đóng góp mã nguồn mở được gán 65 điểm. Điều đó có thể tốt nếu công nghệ là mối quan tâm duy nhất của bạn, và bạn không có gia đình, người phụ thuộc, hay công việc thứ hai hoặc thứ ba
Nhưng nếu bạn có dù chỉ một trong những thứ đó, cơ hội trông có vẻ bị bất lợi khủng khiếp
Tôi tự hỏi có bao nhiêu hệ thống như vậy được thiết kế để ưu ái người giàu, những người ngoài việc học đại học hoặc làm đúng một công việc trong ngành mong muốn thì không phải lo gì khác, và có thể ám ảnh với công nghệ gần như ở mức sở thích đặc biệt
Lấy chính tôi làm ví dụ, ngoài công ty tôi hầu như không làm dự án cá nhân. Toàn bộ kinh nghiệm lập trình thực tế của tôi là những việc tôi làm cho nhà tuyển dụng trong giờ làm
Sở thích của tôi nằm ở các lĩnh vực gần công nghệ như in 3D, phần cứng/Arduino, nhiếp ảnh, chứ không phải kiểu tạo thật nhiều dự án rồi đẩy lên GitHub
Tôi cũng tuyệt đối không làm một ứng dụng CRUD hay SaaS giả để khoe với nhà tuyển dụng tiềm năng. Đó là lãng phí thời gian
Tôi đã cố ý không tạo kiểu hiện diện trực tuyến đó. GitHub của tôi không có repository công khai, và tôi cũng không viết blog
Xu hướng này cũng lan sang mảng vận hành/quản trị hệ thống nơi tôi làm việc, thậm chí ở đó còn tệ hơn. Dĩ nhiên tôi không đưa cả đống script đặc thù theo môi trường lên GitHub của mình, vì sao phải làm thế? Với những người không làm ở bộ phận của tôi tại công ty hiện tại thì chúng chẳng có ý nghĩa gì
Từ tính tất định có một hiệu ứng ma thuật khiến các bài viết online mà nó chạm tới bị bóp méo
Hễ nghe thấy từ đó là gần như có thể đảm bảo câu chuyện sẽ đi sai hướng. Dù vậy, lần này nó thực sự đang nói về tính tất định theo nghĩa cùng đầu vào thì cùng đầu ra, chứ không phải những thứ linh tinh không liên quan
Tính tất định quan trọng đối với khả năng tái lập, nhưng trong trường hợp này bạn có thật sự muốn đầu ra được tái lập không? Làm cho đầu ra LLM trở nên tất định là việc tương đối nhỏ. Nếu dùng batch thì dùng kernel bất biến theo batch, đặt temperature về 0 — hoặc đừng làm vậy vì lấy mẫu ngẫu nhiên tồn tại là có lý do — tốt hơn nữa là cố định seed. Trong một số hệ thống, điều này đã có thể làm được
Nhưng việc đó không khiến kết quả hữu ích hơn. Nó chỉ che đi sự thật rằng agent thực sự không chắc chắn. Hãy nhìn khoảng điểm. Nó vẫn không dự đoán được gì cả, chỉ là mỗi lần điểm sẽ giống nhau. Bạn thật sự muốn điều đó sao?
Điều đang xảy ra ở đây là thông tin được cung cấp quá ít, chỉ đưa một CV gần như ở mức nhiễu, nhưng lại kỳ vọng một câu trả lời có hàm ý quá rộng
Đây là lỗi thiết kế cơ bản, bất kể có dùng LLM hay không. Mọi khảo sát, kỳ thi, luật lệ, hệ thống bỏ phiếu đều cực kỳ nhạy với cách đóng khung vì chúng vận hành trên quá ít thông tin. Chỉ là chúng, khác với thứ này, không tồn tại trong chân không
Thuật toán Las Vegas là không tất định nhưng chính xác 100%. Đổi lại, thời gian để đi tới đáp án đúng có thể khác nhau rất nhiều
Sai lầm ở đây không phải là dùng một hệ thống không tất định. Theo một nghĩa nào đó, sai lầm có thể là dùng quá ít. Đánh giá lại cùng một CV 5 lần để thấy phương sai điểm lớn là một tín hiệu hữu ích hơn so với chỉ đánh giá một lần
Chắc ai cũng từng nghe chuyện trong một giờ ngay trước bữa trưa, mức án thường nghiêm khắc hơn
Nếu muốn ngăn mọi người tối ưu hóa theo quy trình lọc, thì phải làm nó không tất định ở một mức độ nào đó
Ví dụ, thay vì cắt đúng ở top 100, hãy tăng theo hàm mũ khả năng ứng viên tốt hơn vượt qua bộ lọc
Như vậy giá trị của việc khai thác quy trình lọc theo kiểu Goodhart sẽ giảm đi. Xác suất gần như không tăng, và có rất nhiều nơi khác đáng dùng thời gian hơn
Nếu mô hình mặc định là
gemma3:4bthì đó là một mô hình rất nhỏCó lẽ không LLM nào là một trọng tài hoàn hảo và có thể lặp lại, nhưng cắm một mô hình 4B vào hệ thống kiểu này thì cũng gần giống như nối một bộ sinh số ngẫu nhiên vào vậy
Toàn bộ thử nghiệm có cảm giác như ai đó muốn làm một dự án ATS mã nguồn mở, rồi vibe coding để dựng ATS, sau đó chỉ chỉnh đến mức test pass là xong
Có lẽ vẫn có một cách phân tích CV hoạt động tốt với mô hình này. Nhưng không phải kiểu “này đồ sắt vụn, người này đã làm dự án gì?”
Cần trích xuất, sắp xếp, có lẽ là so sánh qua OCR và sắp xếp bổ sung, nhiều lượt phân tích bằng LLM theo từng tín hiệu, bộ phán định, v.v.
Không cái nào trong số đó nhất thiết phải là mô hình lớn. Dùng mô hình lớn thì có thể tốt hơn đôi chút, nhưng vì ngữ cảnh rất ít nên nếu dùng đúng, những mô hình như thế này vẫn có thể hoạt động tốt
Tôi đã tự chạy thử ATS và cũng có trải nghiệm kỳ quặc tương tự
Nó không tìm được hồ sơ GitHub của tôi nên chấm trong khoảng 70 điểm, rồi sau đó lại không thích vài thư viện Ruby nổi tiếng do tôi tạo ra
Sau khi chạy vài lần thì nó bắt đầu nhận diện tương đối đúng, nhưng tôi luôn bị trừ điểm ở phần học vấn chính quy
Những thứ kiểu này thật ghê tởm
Nó cũng không nhận ra chứng chỉ hay giải thưởng. Tôi đã thử áp dụng vài PR mà mọi người đề xuất để cải thiện (https://github.com/Zem-0/hiring-agent), và đúng là có ích, nhưng nhìn chung ATS này thiên lệch rất mạnh về phía những người có đóng góp mã nguồn mở GitHub quy mô lớn
Tôi luôn thấy ngạc nhiên khi các công ty công nghệ trả hơn 300 nghìn USD với lý do khó tìm kỹ sư giỏi, nhưng các recruiter thì lại làm việc mà không có hỗ trợ, và tiêu chí về “ứng viên tốt” cũng hoàn toàn khác nhau
ATS đẩy hơn 50% CV vào hố đen vì các heuristic lọc rác rưởi, đội tuyển dụng chọn ATS vì những lý do như tích hợp Google Gmail, còn công nghệ lọc của ATS đó thì chưa từng được bất kỳ ai trong đội kỹ thuật hay đội dữ liệu xem xét
Tôi thử với CV của mình thì somehow lại được điểm thưởng GSoC
BONUS POINTS: 5.0------------------------------Google Summer of Code (GSoC) participation: +5Nhưng tôi chưa từng tham gia GSoC, và cũng không hề ghi trong CV là mình đã tham gia
Đây là ảo giác đã biết https://github.com/interviewstreet/hiring-agent/issues/240