Demo prototype AI cho khách hàng: cho thấy cái đã chạy mà không hứa quá tay

Thử hình dung: thứ Hai, trưởng phòng kế toán của một công ty logistics than rằng đội chị mất cả buổi chiều để gõ lại số liệu từ hóa đơn nhà cung cấp. Thứ Ba, bạn mở laptop và cho chị xem một prototype đọc hóa đơn rồi tự điền vào bảng tính.

Cả phòng gật gù. Rồi giám đốc tài chính hỏi câu mà FDE nào sớm muộn cũng gặp: “Tháng sau chạy cho toàn công ty được chứ?” Mười giây trả lời câu đó sẽ quyết định không khí của mấy tháng làm việc sau.

Nghe hôm nay, demo ngày mai: đó là nhịp làm việc của nghề này. Shilpa Balaji, cựu FDE ở Palantir, kể rằng hôm trước nghe khách nói gì thì dựng prototype cho điều đó, hôm sau đã mang ra cho khách xem.

Nhưng làm nhanh đến vậy thì cũng rất dễ hứa nhanh theo. Prototype trông như đã xong từ rất lâu trước khi nó xong thật, và fde.academy xếp chuyện hứa quá tay vào nhóm lỗi hàng đầu của FDE mới.

Một buổi demo chứng minh được điều gì?

Prototype của bạn vừa đọc đúng ba hóa đơn do chính bạn chọn, trước những người bạn biết trước sẽ ngồi trong phòng. Một prototype chỉ cần làm được chừng đó: chạy đúng một lần, trên dữ liệu tự chọn, trước khán giả đã chuẩn bị sẵn.

Hệ thống cho toàn công ty thì khác. Nó phải đọc đúng mọi hóa đơn, kể cả những tờ chưa ai nhìn thấy. Giám đốc tài chính không thấy khoảng cách ấy, chị chỉ thấy một màn hình chạy mượt.

Demo vốn được dựng để cho thấy năng lực, không phải để chứng minh độ tin cậy. Blog của EB Pearls cho rằng dự án vấp ở bước từ demo lên production hiếm khi vì kỹ thuật, mà thường vì kỳ vọng hai bên không khớp nhau. Vì thế, việc chính của bạn trong phòng họp không phải là gây ấn tượng mà là giúp khách kỳ vọng đúng mức.

Muốn vậy, hãy coi prototype ấn tượng là bằng chứng cho thấy giai đoạn tốn kém phía sau đáng để bắt đầu. Một kế hoạch thực tế nhìn nó theo cách đó, không coi nó là sản phẩm gần xong. Câu trả lời cho giám đốc tài chính nên bắt đầu từ đây.

Vì sao phải demo trên dữ liệu của chính khách hàng?

First Round Review kể rằng ở Looker, demo luôn chạy trên dữ liệu thật của khách, nên mỗi buổi demo cũng là một proof of concept. Looker không có bản demo bán hàng nào dùng dữ liệu giả. Đây không chỉ là chuyện đạo đức: dữ liệu thật buộc prototype gặp ngay những thứ sẽ làm nó hỏng về sau.

Lý do thứ hai còn quan trọng hơn. Những gì FDE phát hiện tại chỗ khách thường khác xa những gì hợp đồng đã bán. Một bộ hóa đơn mẫu đẹp đẽ chỉ kiểm tra được các giả định ghi trong hợp đồng.

Hóa đơn thật thì có ảnh chụp nghiêng, có ghi chú viết tay, có nhà cung cấp in tổng tiền ở một chỗ lạ. Chính những tờ đó cho biết khách thật sự cần gì.

Vậy việc đầu tiên tại chỗ khách là xin một lô mẫu thật, gồm cả những mẫu “xấu” mà đội vận hành ngại nhất. Nếu khách chỉ đưa toàn mẫu sạch, hãy hỏi thẳng: loại chứng từ nào đang khiến đội mất nhiều thời gian nhất?

Kịch bản 20 phút, từng phần một

Quay lại phòng họp ở công ty logistics giả định. Bảng dưới đây là một kịch bản bạn có thể dùng gần như nguyên văn, chỉ cần thay nghiệp vụ.

Phần	Bạn nói hoặc làm gì	Mục đích
Mở đầu: nói rõ phạm vi	“Đây là prototype, chạy trên 50 hóa đơn chị gửi hôm qua. Em sẽ cho xem nó làm được gì và chỗ nào chưa.”	Đặt kỳ vọng trước khi khách thấy bất cứ thứ gì
Chạy trên dữ liệu thật	Mở hai, ba hóa đơn thuộc loại phổ biến nhất và chạy trực tiếp	Khách thấy đúng nghiệp vụ của mình
Chủ động cho xem ca lỗi	Chạy một ảnh chụp mờ khiến hệ thống đọc sai tổng tiền	Khách thấy bạn không giấu điểm yếu
Con số có eval phía sau	“41 trên 50 hóa đơn trích đúng mọi trường. 9 ca sai chủ yếu là ảnh chụp nghiêng.”	Con số khách có thể tự kiểm lại
Đánh đổi và bước tiếp	Nêu thời gian xử lý, chi phí mỗi hóa đơn và kế hoạch thử trong sandbox	Biến câu “khi nào xong” thành một kế hoạch

