03 thg 12, 2025·8 phút
Andrej Karpathy — bài học về học sâu để triển khai AI
Bài học từ Andrej Karpathy về học sâu: cách biến mạng nơ-ron thành sản phẩm với giả định rõ ràng, chỉ số đo lường và quy trình lấy kỹ thuật làm trung tâm.
Bài học từ Andrej Karpathy về học sâu: cách biến mạng nơ-ron thành sản phẩm với giả định rõ ràng, chỉ số đo lường và quy trình lấy kỹ thuật làm trung tâm.
Một bản demo học sâu có thể trông như phép màu. Một model viết được đoạn văn sạch, nhận diện đối tượng, hoặc trả lời câu hỏi hóc búa. Rồi bạn cố biến bản demo đó thành một nút mà người ta nhấn mỗi ngày, và mọi thứ trở nên lộn xộn. Cùng một prompt hành xử khác đi, các edge case chất đống, và khoảnh khắc "wow" biến thành ticket hỗ trợ.
Chính khoảng cách đó khiến công việc của Andrej Karpathy được nhiều người xây dựng đón nhận. Ông thúc đẩy tư duy rằng mạng nơ-ron không phải đồ vật huyền bí. Chúng là hệ thống bạn thiết kế, kiểm thử và duy trì. Model không vô dụng; sản phẩm chỉ yêu cầu tính nhất quán.
Khi các đội nói họ muốn AI “thực dụng”, thường họ nhắm tới bốn điều:
Các đội gặp khó vì học sâu là xác suất và nhạy với bối cảnh, trong khi sản phẩm bị đánh giá theo độ tin cậy. Một chatbot trả lời 80% câu hỏi tốt vẫn có thể bị coi là hỏng nếu 20% còn lại tự tin, sai và khó phát hiện.
Lấy ví dụ một trợ lý “tự trả lời” cho hỗ trợ khách hàng. Nó trông hay trên vài ticket chọn lọc. Trong môi trường production, khách hàng viết tiếng lóng, gửi ảnh chụp màn hình, trộn ngôn ngữ, hoặc hỏi về các trường hợp chính sách. Lúc đó bạn cần rào chắn, hành vi từ chối rõ ràng, và cách đo xem bản nháp có thực sự giúp agent hay không.
Nhiều người lần đầu biết tới Karpathy qua các ví dụ thực tế, không phải toán học trừu tượng. Ngay cả các dự án ban đầu cũng nêu một điểm đơn giản: mạng nơ-ron trở nên hữu dụng khi bạn đối xử với chúng như phần mềm có thể kiểm thử, phá vỡ và sửa chữa.
Thay vì dừng lại ở “model chạy được”, trọng tâm chuyển sang làm cho nó chạy trên dữ liệu lộn xộn, thực tế. Điều đó bao gồm pipeline dữ liệu, các lần huấn luyện thất bại vì lý do nhàm chán, và kết quả thay đổi khi bạn chỉnh một thứ nhỏ. Trong thế giới đó, học sâu bớt huyền bí và bắt đầu giống kỹ thuật.
Cách tiếp cận theo kiểu Karpathy ít nói về thủ thuật bí mật và nhiều hơn về thói quen:
Nền tảng đó quan trọng sau này vì AI sản phẩm về cơ bản vẫn cùng trò chơi, chỉ có mức độ rủi ro cao hơn. Nếu bạn không xây nghề sớm (đầu vào rõ ràng, đầu ra rõ ràng, chạy lặp lại được), việc đưa tính năng AI lên sản phẩm trở thành phỏng đoán.
Một phần lớn tác động của Karpathy là ông đối xử với mạng nơ-ron như thứ bạn có thể lý giải. Giải thích rõ ràng biến công việc từ “hệ tín ngưỡng” thành kỹ thuật.
Điều đó quan trọng vì người tạo prototype ban đầu thường không phải người duy trì nó. Nếu bạn không giải thích được model đang làm gì, có khả năng bạn không thể debug nó và chắc chắn không thể hỗ trợ nó trên production.
Ép sự rõ ràng ngay từ đầu. Trước khi xây tính năng, ghi ra model thấy gì, xuất gì, và bạn sẽ biết nó tốt hơn bằng cách nào. Phần lớn dự án AI thất bại vì những điều cơ bản, không phải vì toán học.
Một checklist ngắn mang lại hiệu quả sau này:
Suy nghĩ rõ ràng hiện lên dưới dạng thí nghiệm kỷ luật: một script có thể chạy lại, bộ đánh giá cố định, prompt được version, và các chỉ số được ghi log. Baseline giữ bạn trung thực và làm tiến trình hiển thị được.
Prototype chứng minh ý tưởng có thể hoạt động. Tính năng đã phát hành chứng minh nó hoạt động cho người thật, trong điều kiện lộn xộn, mỗi ngày. Khoảng cách này là nơi nhiều dự án AI gặp bế tắc.
Một demo nghiên cứu có thể chậm, tốn kém và mong manh miễn là nó chứng minh khả năng. Production đảo ưu tiên. Hệ thống phải dự đoán được, quan sát được và an toàn ngay cả khi đầu vào lạ, người dùng thiếu kiên nhẫn và lưu lượng tăng đột biến.
Trong production, độ trễ là một tính năng. Nếu model mất 8 giây, người dùng bỏ chạy hoặc nhấn đi nhấn lại, và bạn trả tiền cho mỗi lần thử lại. Chi phí cũng trở thành quyết định sản phẩm, vì một thay đổi nhỏ trong prompt có thể nhân đôi hoá đơn của bạn.
Giám sát là không thể thương lượng. Bạn cần biết không chỉ dịch vụ còn chạy mà còn là đầu ra có duy trì chất lượng chấp nhận được theo thời gian hay không. Dịch chuyển dữ liệu, hành vi người dùng mới và thay đổi upstream có thể lặng lẽ phá vỡ hiệu năng mà không ném lỗi.
Kiểm tra an toàn và chính sách chuyển từ “nên có” thành bắt buộc. Bạn phải xử lý yêu cầu có hại, dữ liệu riêng tư và edge case theo cách nhất quán và có thể kiểm thử.
Các đội thường cuối cùng trả lời cùng một tập câu hỏi:
Prototype có thể do một người làm. Việc triển khai thường cần product định nghĩa thành công, data để xác thực đầu vào và bộ đánh giá, infra để chạy ổn định, và QA để kiểm thử các chế độ lỗi.
“Chạy được trên máy tôi” không phải tiêu chí phát hành. Phát hành có nghĩa là nó hoạt động cho người dùng dưới tải, có logging, guardrails và cách đo xem nó đang giúp hay gây hại.
Ảnh hưởng của Karpathy là mang tính văn hoá, không chỉ kỹ thuật. Ông đối xử với mạng nơ-ron như thứ bạn có thể xây, kiểm thử và cải thiện với kỷ luật giống như bất kỳ hệ thống kỹ thuật nào.
Nó bắt đầu bằng việc ghi giả định trước khi viết code. Nếu bạn không thể nói rõ điều gì phải đúng để tính năng hoạt động, bạn sẽ không thể debug sau này. Ví dụ:
Đó là những phát biểu có thể kiểm thử.
Baseline đến tiếp theo. Baseline là thứ đơn giản nhất có thể hoạt động, và nó là phép kiểm thực tế. Có thể là rules, template tìm kiếm, hoặc thậm chí “không làm gì” kèm UI tốt. Baseline mạnh bảo vệ bạn khỏi việc mất tuần cho model cầu kỳ mà không thắng được cái đơn giản.
Instrumentation khiến việc lặp trở nên khả thi. Nếu bạn chỉ nhìn demo, bạn đang lái theo cảm giác. Với nhiều tính năng AI, một tập nhỏ các con số đã cho bạn biết liệu bạn đang cải thiện hay không:
Rồi lặp trong vòng khép kín. Thay đổi một thứ, so sánh với baseline, và ghi lại đơn giản những gì bạn thử và gì thay đổi. Nếu tiến triển thật, nó sẽ hiện lên trên đồ thị.
Việc đưa AI vào sản phẩm hiệu quả nhất khi bạn đối xử với nó như kỹ thuật: mục tiêu rõ ràng, baseline, và vòng phản hồi nhanh.
Diễn đạt vấn đề người dùng trong một câu. Viết như một than phiền thật: “Agent hỗ trợ tốn quá nhiều thời gian soạn trả lời cho câu hỏi thường gặp.” Nếu không nói được trong một câu, tính năng có thể quá lớn.
Chọn kết quả có thể đo lường. Chọn một con số theo dõi hàng tuần. Ví dụ tốt: thời gian tiết kiệm cho mỗi tác vụ, tỷ lệ chấp nhận bản nháp, giảm sửa đổi, hoặc tỷ lệ chuyển hướng ticket. Quyết định “đủ tốt” trước khi xây.
Định nghĩa baseline bạn phải vượt. So sánh với template đơn giản, approach rules, hoặc “chỉ con người”. Nếu AI không vượt baseline trên chỉ số đã chọn, đừng phát hành.
Thiết kế thử nghiệm nhỏ với dữ liệu đại diện. Thu thập ví dụ khớp thực tế, bao gồm các trường hợp lộn xộn. Giữ một bộ eval nhỏ mà bạn không “đào” bằng mắt mỗi ngày. Ghi rõ gì là pass và gì là fail.
Phát hành sau flag, thu thập phản hồi và lặp. Bắt đầu với nhóm nội bộ nhỏ hoặc một % người dùng. Ghi lại đầu vào, đầu ra và xem nó có giúp không. Sửa mode lỗi hàng đầu trước, rồi chạy lại cùng bộ test để thấy tiến triển thực.
Một mẫu thực dụng cho công cụ soạn thảo: đo “giây đến khi gửi” và “% bản nháp được dùng với sửa ít”.
Nhiều thất bại tính năng AI không phải do model. Chúng là thất bại “chúng ta chưa đồng ý thế nào là thành công”. Nếu muốn học sâu cảm thấy thực dụng, hãy viết giả định và phép đo trước khi viết thêm prompt hay huấn luyện model.
Bắt đầu với giả định có thể làm hỏng tính năng trong sử dụng thực. Thông thường về dữ liệu và con người: văn bản đầu vào là một ngôn ngữ, người dùng chỉ một intent mỗi lần, UI cung cấp đủ ngữ cảnh, edge case hiếm, và mô hình hôm qua vẫn còn đúng tháng sau (drift). Cũng hãy ghi những gì bạn chưa xử lý, như mỉa mai, tư vấn pháp lý, hoặc tài liệu dài.
Biến mỗi giả định thành thứ có thể kiểm thử. Định dạng hữu dụng: “Khi X, hệ thống phải làm Y, và chúng ta kiểm chứng bằng Z.” Giữ cụ thể.
Năm thứ đáng ghi trên một trang:
Giữ offline và online tách biệt có chủ ý. Offline cho biết hệ thống học task, online cho biết tính năng có giúp người thật không. Model có thể điểm cao offline mà vẫn gây khó chịu cho người dùng vì nó chậm, quá tự tin, hoặc sai ở những trường hợp quan trọng.
Định nghĩa “đủ tốt” bằng ngưỡng và hậu quả. Ví dụ: “Offline: >= 85% đúng trên bộ eval; Online: 30% bản nháp được chấp nhận với sửa ít.” Nếu không đạt ngưỡng, quyết định trước: giữ sau flag, giảm rollout, chuyển các ca độ tin thấp về template, hoặc dừng và thu thêm dữ liệu.
Các đội thường coi tính năng AI như chỉnh UI bình thường: phát hành, xem sao, điều chỉnh sau. Cách làm đó vỡ nhanh vì hành vi model có thể thay đổi với prompt, drift và cấu hình nhỏ. Kết quả là nhiều công sức mà không có bằng chứng rõ ràng rằng nó giúp.
Quy tắc thực dụng: nếu bạn không thể nêu baseline và phép đo, bạn chưa sẵn sàng phát hành.
Các mode lỗi phổ biến nhất:
Ví dụ cụ thể: bạn thêm AI để soạn trả lời hỗ trợ. Nếu chỉ theo dõi like, bạn có thể bỏ qua chuyện agent mất nhiều thời gian hơn để xem lại bản nháp, hoặc trả lời đúng nhưng quá dài. Chỉ số tốt hơn là “% gửi với sửa ít” và “thời gian trung vị để gửi”.
Đối xử ngày phát hành như bàn giao kỹ thuật, không phải demo. Bạn phải giải thích được bằng ngôn ngữ đơn giản tính năng làm gì, làm sao biết nó hoạt động, và bạn làm gì khi nó hỏng.
Trước khi ship, đảm bảo bạn có:
Cũng giữ một bộ đánh giá offline trông như lưu lượng thực, bao gồm edge case và ổn định đủ để so sánh theo tuần. Khi bạn thay prompt, model hoặc cách làm sạch dữ liệu, chạy lại cùng bộ đó và xem thay đổi.
Một đội support muốn trợ lý soạn câu trả lời trong giao diện ticket. Agent không gửi tự động. Nó gợi ý bản nháp, làm nổi bật các thông tin chính nó dùng, và yêu cầu agent review và chỉnh trước khi gửi. Lựa chọn này giữ rủi ro thấp trong khi bạn học.
Bắt đầu bằng cách quyết định “tốt hơn” nghĩa là gì bằng con số. Chọn các kết quả có thể đo ngay từ ngày một bằng log sẵn có:
Trước khi cho model vào, đặt baseline nhàm chán nhưng thực tế: templates lưu sẵn cộng lớp rules đơn giản (phát hiện refund vs giao hàng vs reset mật khẩu, rồi điền template phù hợp). Nếu AI không thắng baseline đó, chưa sẵn sàng.
Chạy pilot nhỏ. Làm opt-in cho vài agent, giới hạn một loại ticket trước (ví dụ: trạng thái đơn hàng). Thêm phản hồi nhanh trên mỗi bản nháp: “hữu ích” hoặc “không hữu ích”, kèm lý do ngắn. Ghi lại agent thay đổi gì, không chỉ họ có nhấn nút hay không.
Định nghĩa tiêu chí ship trước để không đoán mò sau. Ví dụ: thời gian xử lý cải thiện 10% mà không tăng leo thang hay mở lại, và agent chấp nhận bản nháp với sửa ít ít nhất 30% thời gian.
Cũng quyết định trigger rollback: tăng đột biến leo thang, giảm điểm hài lòng, hoặc sai sót chính sách lặp lại.
Chọn một ý tưởng AI bạn có thể triển khai trong 2–4 tuần. Giữ nó đủ nhỏ để đo lường, debug và rollback mà không ầm ĩ. Mục tiêu không phải chứng minh model thông minh. Mục tiêu là làm đầu ra người dùng tốt hơn một cách đáng tin so với hiện tại.
Biến ý tưởng thành một trang kế hoạch: tính năng làm gì, không làm gì, và làm sao biết nó hiệu quả. Bao gồm baseline và chỉ số chính bạn sẽ theo dõi.
Nếu muốn chạy nhanh về triển khai, Koder.ai (koder.ai) được xây xung quanh việc tạo app web, server và di động qua giao diện chat, với tính năng như snapshots/rollback và xuất mã nguồn khi bạn cần kiểm soát sâu hơn.
Thói quen cần giữ đơn giản: mỗi thay đổi AI phải kèm một giả định viết ra và một đầu ra có thể đo lường. Đó là cách học sâu bớt phép màu và trở thành công việc bạn có thể phát hành.
Bởi vì các bản demo thường được xây trên dữ liệu sạch, chọn lọc và được đánh giá bằng cảm nhận, trong khi sản phẩm phải xử lý đầu vào lộn xộn, áp lực từ người dùng và việc sử dụng lặp lại.
Để thu hẹp khoảng cách, hãy định nghĩa hợp đồng đầu vào/đầu ra, đo chất lượng trên dữ liệu đại diện và thiết kế các phương án dự phòng cho timeout và trường hợp độ tin cậy thấp.
Chọn một chỉ số gắn với giá trị người dùng mà bạn có thể theo dõi hàng tuần. Một số mặc định tốt:
Quyết định mục tiêu “đủ tốt” trước khi tinh chỉnh prompt hoặc model.
Dùng phương án đơn giản nhất có thể thực tế triển khai:
Nếu AI không thắng baseline trên chỉ số chính (mà không phá vỡ độ trễ/chi phí), chưa nên triển khai.
Giữ một bộ nhỏ trông giống lưu lượng thực, không chỉ các ví dụ tốt nhất.
Quy tắc thực tế:
Điều này làm cho tiến triển hiển thị được và giảm regress vô ý.
Bắt đầu với các guardrail dễ dự đoán và kiểm thử được:
Xem guardrail như yêu cầu sản phẩm, không phải tinh chỉnh tuỳ ý.
Giám sát cả sức khỏe hệ thống và chất lượng đầu ra:
Cũng hãy ghi lại đầu vào/đầu ra (với kiểm soát quyền riêng tư) để tái tạo lỗi và sửa các pattern lỗi hàng đầu.
Đặt ngân sách tối đa trước: mục tiêu độ trễ và chi phí tối đa mỗi yêu cầu.
Rồi giảm chi tiêu mà không đoán mò:
Một cải thiện nhỏ về chất lượng hiếm khi xứng đáng với chi phí hoặc độ chậm lớn trong sản xuất.
Triển khai sau flag và rollout dần dần.
Kế hoạch rollout thực tế:
Rollback không phải là thất bại; nó là một phần để làm cho AI dễ duy trì hơn.
Các vai trò tối thiểu cần (dù một người có thể kiêm nhiều việc):
Việc triển khai thuận lợi khi mọi người đồng thuận về chỉ số, baseline và kế hoạch rollback.
Dùng khi bạn muốn đi từ ý tưởng đến ứng dụng hoạt động nhanh, nhưng vẫn giữ kỷ luật kỹ thuật.
Quy trình thực tế:
Công cụ giúp bạn lặp nhanh hơn; bạn vẫn cần giả định rõ ràng và kết quả có thể đo lường.