Chương 32. Pilot không phải màn trình diễn

Trong EdTech, pilot thường bắt đầu bằng một bức tranh đẹp. Một trường được chọn vì lãnh đạo cởi mở. Một nhóm giáo viên được chọn vì nhiệt tình. Một lớp được chọn vì kỷ luật tốt. Vendor cử đội hỗ trợ sát sao. Thiết bị được kiểm tra trước. Tài khoản được tạo sẵn. Buổi học đầu có người quay phim. Học sinh hào hứng vì mới. Giáo viên được tập huấn riêng. Lãnh đạo đến dự giờ. Sau vài tuần, báo cáo nói: “Pilot thành công.”

Có thể pilot ấy thành công thật. Nhưng cũng có thể nó chỉ thành công như một sân khấu. Trong sân khấu, ánh sáng được chỉnh, diễn viên được chọn, cảnh khó được cắt, sự cố được xử lý sau cánh gà, và khán giả thấy một phiên bản đã được dàn dựng. Trường học thật không giống vậy. Khi mở rộng, sản phẩm sẽ gặp giáo viên không tình nguyện, lớp đông, mạng yếu, thiết bị hỏng, học sinh quên mật khẩu, phụ huynh không đọc tin nhắn, dữ liệu sai, lịch thi chen vào, người phụ trách chuyển việc, ngân sách hỗ trợ giảm, và vendor không thể cử đội đến từng trường. Nếu pilot không chuẩn bị để gặp những điều đó, nó không kiểm tra sản phẩm. Nó chỉ kiểm tra khả năng tạo một câu chuyện đẹp.

Mâu thuẫn của chương này là: pilot cần điều kiện đủ tốt để thử một ý tưởng một cách công bằng, nhưng nếu điều kiện quá đẹp thì pilot lại nói dối về thực tế. Nếu chọn bối cảnh quá hỗn loạn, sản phẩm chưa kịp lộ giá trị đã bị môi trường bóp nghẹt. Nếu chọn bối cảnh quá lý tưởng, sản phẩm có vẻ tốt hơn bản chất. Một pilot nghiêm túc phải đi giữa hai cực ấy: đủ hỗ trợ để học được điều cần học, đủ thật để thất bại có ý nghĩa.

Vì vậy, câu hỏi không phải “pilot có thành công không?”. Câu hỏi đúng hơn là: “Pilot đã làm chúng ta hiểu điều gì trước khi quyết định lớn hơn?” Nếu sau pilot, tổ chức chỉ biết rằng vài giáo viên tốt dùng được sản phẩm khi có đội vendor đứng cạnh, thì chưa biết nhiều. Nếu sau pilot, tổ chức biết ai dùng, ai không dùng, vì sao, cần hỗ trợ gì, tác động học tập ra sao, workload tăng hay giảm, rào cản dữ liệu nằm ở đâu, chi phí hỗ trợ thế nào, điều gì sẽ vỡ khi scale, và khi nào nên dừng, thì pilot đã làm đúng việc của nó.

1. Pilot là nơi học, không phải nơi chứng minh

Một pilot tốt không bắt đầu bằng niềm tin rằng sản phẩm sẽ thắng. Nó bắt đầu bằng sự không chắc chắn có cấu trúc. Ta nghĩ công cụ này có thể giải một vấn đề cụ thể, qua một cơ chế cụ thể, trong một bối cảnh cụ thể, với một nhóm người dùng cụ thể. Nhưng ta chưa biết. Pilot là cách biến “chưa biết” thành những điều biết được, trước khi hệ thống trả giá quá lớn.

Vấn đề là nhiều pilot EdTech được thiết kế như lễ xác nhận. Quyết định mua đã gần như xong, pilot chỉ cần tạo bằng chứng mềm để hợp thức hóa. Vendor cần logo trường. Trường cần câu chuyện đổi mới. Nhà tài trợ cần ảnh tác động. Lãnh đạo cần báo cáo tiến độ. Không ai thật sự muốn pilot thất bại. Khi đó, pilot trở thành sân khấu: dữ liệu được chọn, lỗi được giải thích, người không dùng bị bỏ qua, giáo viên mệt không dám nói, học sinh thích vì mới được xem là learning, và kết quả được viết như thể mở rộng là bước tiếp theo tự nhiên.

Pilot đúng nghĩa phải có quyền làm người ta đổi ý. Nó có thể dẫn đến scale, nhưng cũng có thể dẫn đến sửa, thu hẹp, đổi nhóm người dùng, đổi mô hình triển khai, hoặc dừng. Nếu ngay từ đầu không có khả năng dừng, đó không phải pilot. Đó là truyền thông trước triển khai. Một tổ chức càng nghiêm túc với đổi mới càng phải bảo vệ quyền thất bại sớm, vì thất bại nhỏ là cách tránh thất bại lớn.

EEF trong A School’s Guide to Implementation nhấn mạnh rằng một ý tưởng giáo dục nghe hay chỉ có ý nghĩa khi nó biểu hiện trong công việc hằng ngày của trường; implementation cần chú ý hành vi, bối cảnh và quy trình có cấu trúc.[^eef-implementation] Đây là tinh thần pilot nên theo. Pilot không phải chỗ cho ý tưởng tỏa sáng trong điều kiện sạch. Pilot là chỗ xem ý tưởng sống thế nào trong lịch thật, lớp thật, giáo viên thật, thiết bị thật, và áp lực thật.

2. Pilot chọn toàn người giỏi sẽ trả lời câu hỏi quá dễ

Một trường thường muốn chọn giáo viên tốt nhất cho pilot. Điều này dễ hiểu. Nếu sản phẩm mới, cần người có động lực, chịu khó thử, phản hồi rõ. Một giáo viên giỏi có thể giúp phát hiện giá trị thật của công cụ trước khi lỗi triển khai giết nó. Nếu đưa sản phẩm chưa hoàn thiện vào tay người chưa sẵn sàng, tổ chức có thể kết luận quá sớm rằng sản phẩm vô dụng.

Nhưng nếu pilot chỉ có giáo viên giỏi, câu hỏi được trả lời là: sản phẩm có hoạt động với người dùng tốt nhất không? Câu hỏi đó hữu ích, nhưng không đủ. Scale không xảy ra với người dùng tốt nhất. Scale xảy ra với người dùng bình thường, người bận, người hoài nghi, người ít tự tin công nghệ, người dạy lớp đông, người không có thời gian gọi vendor, người chỉ đọc hướng dẫn nếu hướng dẫn rất rõ. Một sản phẩm chỉ sống nhờ champion teacher chưa phải sản phẩm sẵn sàng mở rộng. Nó là sản phẩm cần anh hùng.