Phần thứ tư là chỗ nhiều người làm sai. Lý do rất đơn giản: không có bộ eval thì khi chất lượng đầu ra kém dần đi, sẽ không có gì báo cho bạn biết.

Hamel Husain còn nói mạnh hơn: theo ông, các sản phẩm AI thất bại gần như luôn chung một gốc rễ là không xây được hệ thống đánh giá đủ vững. Con số 41 trên 50 có giá trị vì khách có thể mở từng hóa đơn ra đối chiếu.

Phần thứ năm cũng cần thẳng thắn như vậy. Hệ thống agent thường chịu độ trễ cao hơn và chi phí lớn hơn để đổi lấy kết quả tốt hơn, và giám đốc tài chính cần biết điều này trước khi đồng ý. Bước tiếp theo hợp lý là thử thật kỹ trong sandbox, có guardrail phù hợp, rồi mới cho agent chạy thật.

Đến lúc này, bạn đã có câu trả lời cho câu hỏi “tháng sau”:

“Tháng sau thì chưa chạy toàn công ty được. Prototype cho thấy tự động hóa là khả thi với hóa đơn chuẩn. Bước tiếp theo là cho nó chạy song song với đội kế toán trong sandbox, đo trên dữ liệu mới, rồi mới quyết định mở rộng.”

Chuẩn bị trước buổi demo như thế nào?

Hãy bắt đầu từ dữ liệu chứ đừng bắt đầu từ slide. Lấy mẫu thật từ khách, rồi tự tay gán nhãn đáp án đúng cho vài chục mẫu. Việc này tẻ nhạt, nhưng nhờ nó, cảm giác “có vẻ ổn” trở thành một con số bạn bảo vệ được.

Tiếp theo, dựng phiên bản đơn giản nhất có thể chạy được. Anthropic khuyên chỉ thêm độ phức tạp khi thật sự cần. Làm vậy còn giữ cho demo trung thực, vì thứ bạn trình diễn đúng là thứ bạn đã xây, không có lớp nào thêm vào chỉ để trông ấn tượng.

Cuối cùng, chạy eval rồi xếp các lỗi theo nguyên nhân. Chọn một lỗi tiêu biểu để đưa vào demo, và viết sẵn câu mở đầu cùng câu trả lời cho “khi nào xong”. Nếu đọc to câu trả lời đó mà bạn thấy ngượng, nhiều khả năng nó vẫn đang hứa quá tay.

Những lỗi biến buổi demo thành một lời hứa

Một lỗi hay gặp là demo trên dữ liệu mẫu được chọn cho đẹp. Khách sẽ nhớ cái hệ thống chạy mượt đó. Đến lần đầu nó vấp trên hóa đơn thật, họ sẽ thấy mình bị lừa.

Lỗi thứ hai là giấu ca sai. Thực ra, một lỗi do chính bạn chỉ ra lại tạo được uy tín mà một buổi demo hoàn hảo không tạo được.

Lỗi thứ ba là nói “độ chính xác khoảng 95%” trong khi phía sau không có bộ eval nào. Lỗi thứ tư là dựng agent nhiều bước chỉ để gây ấn tượng, rồi phải gánh luôn độ trễ và chi phí của nó. Lỗi thứ năm là trả lời “khi nào” bằng một ngày cụ thể ngay trong phòng họp.

Cả năm lỗi đều chung một gốc: tưởng buổi demo là đích đến. fde.academy viết rằng thành công của một FDE được đo bằng việc vấn đề thật của khách có được giải quyết hay không, chứ không đo bằng độ ấn tượng của buổi demo.

Thể hiện kỹ năng này trong CV

Khi đọc JD, hãy để ý xem “prototype”, “customer-facing demo” và “evaluation” có cùng xuất hiện không. Nếu có, đó là dấu hiệu công việc cần đúng kỹ năng này.

Trong CV, một dòng gọn là đủ, chẳng hạn: “Dựng prototype trích xuất chứng từ trên dữ liệu thật của khách; tự xây bộ eval có nhãn trước buổi demo, trình bày cả ca lỗi và đề xuất giai đoạn thử trong sandbox.”

Dòng đó cho người đọc thấy bạn làm nhanh mà vẫn biết dừng đúng chỗ. fde.academy nhắc rằng khách hàng nhớ người giữ lời lâu hơn nhiều so với người nói năng tự tin trong phòng họp. Buổi demo đầu tiên là lần đầu bạn có dịp giữ lời.