Khi bạn mới bắt đầu xây dựng với trí tuệ nhân tạo, những tiếng nói lớn nhất đều chỉ về cùng một hướng: mô hình. Họ nói rằng chỉ cần chọn đúng mô hình, mọi thứ khác sẽ đâu vào đấy. Sau vài tuần tự mình thử nghiệm, tôi có thể khẳng định với bạn rằng điều đó đơn giản là không đúng. Việc lựa chọn giữa các mô hình ngôn ngữ lớn hiện có là quan trọng, nhưng nó có lẽ chỉ chiếm 20% công việc. Phần còn lại là công việc về hệ thống. Đó là việc xây dựng hạ tầng, kỹ nghệ và thử nghiệm không ngừng nghỉ. Nhận thức đó đã đến với tôi từ sớm, và nó đã thay đổi hoàn toàn cách tôi tiếp cận mọi dự án kể từ đó.
Mô hình chỉ là sự khởi đầu
Dễ hiểu tại sao những người mới bắt đầu lại ám ảnh với các mô hình. Các ghi chú phát hành hứa hẹn khả năng lập luận tốt hơn, cửa sổ ngữ cảnh lớn hơn và kết quả đầu ra sạch hơn. Những cải tiến đó là có thật, nhưng chúng cũng mang tính đa dụng. Một mô hình tiên tiến nhất cũng sẽ không tự động biết chính sách hoàn tiền của công ty bạn. Nó sẽ không định dạng phản hồi một cách đáng tin cậy cho ứng dụng di động của bạn trừ khi bạn hướng dẫn cách làm. Nó cũng không thể tự dưng lấy được dữ liệu tồn kho trực tiếp.
Tôi đã học được điều này một cách cay đắng. Bản mẫu đầu tiên của tôi sử dụng một mô hình đầy năng lực và tạo ra những đoạn văn đẹp đẽ, đầy tự tin nhưng đôi khi lại hoàn toàn sai lệch. Văn bản nghe có vẻ chuyên nghiệp vì mô hình đã nắm vững tông giọng, nhưng nó lại không có quyền truy cập vào thông tin hiện tại. Tôi đã dành nhiều ngày để so sánh các điểm chuẩn (benchmarks) của mô hình trong khi lẽ ra tôi nên nghĩ về các đường ống dữ liệu (data pipelines) và việc chèn ngữ cảnh (context injection). Mô hình không hề hỏng. Hệ thống xung quanh nó mới là chưa hoàn thiện. Sự phân biệt đó là tất cả khi bạn chuyển từ các bản demo sang phần mềm mà mọi người thực sự tin dùng.
Prompt là mã lệnh, không phải lời gợi ý
Các prompt chất lượng cao nằm ở trung tâm của bất kỳ ứng dụng AI đáng tin cậy nào. Lúc đầu, tôi coi prompt như các truy vấn tìm kiếm—ngắn gọn, thân mật và đầy lạc quan. Tôi thường yêu cầu mô hình "tóm tắt cái này" hoặc "hãy hữu ích nhé" và hy vọng điều tốt đẹp nhất sẽ đến. Kết quả dao động dữ dội giữa hữu ích và không liên quan, và tôi chẳng hiểu tại sao.
Giờ đây, tôi coi prompt như những chương trình nhẹ. Một prompt tốt sẽ xác định vai trò, chỉ định định dạng đầu ra, bao gồm các ví dụ khi cần thiết và thiết lập các ranh giới. Nếu tôi muốn JSON, tôi yêu cầu JSON và đưa ra schema. Nếu tôi cần một câu trả lời ngắn gọn, tôi sẽ giới hạn độ dài một cách rõ ràng và cấm phần mở đầu (preamble). Việc lặp lại (iteration) rất quan trọng. Tôi lưu lại nhật ký các prompt và kết quả đầu ra của chúng, thay đổi từng biến một. Một tính từ mơ hồ duy nhất trong prompt có thể làm thay đổi hành vi của cả một quy trình làm việc. Sự nhạy cảm đó đòi hỏi sự khắt khe, chứ không phải là sự đoán mò.
Dữ liệu đầu vào kém, kết quả đầu ra kém
Khả năng truy xuất dữ liệu đáng tin cậy là nơi mà nhiều dự án AI âm thầm thất bại. Retrieval-Augmented Generation, hay RAG, đã trở thành mô hình tiêu chuẩn để cho phép các mô hình truy cập vào dữ liệu riêng tư hoặc dữ liệu hiện tại. Ý tưởng rất đơn giản: lấy các tài liệu liên quan, đưa chúng vào cửa sổ ngữ cảnh của mô hình và để mô hình lập luận dựa trên các sự thật. Nhưng thực tế thì phức tạp hơn nhiều.
Tôi đã dành thời gian gỡ lỗi một cơ sở tri thức đơn giản nhưng liên tục trả về các kết quả không liên quan. Mô hình vẫn ổn. Lớp truy xuất (retrieval layer) mới là thứ đang gặp lỗi. Các đoạn dữ liệu (chunks) của tôi quá nhỏ và bị mất ngữ cảnh. Các vector nhúng (embeddings) của tôi được tạo ra mà không làm sạch các tiêu đề trùng lặp. Việc tìm kiếm sự tương đồng đã tìm thấy các đoạn văn bản có sự gần gũi về mặt kỹ thuật nhưng lại trả lời sai câu hỏi. Việc khắc phục có nghĩa là phải tư duy lại chiến lược chia nhỏ dữ liệu (chunking strategy), thêm các bộ lọc siêu dữ liệu (metadata filters) và đưa vào bước xếp hạng lại (re-ranking). Một khi việc truy xuất đã ổn định, câu trả lời của mô hình được cải thiện ngay lập tức. Bài học rất rõ ràng: bạn không thể vá lỗi truy xuất dữ liệu kém bằng một mô hình tốt hơn. Bạn phải xây dựng đường ống dữ liệu một cách chính xác.
Bạn không thể cải thiện những gì bạn không đo lường được
Đánh giá liên tục là thói quen phân biệt giữa các thử nghiệm và các sản phẩm thực thụ. Khi mới bắt đầu, tôi đánh giá dựa trên "cảm giác" (vibe). Tôi sẽ đọc năm kết quả đầu ra, gật đầu tán thành và tiếp tục. Điều đó có vẻ ổn cho đến khi người dùng đặt câu hỏi thứ sáu và nhận được một thứ gì đó kỳ lạ.
Giờ đây, tôi xây dựng các bộ đánh giá nhỏ cho mọi tính năng. Tôi thu thập các truy vấn thực tế của người dùng, gắn nhãn hành vi mong đợi và chạy các kiểm tra tự động đối với chúng. Tôi theo dõi sự trôi dạt (drift): một prompt hoạt động tốt vào tháng trước có thể bị giảm chất lượng sau một bản cập nhật mô hình hoặc sau khi dữ liệu nền thay đổi. Tôi tách biệt việc đánh giá phong cách khỏi độ chính xác về mặt sự thật. Trông chuyên nghiệp thì tốt; nhưng phải chính xác mới là bắt buộc. Nếu không có vòng lặp này, bạn đang tung ra sản phẩm dựa trên hy vọng, mà hy vọng thì không phải là một chiến lược kiểm thử.
Hiểu rõ giới hạn của máy móc
Hiểu rõ các giới hạn của mô hình đã giúp tôi tránh được việc hứa hẹn quá nhiều nhưng thực hiện không tới. Các hệ thống này có những hạn chế thực sự. Cửa sổ ngữ cảnh (context windows) đã lớn hơn trước, nhưng chúng vẫn có giới hạn, và việc nhồi nhét quá đầy sẽ làm giảm hiệu suất ở các phần biên. Các mô hình hay gặp hiện tượng ảo giác (hallucinate), đặc biệt là ở các chủ đề ngách nơi dữ liệu huấn luyện còn mỏng. Chúng gặp khó khăn với các phép tính số học chính xác và một số loại logic đa bước. Chúng cũng rất nhạy cảm với cách diễn đạt.
Chi phí và tốc độ cũng là những giới hạn. Một mô hình tạo ra văn bản hoàn hảo trong mười giây có thể không dùng được trong giao diện chat thời gian thực. Giờ đây, tôi luôn phân bổ các tính năng vào ngân sách độ trễ (latency budgets) ngay từ đầu. Nếu một tác vụ cần phản hồi dưới một giây, tôi có thể tính toán trước câu trả lời, sử dụng bộ nhớ đệm (cache) một cách triệt để, hoặc dùng một mô hình nhỏ hơn cho bản thảo đầu tiên và chỉ dùng mô hình lớn hơn để tinh chỉnh. Làm việc trong các khuôn khổ giới hạn là kỹ thuật tiêu chuẩn. AI cũng không ngoại lệ.
Xây dựng cho người dùng thực tế
Tôi hiện đang nghiên cứu các ứng dụng LLM và kỹ thuật phần mềm với một mục tiêu đơn giản: xây dựng những công cụ mà mọi người sử dụng hàng ngày. Nghe có vẻ hiển nhiên, nhưng khoảng cách giữa một bản mẫu (prototype) thú vị và một công cụ dùng hàng ngày là rất lớn. Một bản demo có thể chấp nhận việc tạm dừng 40 giây và một câu trả lời dài dòng. Nhưng một người đang cố gắng hoàn thành công việc trước cuộc họp thì không thể.
Các công cụ dùng hàng ngày cần có khả năng xử lý lỗi, các phương án dự phòng (fallbacks) và giao diện người dùng (UI) rõ ràng khi mô hình không chắc chắn. Chúng cần tích hợp vào các quy trình làm việc (workflows) hiện có thay vì ép buộc các quy trình mới. Giờ đây tôi luôn nghĩ về các trường hợp biên (edge cases): điều gì xảy ra khi mô hình từ chối trả lời, khi ngữ cảnh bị tràn, hoặc khi API hết thời gian chờ (timeout)? Phát hành phần mềm AI đồng nghĩa với việc trả lời những câu hỏi đó bằng mã nguồn, chứ không chỉ bằng sự lạc quan.
Hãy cùng chia sẻ những gì chúng ta học được
Tôi muốn kết nối với các nhà phát triển khác đang đi trên cùng một con đường. Lĩnh vực này chuyển động rất nhanh, và các phương pháp hay nhất (best practices) vẫn đang được viết tiếp. Không ai có tất cả câu trả lời. Cho dù bạn đang vật lộn với thiết kế câu lệnh (prompt design), chiến đấu với các đường ống truy xuất (retrieval pipelines), hay tìm cách đánh giá kết quả đầu ra ở quy mô lớn, thì những vấn đề này sẽ được giải quyết tốt hơn nếu làm cùng nhau.
Hãy để chúng ta chia sẻ những gì mình học được. Không phải là những bài diễn thuyết bóng bẩy tại hội nghị, mà là những giai đoạn dở dang đầy rắc rối. Những đường ống bị lỗi, những tinh chỉnh câu lệnh cuối cùng cũng hiệu quả, những bài kiểm tra đánh giá đã phát hiện ra lỗi trước khi ra mắt. Sự trao đổi chi tiết và trung thực đó chính là thứ biến những thử nghiệm cá nhân thành một kho tàng kiến thức chung.
Bài học thực sự
Nếu bạn mới bắt đầu phát triển AI, hãy dành ít thời gian hơn để tìm kiếm...