Tương tự, nếu pilot chọn lớp dễ, trường giàu, mạng tốt, học sinh có thiết bị, phụ huynh hỗ trợ, và lịch học linh hoạt, kết quả sẽ trả lời một câu hỏi hẹp: trong điều kiện thuận lợi, công cụ có thể chạy không? Nhưng hệ thống giáo dục hiếm khi thiếu giải pháp cho nơi thuận lợi. Vấn đề là nơi khó. Một pilot công bằng phải cố ý đưa vào vài bối cảnh biên: lớp đông, mạng yếu, học sinh nền thấp, phụ huynh ít hỗ trợ, giáo viên trung bình, thiết bị dùng chung. Không phải để làm sản phẩm thất bại, mà để thấy điều kiện tối thiểu để nó thành công.

World Bank từng mô tả “remote learning paradox” trong đại dịch: nhiều hệ thống chọn mô hình học từ xa không phù hợp với access và capabilities của đa số giáo viên, học sinh, dẫn đến take-up thấp và bất bình đẳng tăng.[^worldbank-remote] Đây chính là bài học cho pilot EdTech. Nếu pilot chỉ kiểm tra nhóm có access và capabilities cao, scale sẽ gặp nghịch lý tương tự: chính nhóm cần nhất lại ít dùng được nhất.

3. Baseline không phải thủ tục

Không có baseline, pilot rất dễ tự lừa mình. Sau khi dùng app, học sinh làm nhiều bài hơn. Nhưng trước đó các em làm bao nhiêu? Sau khi có dashboard, giáo viên nói hiểu lớp hơn. Nhưng trước đó họ đã có cách hiểu nào? Sau khi gửi SMS, phụ huynh phản hồi nhiều hơn. Nhưng trước đó phản hồi qua kênh nào? Sau khi AI hỗ trợ, giáo viên soạn bài nhanh hơn. Nhưng trước đó mất bao lâu, chất lượng bài thế nào, và thời gian tiết kiệm được dùng vào đâu?

Baseline không chỉ là điểm kiểm tra đầu kỳ. Nó là bức ảnh ban đầu của vấn đề. Nếu vấn đề là học sinh yếu toán, baseline cần biết mức học thật của học sinh, phân bố năng lực, nhóm nào yếu, nguyên nhân nào có thể. Nếu vấn đề là giáo viên quá tải, baseline cần workload hiện tại. Nếu vấn đề là phụ huynh ít tham gia, baseline cần kênh liên lạc, mức hiểu, rào cản ngôn ngữ, thời gian. Nếu vấn đề là dropout, baseline cần attendance, risk factors, dữ liệu thiếu, quy trình can thiệp hiện có.

U.S. Department of Education trong hướng dẫn dùng bằng chứng nhấn mạnh quy trình continuous improvement gồm xác định nhu cầu địa phương, chọn can thiệp phù hợp, lập kế hoạch, triển khai, rồi xem xét và phản tư kết quả.[^used-evidence] Baseline chính là phần “xác định nhu cầu” được làm nghiêm túc. Nếu không biết điểm xuất phát, mọi thay đổi sau pilot đều dễ bị diễn giải theo ý người muốn thắng.

Baseline cũng giúp tránh mua giải pháp sai nguyên nhân. Một trường có thể nghĩ học sinh không làm bài vì thiếu app nhắc nhở, nhưng baseline cho thấy các em không hiểu bài nền. Một chính phủ có thể nghĩ giáo viên cần dashboard, nhưng baseline cho thấy dữ liệu hiện có sai và giáo viên không có thời gian can thiệp. Một vendor có thể nghĩ AI tutor sẽ tăng tự học, nhưng baseline cho thấy học sinh không có thiết bị riêng. Pilot không có baseline thường chỉ kiểm tra một giải pháp đã được thích từ trước.

4. Giả thuyết phải cụ thể đến mức có thể sai

Một pilot không nên bắt đầu bằng câu “chúng ta sẽ xem công nghệ này có giúp học tập không”. Câu đó quá rộng. Pilot cần giả thuyết cụ thể: công cụ này sẽ giúp học sinh lớp 6 yếu phân số tăng khả năng giải bài qua việc luyện đúng trình độ 30 phút mỗi tuần, với phản hồi tức thì và giáo viên xem báo cáo lỗi để dạy lại mỗi thứ Sáu. Hoặc: hệ thống nhắn tin này sẽ giảm vắng học bằng cách gửi cảnh báo sớm cho phụ huynh trong ngôn ngữ dễ hiểu, kèm hành động cụ thể và kênh liên hệ giáo viên. Hoặc: AI này sẽ giảm thời gian giáo viên tạo câu hỏi ôn tập mà không giảm chất lượng so với câu hỏi tự viết.

Giả thuyết cụ thể buộc ta nói rõ cơ chế. Nếu học sinh tiến bộ, vì sao? Vì thêm thời gian luyện tập, vì bài đúng trình độ, vì feedback nhanh, vì giáo viên can thiệp tốt hơn, hay vì học sinh hào hứng do mới? Nếu phụ huynh phản hồi, vì tin nhắn đúng lúc, ngôn ngữ dễ hiểu, hay vì giáo viên gọi điện sau đó? Nếu giáo viên tiết kiệm thời gian, vì AI tạo bản nháp tốt, hay vì họ chấp nhận chất lượng thấp hơn? Không có giả thuyết cơ chế, pilot có thể thấy kết quả nhưng không biết cách scale.

Giả thuyết cũng phải có điều kiện sai. Nếu sau tám tuần, học sinh dùng đủ liều nhưng không cải thiện ở kỹ năng mục tiêu, giả thuyết yếu. Nếu học sinh không dùng đủ liều vì login quá khó, vấn đề là triển khai. Nếu giáo viên không xem dashboard vì báo cáo không hành động được, cơ chế “data-driven teaching” chưa hoạt động. Nếu phụ huynh mở tin nhắn nhưng không thay đổi hành vi, thông điệp có thể chưa đúng. Mỗi loại thất bại dạy điều khác nhau.

EdTech Hub mô tả sandbox như một cách tạo real-time evidence qua các thử nghiệm nhanh, lặp lại trong điều kiện thực, nhằm đẩy hiệu quả lên, giảm chi phí và hiểu cách triển khai ở quy mô.[^edtechhub-sandbox] Tinh thần sandbox rất hợp với giả thuyết cụ thể: không thử để thắng một lần, mà thử để học nhanh hơn và làm can thiệp robust hơn.

5. Failure criteria là dấu hiệu trưởng thành

Nhiều pilot có success criteria nhưng không có failure criteria. Thành công là học sinh thích, giáo viên dùng, điểm tăng, hệ thống chạy, lãnh đạo hài lòng. Nhưng thất bại là gì? Tỷ lệ đăng nhập dưới bao nhiêu thì dừng? Workload tăng bao nhiêu thì không chấp nhận? Nhóm học sinh nghèo dùng thấp hơn bao nhiêu thì phải sửa? Chi phí hỗ trợ mỗi trường cao hơn bao nhiêu thì không scale? Sự cố dữ liệu nào là nghiêm trọng? Không cải thiện outcome nào thì kết luận không đủ giá trị?

Không có failure criteria, mọi kết quả đều có thể được xoay thành tích cực. Học sinh dùng ít? Cần truyền thông thêm. Giáo viên không dùng? Cần tập huấn thêm. Điểm không tăng? Cần thời gian thêm. Workload tăng? Giai đoạn đầu nào cũng khó. Nhóm yếu bị bỏ lại? Cần phiên bản sau. Mọi lời giải thích có thể đúng, nhưng nếu không có ngưỡng dừng, pilot không học được gì ngoài khả năng biện minh.

Failure criteria không phải thái độ bi quan. Nó là sự tử tế với hệ thống. Nó bảo vệ giáo viên khỏi phải dùng mãi công cụ không phù hợp. Nó bảo vệ học sinh khỏi bị đưa vào thử nghiệm kéo dài. Nó bảo vệ ngân sách khỏi chi phí chìm. Nó bảo vệ vendor nghiêm túc khỏi kỳ vọng mơ hồ. Nó giúp tất cả bên biết từ đầu: chúng ta không tìm bằng chứng để thắng bằng mọi giá; chúng ta tìm sự thật đủ tốt để quyết định.

Một pilot tốt nên có ba loại tiêu chí dừng. Thứ nhất là learning failure: công cụ không cải thiện outcome mục tiêu dù được dùng đủ. Thứ hai là implementation failure: công cụ không thể được dùng đủ trong điều kiện thật với hỗ trợ hợp lý. Thứ ba là harm or burden failure: công cụ tạo rủi ro, workload, chi phí, bất bình đẳng hoặc sự cố dữ liệu vượt ngưỡng chấp nhận. Có thể sửa sau thất bại, nhưng phải gọi đúng tên thất bại.

6. Người không dùng là dữ liệu quý nhất

Pilot thường thích kể về người dùng tích cực. Nhưng người không dùng mới thường nói sự thật về scale. Ai không đăng nhập? Ai đăng nhập một lần rồi bỏ? Ai không hoàn thành onboarding? Ai không dùng vì quên mật khẩu, vì thiết bị yếu, vì thấy không liên quan, vì giáo viên không nhắc, vì phụ huynh không biết, vì ngôn ngữ khó, vì app nặng, vì lịch học không có chỗ, vì sợ bị chấm điểm? Nếu pilot chỉ phân tích người dùng còn lại, nó đang học từ nhóm đã vượt qua rào cản.

Dữ liệu người không dùng đặc biệt quan trọng cho equity. Một sản phẩm có thể tạo tác động tốt với học sinh dùng đủ, nhưng nếu học sinh nghèo, học sinh khuyết tật, học sinh ngôn ngữ thiểu số hoặc học sinh vùng mạng yếu dùng ít hơn, scale sẽ làm khoảng cách rộng hơn. Điều đáng sợ là báo cáo trung bình vẫn có thể đẹp, vì nhóm dùng nhiều là nhóm đã thuận lợi.

Khung RE-AIM rất hữu ích ở đây vì nó bắt đầu bằng Reach, không bắt đầu bằng hiệu quả trên người đã tham gia. RE-AIM hỏi về Reach, Effectiveness, Adoption, Implementation và Maintenance, nhằm xem một chương trình có chạm được nhóm mục tiêu, tạo tác động, được tổ chức/người thực hiện chấp nhận, triển khai nhất quán, và duy trì được hay không.[^reaim] Với EdTech, Reach nghĩa là ai thật sự vào được công cụ, không chỉ ai được cấp tài khoản. Adoption nghĩa là giáo viên, trường, phụ huynh và học sinh có dùng thật không. Maintenance nghĩa là sau giai đoạn hỗ trợ đặc biệt, công cụ còn sống không.

Vì vậy, pilot phải thiết kế ngay từ đầu để thu dữ liệu người không dùng. Không phải theo dõi quá mức, mà là hiểu rào cản. Có thể cần phỏng vấn nhóm bỏ dùng, xem log lỗi đăng nhập, đo thiết bị, hỏi giáo viên, quan sát lớp, phân tích theo nhóm. Một pilot không biết vì sao người ta không dùng sẽ scale bằng niềm tin rằng truyền thông và tập huấn sẽ chữa mọi thứ.

7. Pilot phải đo support burden

Một sản phẩm chạy tốt trong pilot có thể chỉ vì đội hỗ trợ quá dày. Vendor tạo tài khoản, nhắc giáo viên, xử lý lỗi, đứng lớp buổi đầu, gọi điện từng trường, làm sạch dữ liệu, tạo báo cáo, giải thích dashboard, sửa nội dung, trả lời chat lúc tối. Điều này không xấu. Hỗ trợ mạnh ở pilot giúp phát hiện vấn đề. Nhưng nếu báo cáo không ghi support burden, tổ chức sẽ tưởng sản phẩm tự chạy.

Support burden gồm số giờ hỗ trợ kỹ thuật, số ticket, loại lỗi, thời gian xử lý, số lần giáo viên cần hỏi, số lần học sinh mất tài khoản, số lần thiết bị cần sửa, số lần dữ liệu sai, số buổi tập huấn bổ sung, số tài liệu phải viết lại, số cuộc gọi phụ huynh, số người cần có mặt để một lớp học diễn ra. Đây là dữ liệu rất đời thường, nhưng nó quyết định scale.

World Bank khi nói về EdTech nhấn mạnh thiết kế phải holistic: teacher capacity, digital resources gắn với curriculum, assessment, devices, connectivity, và readiness hệ thống; ETRI cũng xem technical support, maintenance responsibilities và monitoring tools là phần của readiness, không phải phụ lục.[^worldbank-digital][^worldbank-etri] Điều này nghĩa là pilot không thể chỉ đo học sinh làm bài. Nó phải đo hệ thống phải làm gì để học sinh có thể làm bài.

Một sản phẩm có thể đáng scale dù support burden ban đầu cao, nếu burden giảm nhanh khi quy trình ổn định. Nhưng nếu sau ba tháng, mỗi trường vẫn cần vendor xử lý liên tục, scale sẽ rất đắt. Nếu support burden chủ yếu do dữ liệu đầu vào bẩn, cần đầu tư data cleanup trước khi scale. Nếu burden do giao diện khó, cần sửa sản phẩm. Nếu burden do giáo viên không hiểu mục đích, cần sửa training. Support burden không phải chuyện vận hành nhỏ. Nó là chỉ số xem sản phẩm có tự đứng được trong trường học thật không.

8. Workload phải được đo bằng thời gian thật

Một pilot EdTech có thể nói giáo viên hài lòng, nhưng giáo viên vẫn làm thêm việc. Trong tuần đầu, họ có thể hào hứng. Đến tháng thứ hai, workload mới lộ rõ. Họ phải nhập danh sách, theo dõi học sinh chưa nộp, đọc dashboard, tạo nhóm, giải thích lỗi, kiểm tra câu trả lời AI, xử lý phụ huynh, đối chiếu điểm, tải tài liệu, gửi báo cáo. Nếu evaluation chỉ hỏi “thầy cô có thích sản phẩm không?” nó bỏ qua chi phí lao động.

Workload nên được đo bằng thời gian và nhịp công việc. Giáo viên mất bao lâu để chuẩn bị một tiết có công nghệ so với trước? Họ mất bao lâu để xử lý sau tiết học? Có công việc nào chuyển từ phòng IT sang giáo viên không? Có công việc nào chuyển từ giáo viên sang học sinh hoặc phụ huynh không? Thời gian tiết kiệm được dùng vào việc gì? Công cụ có giảm việc lặp vô nghĩa hay tạo thêm việc quản lý nền tảng?

Implementation outcomes taxonomy nhắc rằng cost, feasibility, adoption, fidelity và sustainability là các outcome riêng, không nên bị nhầm với kết quả cuối cùng của người học.[^implementation-outcomes] Workload nằm giữa cost và feasibility. Nếu giáo viên phải trả bằng thời gian vô hình, pilot chưa tính đủ chi phí. Nếu workload tăng ở nhóm giáo viên yếu công nghệ, scale có thể làm bất bình đẳng nghề nghiệp tăng.

Điều này không có nghĩa mọi tăng workload đều xấu. Một đổi mới tốt có thể cần giai đoạn học ban đầu. Nhưng pilot phải biết đường cong ấy. Workload tăng bao lâu? Sau khi quen có giảm không? Ai bị tăng nhiều nhất? Có hỗ trợ nào giảm burden không? Có việc nào nên bỏ để công cụ có chỗ sống không? Nếu trường thêm EdTech mà không bỏ gì, giáo viên sẽ trở thành nơi chất mọi tham vọng.

9. Unintended consequences không phải chuyện sau này

Một pilot nghiêm túc phải đi tìm hậu quả không mong muốn ngay từ đầu. Không phải để phá dự án, mà để không bị bất ngờ bởi những điều rất dễ đoán. App luyện tập có thể làm học sinh chỉ săn điểm. Dashboard có thể khiến giáo viên tập trung vào học sinh “gần đạt” và bỏ nhóm quá yếu. Tin nhắn phụ huynh có thể làm một số em bị mắng nhiều hơn. AI feedback có thể làm học sinh viết nhiều hơn nhưng nghĩ ít hơn. Bảng xếp hạng có thể tăng động lực cho nhóm đầu và làm nhóm cuối xấu hổ. Camera lớp học có thể làm học sinh im lặng hơn. Hệ thống cảnh báo có thể gắn nhãn rủi ro lên nhóm nghèo nhiều hơn.

UNESCO GEM 2023 nhấn mạnh cần mục tiêu và nguyên tắc rõ để công nghệ có lợi và tránh hại; báo cáo nêu các rủi ro như distraction, thiếu tiếp xúc con người, xâm phạm quyền riêng tư và tác động xã hội rộng hơn nếu thiếu quản trị.[^unesco-gem] Pilot là nơi những rủi ro ấy phải được đưa vào câu hỏi đo lường, không phải phần “ethical considerations” đặt cuối tài liệu.

Unintended consequences thường không hiện trong dashboard mặc định. Cần quan sát lớp, phỏng vấn học sinh, hỏi giáo viên, nhìn dữ liệu subgroup, kiểm tra hành vi gian lận, xem phụ huynh phản ứng, đo cảm giác thuộc về, đo áp lực, xem ai biến mất khỏi hệ thống. Một sản phẩm có thể tăng điểm ngắn hạn nhưng làm học sinh ghét môn học hơn. Một công cụ có thể giảm thời gian chấm nhưng làm giáo viên ít đọc suy nghĩ học sinh hơn. Những thứ này khó đo, nhưng không vì khó mà được phép bỏ qua.

Pilot tốt không chỉ hỏi “cái gì tốt lên?” mà hỏi “cái gì xấu đi?”. Nếu không có chỉ số nào có thể xấu đi trong báo cáo, báo cáo chưa nghiêm túc. Giáo dục là hệ thống phức tạp; can thiệp vào một điểm có thể đẩy gánh nặng sang điểm khác. Pilot là thời điểm rẻ nhất để thấy điều đó.

10. Data cleanup là nơi nhiều pilot chết thầm

EdTech thích nói về AI và analytics, nhưng nhiều triển khai vỡ ở dữ liệu cơ bản: tên học sinh sai, mã lớp không khớp, giáo viên chưa có tài khoản, học sinh chuyển trường, danh sách lớp cập nhật chậm, phụ huynh đổi số điện thoại, môn học đặt tên khác nhau, dữ liệu điểm nằm trong file rời, hệ thống cũ không xuất chuẩn, privacy consent chưa rõ. Trong pilot nhỏ, những lỗi này được sửa tay. Khi scale, sửa tay biến thành cơn lũ.

Data cleanup thường bị xem là việc hành chính thấp cấp, nhưng nó là hạ tầng học tập. Nếu học sinh không đăng nhập được, không có personalized learning. Nếu lớp không khớp, dashboard sai. Nếu điểm đầu vào sai, adaptive engine gợi ý sai. Nếu phụ huynh sai số điện thoại, nudge không đến. Nếu dữ liệu khuyết tật không được nhập đúng và an toàn, accessibility không hoạt động. Nếu danh sách giáo viên lỗi, training bỏ sót người.

World Bank nhấn mạnh nguyên tắc data-driven đi cùng transparent standards và interoperable data architecture, tránh data silos và vendor lock-in.[^worldbank-digital] Đây không phải câu chuyện kiến trúc xa xôi. Với pilot, nó có nghĩa là đừng để vendor âm thầm làm sạch dữ liệu bằng bảng tính riêng rồi báo sản phẩm chạy tốt. Cần đo rõ dữ liệu đầu vào bẩn thế nào, ai sửa, mất bao lâu, cần chuẩn gì, khi scale có tự động hóa được không, và dữ liệu có được trả lại hệ thống công không.

Một pilot không đo data cleanup sẽ đánh giá thấp chi phí scale. Nó giống như thử nấu ăn trong bếp đã có người rửa sạch nguyên liệu, cắt sẵn, cân sẵn, rồi kết luận công thức rất nhanh. Khi đưa cho hàng nghìn bếp trường học, ai sẽ làm phần chuẩn bị đó? Nếu câu trả lời là “chưa rõ”, pilot chưa đủ.

11. Từ pilot sang scale là đổi bản chất

Scale không phải pilot lớn hơn. Scale là một trạng thái khác. Trong pilot, quan hệ cá nhân thay thế quy trình. Trong scale, quy trình phải thay thế quan hệ cá nhân mà vẫn giữ chất lượng. Trong pilot, vendor biết tên từng giáo viên. Trong scale, support phải qua hệ thống. Trong pilot, lỗi dữ liệu được sửa tay. Trong scale, cần chuẩn dữ liệu. Trong pilot, một lãnh đạo thúc đẩy sát. Trong scale, nhiều cấp quản lý phải phối hợp. Trong pilot, giáo viên tự nguyện. Trong scale, nhiều người dùng không tự nguyện. Trong pilot, attention cao. Trong scale, attention phân tán.

Brookings Millions Learning nhấn mạnh scaling trong giáo dục không chỉ là nhân rộng một dự án, mà là mở rộng và làm sâu tác động bền vững trong hệ thống; Real-time Scaling Labs được thiết kế để học, hỗ trợ và ghi lại quá trình scale trong thời gian thực, bao gồm cả điều chỉnh dựa trên bằng chứng.[^brookings-scale] Đây là một điểm rất quan trọng: scale là quá trình thay đổi hệ thống, không phải thao tác copy-paste.

Điểm gãy từ pilot sang scale thường nằm ở training, support, data cleanup, procurement, governance, nội dung địa phương, lịch học, quyền dữ liệu, và động lực giáo viên. Sản phẩm có thể không đổi nhiều, nhưng môi trường thay đổi. Khi số trường tăng, variation tăng. Khi variation tăng, những giả định bị lộ. Nếu pilot không cố ý tìm điểm gãy, scale sẽ tìm giùm, nhưng lúc đó chi phí cao hơn.

Vì vậy, pilot tốt phải có “scale rehearsal”. Không cần mở rộng toàn hệ thống, nhưng cần mô phỏng các điều kiện scale: training theo cách có thể nhân rộng, support theo kênh bình thường, tài liệu tự học cho giáo viên, onboarding không cần vendor đứng cạnh, dữ liệu lấy từ hệ thống thật, thiết bị đa dạng, lớp không được chọn quá đẹp, và ngân sách tính theo mức thường niên. Nếu một pilot chỉ chạy được với đội đặc nhiệm, nó chưa chứng minh được scale.

12. Pilot nhỏ không được trả lời câu hỏi lớn quá mức

Một pilot 6 tuần ở 3 trường không thể chứng minh tác động dài hạn toàn hệ thống. Một pilot với 5 giáo viên giỏi không thể chứng minh adoption đại trà. Một pilot với thiết bị mới không thể chứng minh sustainability. Một pilot dùng bài test do vendor thiết kế không thể chứng minh learning transfer rộng. Một pilot không có nhóm so sánh không thể nói chắc về tác động nhân quả. Vấn đề không phải pilot nhỏ vô dụng. Vấn đề là kết luận phải khớp với thiết kế.

Pilot nhỏ có thể trả lời câu hỏi tốt: onboarding có hiểu được không, lỗi kỹ thuật chính là gì, giáo viên thấy dashboard có hành động được không, học sinh có dùng được trên thiết bị cũ không, ngôn ngữ có rõ không, dữ liệu nào thiếu, lịch học nào phù hợp, nhóm nào bị bỏ lại, outcome nào nên đo ở pilot lớn hơn. Những câu hỏi này rất giá trị. Nhưng chúng không phải “sản phẩm này tăng learning outcomes 20%”.

J-PAL và MIT từng nhấn mạnh nhu cầu đánh giá nghiêm túc các mô hình EdTech, đặc biệt khi công nghệ được nhận nuôi nhanh và người ra quyết định cần biết cách nào thật sự cải thiện học tập, nhất là cho nhóm bất lợi.[^jpal-edtech] Điều đó không có nghĩa mỗi pilot phải là RCT lớn. Nó có nghĩa là phải trung thực về cấp độ bằng chứng. Feasibility pilot, usability pilot, efficacy trial, effectiveness trial và scale evaluation là những câu hỏi khác nhau.

Khi pilot nhỏ bị dùng để bán quyết định lớn, nó phản bội cả người làm nghiên cứu lẫn người làm sản phẩm. Sản phẩm bị đặt vào scale trước khi sẵn sàng. Trường bị buộc tin quá mức. Người học chịu rủi ro. Một tổ chức trưởng thành không hỏi pilot nhỏ câu hỏi mà chỉ pilot lớn hoặc evaluation khác mới trả lời được.

13. Pilot vĩnh viễn cũng là một cách né trách nhiệm

Nếu một bên dùng pilot để chứng minh quá mức, bên kia có thể dùng pilot để trì hoãn mãi. “Cần thử thêm.” “Cần dữ liệu thêm.” “Cần thêm năm nữa.” “Cần thêm bối cảnh nữa.” Trong khi đó, người học vẫn thiếu hỗ trợ, giáo viên vẫn quá tải, hệ thống vẫn đứng yên. Bằng chứng không nên trở thành cái cớ để không quyết định.

Có những can thiệp rủi ro thấp, chi phí thấp, dựa trên cơ chế mạnh, có phản hồi tích cực, có monitoring tốt, thì có thể mở rộng dần mà không cần chờ bằng chứng hoàn hảo. Có những can thiệp rủi ro cao, thu dữ liệu nhạy cảm, thay đổi grading, tracking hoặc placement, thì cần bằng chứng mạnh hơn. Vấn đề là không dùng một chuẩn cho mọi thứ. Chương 31 đã nói: mức bằng chứng phải khớp mức rủi ro.

Pilot vĩnh viễn cũng có hại cho giáo viên. Họ liên tục thử công cụ mới, quy trình mới, dashboard mới, tài khoản mới, nhưng không có gì trở thành năng lực ổn định. Học sinh thì thành đối tượng của chuỗi thử nghiệm không kết thúc. Một hệ thống luôn pilot nhưng không scale cái tốt, không dừng cái xấu, không tích lũy năng lực, thì đang bận rộn mà không học.

Vì vậy, pilot cần decision gate rõ: sau giai đoạn này, quyết định là gì? Dừng, sửa rồi thử lại, mở rộng có giới hạn, hay scale? Cần dữ liệu nào để quyết định? Ai quyết định? Khi nào? Nếu không có gate, pilot trở thành trạng thái lơ lửng. Đổi mới nghiêm túc cần cả quyền thất bại lẫn nghĩa vụ quyết định.

14. Các bên trong cuộc tranh luận

Vendor nói: “Nếu pilot không tạo câu chuyện thành công, không ai dám mua.” Đây là thật. Thị trường thưởng cho câu chuyện đẹp. Nhưng vendor nghiêm túc nên hiểu rằng pilot che lỗi sẽ làm sản phẩm vỡ ở scale. Một pilot trung thực có thể khó bán ngắn hạn hơn, nhưng nó giúp sản phẩm trưởng thành, tránh overpromise và xây niềm tin dài hạn.

Nhà quản lý nói: “Tôi cần pilot để thuyết phục cấp trên và phụ huynh.” Cũng đúng. Chính sách cần sự ủng hộ. Nhưng thuyết phục không nên đồng nghĩa dàn dựng. Một báo cáo pilot mạnh nhất không phải báo cáo không có lỗi. Nó là báo cáo chỉ ra lỗi, cách sửa, chi phí sửa, và vì sao sau khi sửa vẫn đáng làm. Sự tin cậy đến từ minh bạch, không phải từ hình ảnh không vết xước.

Giáo viên nói: “Đừng biến lớp tôi thành nơi quay demo.” Đây là yêu cầu chính đáng. Nếu giáo viên tham gia pilot, họ phải được quyền phản hồi thật, được hỗ trợ thật, được bảo vệ khỏi áp lực phải khen, và được biết phản hồi của họ dẫn đến thay đổi gì. Một pilot lấy thời gian lớp học nhưng không trả lại năng lực hoặc cải tiến là pilot khai thác.

Nhà nghiên cứu nói: “Pilot cần thiết kế đủ nghiêm để học được.” Đúng. Nhưng nhà nghiên cứu cũng phải tôn trọng nhịp trường học. Một evaluation quá nặng có thể làm pilot biến dạng. Cần thiết kế đo lường vừa đủ: đủ để ra quyết định, không nặng đến mức chính việc đo trở thành gánh nặng mới.

Học sinh nói: “Em không muốn là bằng chứng cho thứ người lớn đã quyết.” Đây là lời nhắc đạo đức. Pilot phải bảo vệ người học: không dùng dữ liệu quá mức, không làm hại lộ trình học, không bỏ nhóm yếu, không bắt buộc rủi ro cao khi chưa đủ căn cứ, không dùng cảm xúc hào hứng ban đầu của học sinh làm bằng chứng học tập.

Nhà tài trợ nói: “Chúng tôi cần thấy impact.” Đúng, nhưng impact trong pilot phải được hiểu như học hỏi có kỷ luật. Nếu nhà tài trợ chỉ muốn câu chuyện thành công, người nhận tài trợ sẽ học cách che thất bại. Nếu nhà tài trợ muốn learning agenda thật, hệ thống có thể nói sự thật sớm hơn.

15. Một thiết kế pilot đáng tin

Một pilot đáng tin bắt đầu bằng vấn đề cụ thể. Không phải “đưa AI vào trường học”, mà là “giáo viên lớp 7 mất quá nhiều thời gian tạo bài luyện phân hóa”, hoặc “học sinh lớp 5 yếu đọc không có đủ bài luyện đúng trình độ”, hoặc “phụ huynh không nhận được cảnh báo vắng học kịp thời”. Vấn đề càng rõ, công nghệ càng bớt phô diễn.

Nó có logic model ngắn: input là gì, hoạt động là gì, ai đổi hành vi, cơ chế học tập là gì, outcome gần là gì, outcome xa là gì, rủi ro là gì. Logic model không phải trang trí hồ sơ. Nó giúp biết đo cái gì. Nếu cơ chế là feedback tức thì, phải đo học sinh có nhận và dùng feedback không. Nếu cơ chế là giáo viên dạy lại dựa trên dashboard, phải đo giáo viên có xem dashboard và dạy lại không.

Nó có baseline và nhóm so sánh phù hợp với câu hỏi. Không phải lúc nào cũng cần RCT, nhưng cần một cách chống tự lừa: dữ liệu trước-sau, nhóm tương tự, staggered rollout, matched comparison, hoặc ít nhất là mục tiêu đo rõ và dữ liệu người không dùng. Thiết kế càng yếu, claim càng khiêm tốn.

Nó có success và failure criteria trước khi chạy. Không thêm tiêu chí sau khi thấy dữ liệu. Không chỉ đo cái đẹp. Có learning outcome, adoption, workload, support burden, equity, cost và unintended consequences. Có ngưỡng để scale, ngưỡng để sửa, ngưỡng để dừng.

Nó chọn mẫu có chủ ý. Có trường thuận lợi để thấy trần giá trị, có trường bình thường để thấy thực tế, có bối cảnh khó để thấy giới hạn. Không chọn toàn người chống đối, cũng không chọn toàn người hâm mộ. Một pilot chỉ có fan club không nói được tương lai.

Nó dùng quy trình có thể scale. Training phải gần với training sau này. Support phải được ghi lại. Data cleanup phải được tính giờ. Tài liệu phải đủ rõ để giáo viên mới hiểu. Nếu đội đặc nhiệm làm gì, phải ghi việc đó thành chi phí hoặc chuyển thành năng lực hệ thống.

Nó có after-action review trung thực: điều gì đúng, điều gì sai, điều gì bất ngờ, giả thuyết nào được giữ, giả thuyết nào bị bác, điều kiện tối thiểu là gì, điểm gãy khi scale là gì, quyết định tiếp theo là gì. Báo cáo pilot tốt không phải báo cáo làm người đọc yên tâm tuyệt đối. Nó làm người đọc hiểu rủi ro rõ hơn.

16. Pilot với AI cần ngưỡng nghiêm hơn

AI làm pilot phức tạp hơn vì sản phẩm không chỉ phản hồi cố định. Nó sinh câu trả lời, chấm, gợi ý, tóm tắt, phân loại, cảnh báo, đôi khi suy luận về người học. Một lỗi AI có thể không lặp lại theo cách dễ thấy. Một model update có thể thay đổi hành vi sản phẩm giữa pilot. Một câu trả lời sai có thể nghe rất tự tin. Một dashboard risk có thể ảnh hưởng kỳ vọng của giáo viên. Một AI tutor có thể tạo quan hệ mô phỏng mà người học tin là quan hệ thật.

Vì vậy, pilot AI không thể chỉ đo usage và satisfaction. Nó cần kiểm tra chất lượng đầu ra, hallucination, bias theo nhóm, mức phù hợp chương trình học, tone với trẻ em, privacy, data retention, human oversight, escalation khi AI không biết, khả năng giáo viên kiểm soát, và tác động lên tự học. Nếu AI chấm bài, cần so với người chấm, kiểm tra sai lệch theo nhóm, và có quyền khiếu nại. Nếu AI tutor, cần kiểm tra liệu học sinh hiểu sâu hơn hay chỉ nhận lời giải nhanh hơn. Nếu AI cảnh báo rủi ro, cần kiểm tra false positive, false negative và hành động sau cảnh báo.

World Bank nhấn mạnh AI trong giáo dục có rủi ro như bias, privacy và khả năng làm sâu bất bình đẳng nếu không có safeguards; đồng thời công nghệ phải hỗ trợ chứ không thay thế giáo viên.[^worldbank-digital] Điều này đưa ra một nguyên tắc cho pilot AI: human-in-the-loop không phải câu chữ an toàn. Phải đo con người thật sự can thiệp lúc nào, có đủ thông tin không, có quyền override không, và có đủ thời gian không.

AI cũng cần version control trong pilot. Model nào, prompt nào, guardrail nào, dữ liệu retrieval nào, chính sách lưu dữ liệu nào, ngày nào thay đổi, thay đổi có ảnh hưởng gì. Nếu pilot AI chạy trên một hệ thống thay đổi liên tục mà không ghi phiên bản, kết quả rất khó đọc. Một pilot không biết mình đã thử phiên bản nào thì không biết mình học được điều gì.

17. Khi nào nên scale?

Không có một ngưỡng duy nhất cho mọi sản phẩm, nhưng có vài dấu hiệu tốt. Thứ nhất, vấn đề thật và đủ quan trọng. Pilot không chỉ chứng minh công cụ chạy, mà chứng minh công cụ chạm vào một nhu cầu ưu tiên. Thứ hai, cơ chế tác động có tín hiệu rõ: người dùng đổi hành vi theo cách logic model dự đoán. Thứ ba, learning hoặc outcome mục tiêu cải thiện ở mức đáng chú ý, hoặc ít nhất có bằng chứng đủ mạnh để mở rộng có kiểm soát nếu pilot là feasibility stage.

Thứ tư, adoption không chỉ đến từ nhóm thuận lợi. Người dùng bình thường có thể dùng với training và support hợp lý. Thứ năm, workload và support burden nằm trong ngưỡng có thể duy trì. Thứ sáu, equity không xấu đi hoặc đã có phương án rõ cho nhóm bị bỏ lại. Thứ bảy, data cleanup, integration, procurement và governance đã được hiểu đủ. Thứ tám, cost model nhiều năm không vỡ. Thứ chín, có kế hoạch monitoring khi scale và quyền dừng nếu tín hiệu xấu.

Scale không nhất thiết là toàn hệ thống ngay. Có thể scale theo vòng: thêm vùng, thêm lớp, thêm môn, thêm nhóm trường khó hơn, hoặc thêm tính năng sau khi ổn định. Scale tốt giống học tiếp ở mức rủi ro cao hơn, không phải nhảy từ sân khấu nhỏ sang sân vận động. Mỗi vòng scale nên trả lời câu hỏi mới: điều gì còn đúng khi hỗ trợ giảm, variation tăng, người dùng bớt hâm mộ, và chi phí thật xuất hiện?

Nếu pilot có kết quả đẹp nhưng chỉ trong điều kiện quá đặc biệt, đừng scale sản phẩm; scale việc học được từ pilot. Có thể kết luận rằng công cụ tốt cho nhóm hẹp, hoặc cần redesign, hoặc nên dùng như supplement tự chọn, hoặc chỉ nên triển khai nơi có hạ tầng đủ, hoặc cần đầu tư dữ liệu trước. Không scale cũng có thể là một quyết định thông minh. Quy mô không phải phần thưởng cho pilot. Quy mô là trách nhiệm.

18. Lập trường của chương này

Chương này không chống pilot. Ngược lại, nó bảo vệ pilot khỏi bị làm rỗng. Giáo dục cần thử nghiệm nhỏ trước khi quyết định lớn. EdTech càng mới, càng phức tạp, càng chạm dữ liệu và quan hệ học tập, càng cần pilot. Nhưng pilot chỉ có giá trị nếu nó được phép nói sự thật.

Pilot không phải màn trình diễn cho sản phẩm. Nó là cuộc gặp có kỷ luật giữa giả thuyết và đời sống trường học. Nó phải có baseline, giả thuyết, tiêu chí thành công, tiêu chí thất bại, dữ liệu người không dùng, đo workload, đo support burden, nhìn unintended consequences, và chuẩn bị cho scale bằng cách tìm điểm gãy. Nó phải tôn trọng giáo viên như người đồng thiết kế, học sinh như chủ thể cần bảo vệ, và dữ liệu như công cụ học hỏi chứ không phải chất liệu quảng cáo.

Nếu pilot chỉ chọn lớp đẹp, giáo viên đẹp, điều kiện đẹp, rồi kết luận sản phẩm đẹp, nó không giúp giáo dục. Nó chỉ giúp niềm tin của người đã muốn tin. Nếu pilot có thể thất bại, có thể làm người ta sửa, có thể làm người ta dừng, có thể làm người ta scale thận trọng hơn, thì nó đáng làm. Một pilot tốt không nhất thiết kết thúc bằng tiếng vỗ tay. Nó kết thúc bằng một quyết định sáng hơn.

Và có lẽ đây là thước đo đơn giản nhất: sau pilot, tổ chức có can đảm nói điều gì không đẹp không? Nếu không, pilot chưa phải học. Nó vẫn là sân khấu.

Ghi chú nguồn cho chương

[^eef-implementation]: Education Endowment Foundation, A School’s Guide to Implementation (Third Edition, 2024). Hướng dẫn nhấn mạnh rằng một ý tưởng giáo dục chỉ có ý nghĩa khi nó biểu hiện trong công việc hằng ngày của trường; implementation cần chú ý behaviors, contextual factors và structured process. Nguồn: https://educationendowmentfoundation.org.uk/education-evidence/guidance-reports/implementation

[^worldbank-remote]: World Bank, Remote Learning during the pandemic: Lessons from today, principles for tomorrow (2021). Báo cáo mô tả “remote learning paradox” khi nhiều hệ thống chọn phương thức học từ xa không phù hợp với access và capabilities của đa số giáo viên, học sinh; dẫn đến take-up thấp và bất bình đẳng gia tăng. Nguồn: https://www.worldbank.org/en/news/press-release/2021/11/18/new-world-bank-report-remote-learning-during-the-pandemic-lessons-from-today-principles-for-tomorrow

[^used-evidence]: U.S. Department of Education, Using Evidence to Strengthen Education Investments (Revised Non-Regulatory Guidance, September 28, 2023) và các trang hỗ trợ evidence-based practices. Hướng dẫn nhấn mạnh quy trình continuous improvement gồm identify local needs, select relevant evidence-based components, plan, implement, examine and reflect. Nguồn: https://eed.communities.ed.gov/resources/revised-non-regulatory-guidance-using-evidence-strengthen-education-investments và trang tóm tắt: https://www.ed.gov/teaching-and-administration/lead-and-manage-my-school/state-support-network/ssn-resources/leveraging-evidence-based-practices-for-local-school-improvement

[^edtechhub-sandbox]: EdTech Hub, Sandbox Method: Sandboxes to Scale Impactful EdTech Interventions. EdTech Hub mô tả sandbox như một cách tạo real-time evidence qua thử nghiệm nhanh, lặp lại trong điều kiện thực, nhằm tăng hiệu quả, giảm chi phí và hiểu cách triển khai EdTech ở quy mô. Nguồn: https://edtechhub.org/sandboxes/ và trang Evidence in EdTech: https://edtechhub.org/evidence/

[^reaim]: RE-AIM Workgroup, What is RE-AIM? và Shaw et al., Operationalizing the RE-AIM framework (BMC Public Health, 2019). RE-AIM là khung lập kế hoạch/đánh giá theo năm chiều: Reach, Effectiveness, Adoption, Implementation và Maintenance, giúp chú ý cả external validity, adoption và sustainability chứ không chỉ hiệu quả trên người đã tham gia. Nguồn: https://re-aim.org/learn/what-is-re-aim/ và https://bmcpublichealth.biomedcentral.com/articles/10.1186/s12889-019-7131-4

[^worldbank-digital]: World Bank Group, Digital Technologies in Education (trang chủ đề, cập nhật 2025). World Bank nhấn mạnh công nghệ không phải silver bullet; chính sách EdTech cần hỏi “why”, thiết kế cho scale, empower teachers, engage ecosystem và dùng data-driven systems với transparent standards/interoperable data architecture để tránh data silos và vendor lock-in. Nguồn: https://www.worldbank.org/ext/en/topic/education/digital-technologies-in-education

[^worldbank-etri]: World Bank, Education and Technology Readiness Index (ETRI). ETRI đánh giá readiness của hệ sinh thái EdTech qua School Management, Teachers, Students, Devices, Connectivity và Digital Education Resources; trong Devices và Connectivity có các yếu tố như technical support, maintenance responsibilities và monitoring tools. Nguồn: https://www.worldbank.org/en/topic/education/brief/edtech-readiness-index

[^implementation-outcomes]: Proctor và cộng sự đề xuất taxonomy implementation outcomes năm 2011; bài scoping review 2023 trong Implementation Science tổng hợp 10 năm nghiên cứu implementation outcomes, gồm acceptability, adoption, appropriateness, feasibility, fidelity, cost, penetration và sustainability. Nguồn: https://implementationscience.biomedcentral.com/articles/10.1186/s13012-023-01286-z

[^unesco-gem]: UNESCO Global Education Monitoring Report Team, Technology in education: A tool on whose terms? (2023). Báo cáo nhấn mạnh cần mục tiêu và nguyên tắc rõ để công nghệ có lợi và tránh hại; đồng thời nêu các rủi ro như distraction, thiếu tiếp xúc con người, privacy, bất bình đẳng tiếp cận và việc bằng chứng về tác động EdTech còn thiếu. Nguồn: https://www.unesco.org/gem-report/en/publication/technology-education và bản web: https://gem-report-2023.unesco.org/technology-in-education/

[^brookings-scale]: Brookings Center for Universal Education, Millions Learning và Real-time Scaling Labs. Dự án nhấn mạnh scaling trong giáo dục không chỉ là mở rộng một dự án, mà là mở rộng và làm sâu tác động bền vững trong hệ thống; Real-time Scaling Labs học, hỗ trợ và ghi lại quá trình scale trong thời gian thực để điều chỉnh dựa trên bằng chứng. Nguồn: https://www.brookings.edu/real-time-scaling-labs/ và https://www.brookings.edu/articles/millions-learning-real-time-scaling-labs/

[^jpal-edtech]: MIT News/J-PAL North America, What 126 studies say about education technology (2019) và các hoạt động Education, Technology, and Opportunity Initiative. J-PAL nhấn mạnh nhu cầu đánh giá nghiêm túc các mô hình EdTech bằng randomized evaluations và regression discontinuity designs để biết công nghệ giúp hay hại học tập, nhất là với nhóm bất lợi. Nguồn: https://news.mit.edu/2019/mit-jpal-what-126-studies-tell-us-about-education-technology-impact-0226 và https://news.mit.edu/2019/j-pal-north-america-calls-proposals-education-leaders-0114