Những điều học được khi xây dựng cùng LLM trong một năm

• Đây là một giai đoạn thú vị cho phát triển sử dụng mô hình ngôn ngữ lớn (LLM)
  • Trong 1 năm qua, LLM đã đạt đến mức "đủ tốt" cho các ứng dụng thực tế, và mỗi năm đều trở nên tốt hơn cũng như rẻ hơn
  • Cùng với các bản demo trên mạng xã hội, ước tính khoảng 200 tỷ USD sẽ được đầu tư vào AI cho đến năm 2025
  • Nhờ API của các nhà cung cấp, LLM trở nên dễ tiếp cận hơn, cho phép không chỉ kỹ sư và nhà khoa học ML mà cả mọi người xây dựng trí tuệ vào trong sản phẩm
• Rào cản gia nhập để xây dựng với AI đã thấp hơn, nhưng việc tạo ra sản phẩm và hệ thống hiệu quả vượt lên trên mức demo vẫn còn khó
• Chúng tôi đã xây dựng trong suốt 1 năm qua và đã phát hiện ra nhiều khó khăn trong quá trình đó
  • Chúng tôi muốn chia sẻ những gì đã học được để bạn có thể tránh các sai lầm của chúng tôi và lặp lại nhanh hơn
• Bài viết này gồm ba phần:
  1. Tactical (chiến thuật): một số thực hành cho prompting, RAG, workflow engineering, đánh giá và giám sát
     • Được viết cho những người thực hành xây dựng với LLM hoặc đang làm các dự án cuối tuần
  2. Operational (vận hành): các mối quan tâm mang tính tổ chức và thường nhật khi ra mắt sản phẩm, cùng cách xây dựng đội ngũ hiệu quả
     • Dành cho các lãnh đạo sản phẩm/kỹ thuật muốn triển khai bền vững và ổn định
  3. Strategic (chiến lược): góc nhìn dài hạn và bức tranh lớn cùng cách lặp lại, với các quan điểm như "không GPU trước PMF" và "tập trung vào hệ thống thay vì mô hình"
     • Được viết với nhà sáng lập và lãnh đạo điều hành trong tâm trí
• Hướng dẫn này nhằm trở thành một cẩm nang thực tiễn để xây dựng sản phẩm thành công bằng LLM
  • Nó xuất phát từ trải nghiệm của chính chúng tôi và đưa ra các ví dụ trên toàn ngành

[Chiến thuật: Cốt lõi của việc sử dụng LLM]

• Trong phần này, chúng tôi chia sẻ các thực tiễn tốt nhất cho những thành phần cốt lõi của ngăn xếp LLM mới nổi
  • Bao gồm các mẹo prompting để nâng cao chất lượng và độ tin cậy, chiến lược để đánh giá đầu ra, và các ý tưởng retrieval-augmented generation nhằm cải thiện grounding
  • Chúng tôi cũng sẽ khám phá cách thiết kế các workflow human-in-the-loop

Chiến thuật 1. Prompting

• Khi phát triển ứng dụng mới, chúng tôi khuyến nghị bắt đầu bằng prompting
  • Rất dễ đánh giá thấp hoặc đánh giá quá cao tầm quan trọng của prompting
  • Nó thường bị đánh giá thấp vì nếu áp dụng đúng các kỹ thuật prompting phù hợp, bạn có thể đi được rất xa
  • Nó cũng thường bị đánh giá quá cao vì để ứng dụng dựa trên prompt hoạt động đúng, vẫn cần rất nhiều kỹ thuật bao quanh prompt

Tập trung tận dụng tối đa các kỹ thuật prompting cơ bản

• Có một số kỹ thuật prompting liên tục giúp cải thiện hiệu năng trên nhiều mô hình và tác vụ
  • Bao gồm N-shot prompt + học trong ngữ cảnh, Chain-of-Thought, và cung cấp tài nguyên liên quan
• N-shot prompt và học trong ngữ cảnh
  • Ý tưởng của học trong ngữ cảnh thông qua N-shot prompt là cung cấp cho LLM một số ví dụ để trình diễn tác vụ và căn chỉnh đầu ra theo kỳ vọng
  • Nếu N quá thấp, mô hình có thể bị neo quá mức vào các ví dụ cụ thể đó và làm giảm khả năng khái quát hóa
  • Về mặt kinh nghiệm, hãy nhắm tới N ≥ 5, và đừng ngại dùng đến vài chục ví dụ
  • Các ví dụ nên đại diện cho phân phối đầu vào dự kiến
  • Không nhất thiết phải cung cấp đầy đủ các cặp đầu vào/đầu ra; trong nhiều trường hợp, chỉ ví dụ về đầu ra mong muốn là đủ
  • Nếu bạn đang dùng LLM hỗ trợ sử dụng công cụ, thì trong các ví dụ N-shot cũng nên dùng chính các công cụ mà bạn muốn agent sử dụng
• Prompting Chain-of-Thought (CoT)
  • Trong CoT prompting, bạn khuyến khích LLM giải thích quá trình suy nghĩ trước khi trả về câu trả lời cuối cùng
  • Có thể xem đây như việc cung cấp cho LLM một cuốn sổ nháp để nó không phải làm mọi thứ chỉ bằng bộ nhớ
  • Cách tiếp cận ban đầu chỉ đơn giản là thêm cụm từ "hãy nghĩ từng bước" vào một phần của chỉ dẫn, nhưng chúng tôi nhận thấy việc làm cho CoT cụ thể hơn sẽ hữu ích
  • Việc thêm mức độ cụ thể trong 1–2 câu thường giúp giảm đáng kể tỷ lệ phát sinh hallucination
  • Gần đây, đã có nghi vấn về việc liệu kỹ thuật này có thực sự mạnh mẽ như nhiều người tin hay không
  • Cũng có khá nhiều tranh luận về việc chính xác điều gì diễn ra trong quá trình suy luận khi CoT được sử dụng
  • Dù vậy, đây vẫn là một kỹ thuật đáng để thử nghiệm khi có thể
• Cung cấp tài nguyên liên quan
  • Cung cấp tài nguyên liên quan là một cơ chế mạnh mẽ để mở rộng nền tảng tri thức của mô hình, giảm hallucination và tăng niềm tin của người dùng
  • Điều này thường được thực hiện thông qua retrieval-augmented generation (RAG)
  • Cung cấp cho mô hình các đoạn văn bản mà nó có thể trực tiếp sử dụng trong câu trả lời là một kỹ thuật thiết yếu
  • Khi cung cấp tài nguyên liên quan, chỉ đưa chúng vào thôi là chưa đủ
    • Đừng quên chỉ dẫn mô hình ưu tiên sử dụng tài nguyên, tham chiếu trực tiếp đến chúng, và đôi khi nêu rõ khi tài nguyên là không đủ
  • Những điều này giúp "ground" phản hồi của agent vào kho tài nguyên

Cấu trúc hóa đầu vào và đầu ra

• Đầu vào và đầu ra có cấu trúc giúp mô hình hiểu đầu vào tốt hơn và trả về đầu ra có thể tích hợp ổn định với các hệ thống downstream
  • Việc thêm định dạng tuần tự hóa vào đầu vào có thể giúp làm rõ mối quan hệ giữa các token trong ngữ cảnh, thêm metadata cho các token cụ thể (như kiểu dữ liệu), hoặc liên hệ yêu cầu với các ví dụ tương tự trong dữ liệu huấn luyện của mô hình
  • Ví dụ, rất nhiều câu hỏi trên internet về việc viết SQL bắt đầu bằng cách chỉ định schema SQL
    • Vì vậy, prompting hiệu quả cho Text-to-SQL nên bao gồm định nghĩa schema có cấu trúc
• Đầu ra có cấu trúc phục vụ mục đích tương tự, nhưng đơn giản hóa việc tích hợp vào các thành phần downstream của hệ thống
  • Instructor và Outlines hoạt động tốt với đầu ra có cấu trúc
    • (dùng Instructor nếu bạn đang import SDK API của LLM, và dùng Outlines nếu bạn đang import Huggingface cho mô hình tự host)
  • Đầu vào có cấu trúc làm cho tác vụ được biểu đạt rõ ràng và giống với định dạng trong dữ liệu huấn luyện, nên làm tăng khả năng có đầu ra tốt hơn
• Khi dùng đầu vào có cấu trúc, cần lưu ý rằng mỗi họ LLM có cách ưa thích riêng
  • Claude thích <xml> trong khi GPT thích Markdown và JSON
  • Khi dùng XML, bạn cũng có thể điền sẵn phản hồi của Claude bằng cách cung cấp thẻ <response>

Hãy tạo các prompt nhỏ và làm tốt một việc

• Một anti-pattern/code smell phổ biến trong phần mềm là "God Object", tức một class hoặc hàm đơn lẻ làm tất cả mọi thứ
  • Điều này cũng áp dụng tương tự với prompt
• Prompt thường bắt đầu đơn giản
  • Bạn có thể bắt đầu với vài câu chỉ dẫn và một vài ví dụ
  • Nhưng khi cố cải thiện hiệu năng và xử lý thêm nhiều edge case, độ phức tạp sẽ tăng lên
    • Thêm nhiều chỉ dẫn hơn, suy luận nhiều bước hơn, hàng chục ví dụ, v.v.
  • Cuối cùng, prompt vốn ban đầu đơn giản lại biến thành một con quái vật Frankenstein 2.000 token
    • Hơn nữa, hiệu năng đối với các đầu vào phổ biến và trực quan hơn thậm chí còn giảm đi
    • GoDaddy xếp đây là bài học số 1 họ rút ra từ việc xây dựng với LLM
• Cũng như bạn cố giữ hệ thống và code đơn giản, prompt cũng nên như vậy
  • Thay vì dùng một prompt đa năng duy nhất cho công cụ tóm tắt bản chép cuộc họp, có thể chia thành các bước như sau
    • Trích xuất các quyết định chính, hạng mục hành động và người phụ trách dưới dạng có cấu trúc
    • Đối chiếu các chi tiết đã trích xuất với bản chép gốc để kiểm tra tính nhất quán
    • Tạo bản tóm tắt ngắn gọn từ các chi tiết có cấu trúc
• Kết quả là bạn tách một prompt duy nhất thành nhiều prompt đơn giản, tập trung và dễ hiểu hơn
  • Việc phân tách này giúp bạn có thể lặp lại và đánh giá từng prompt một cách riêng biệt

Tạo token ngữ cảnh

• Cần xem xét lại và thách thức các giả định về lượng ngữ cảnh thực sự phải gửi cho agent
  • Không phải tạc một bức tượng ngữ cảnh như Michelangelo, mà phải gọt bỏ vật liệu không cần thiết để làm lộ ra bức tượng
  • RAG là phương pháp được dùng rộng rãi để gom tất cả các khối đá cẩm thạch có khả năng liên quan, nhưng bạn đang làm gì để trích xuất đúng thứ cần thiết?
• Người viết nhận thấy rằng việc lấy prompt cuối cùng được gửi cho mô hình, đặt nó lên một trang trống cùng toàn bộ phần cấu thành ngữ cảnh, meta prompting và kết quả RAG rồi đọc lại sẽ giúp xem xét lại ngữ cảnh
  • Cách này có thể giúp phát hiện sự trùng lặp, ngôn ngữ tự mâu thuẫn và các phần định dạng sai
• Một tối ưu hóa cốt lõi khác là cấu trúc của ngữ cảnh
  • Biểu diễn kiểu bag-of-docs không hữu ích cho con người, vì vậy không nên mặc định rằng nó sẽ tốt cho agent
  • Cần cân nhắc kỹ cách tổ chức ngữ cảnh để làm nổi bật mối quan hệ giữa từng phần và giúp việc trích xuất trở nên đơn giản nhất có thể

Chiến thuật 2. Truy xuất thông tin / RAG

• Ngoài prompting, một cách hiệu quả khác để điều chỉnh LLM là cung cấp tri thức như một phần của prompt
  • Điều này giúp LLM được ground vào ngữ cảnh được cung cấp, từ đó được dùng cho học trong ngữ cảnh
  • Cách này được gọi là Retrieval-Augmented Generation (RAG)
  • Những người làm thực tế nhận thấy RAG hiệu quả trong việc cung cấp tri thức và cải thiện đầu ra, đồng thời đòi hỏi ít công sức và chi phí hơn nhiều so với fine-tuning
  • RAG chỉ tốt tương ứng với độ liên quan, mật độ thông tin và mức độ chi tiết của các tài liệu được truy xuất

Chất lượng đầu ra của RAG phụ thuộc vào chất lượng của tài liệu được truy xuất, và có một số yếu tố cần cân nhắc

• Thước đo đầu tiên và hiển nhiên nhất là "độ liên quan"
  • Điều này thường được định lượng bằng các chỉ số xếp hạng như Mean Reciprocal Rank (MRR) hoặc Normalized Discounted Cumulative Gain (NDCG)
  • MRR đánh giá mức độ hệ thống đặt kết quả liên quan đầu tiên tốt đến đâu trong danh sách xếp hạng, trong khi NDCG xem xét cả độ liên quan và vị trí của mọi kết quả
  • Chúng đo hiệu quả của hệ thống trong việc xếp hạng tài liệu liên quan cao hơn và tài liệu không liên quan thấp hơn
  • Ví dụ, nếu truy xuất các bản tóm tắt của người dùng để tạo tóm tắt review phim, thì nên xếp hạng các review về bộ phim cụ thể đó cao hơn và loại bỏ review của các phim khác
  • Cũng như trong các hệ thống gợi ý truyền thống, thứ hạng của các mục được truy xuất có ảnh hưởng đáng kể đến cách LLM thực hiện tác vụ downstream
  • Để đo tác động, hãy thử chạy tác vụ dựa trên RAG khi xáo trộn các mục được truy xuất và kiểm tra xem đầu ra RAG hoạt động ra sao
• Yếu tố thứ hai là "mật độ thông tin"
  • Nếu hai tài liệu có cùng mức độ liên quan, nên ưu tiên tài liệu ngắn gọn hơn và có ít chi tiết không liên quan hơn
  • Quay lại ví dụ về phim, có thể coi kịch bản phim và toàn bộ review người dùng là liên quan theo nghĩa rộng
  • Dù vậy, các review được đánh giá cao và review biên tập có khả năng có mật độ thông tin cao hơn
• Cuối cùng, hãy cân nhắc "mức độ chi tiết" được cung cấp trong tài liệu
  • Hãy tưởng tượng bạn đang xây dựng một hệ thống RAG để sinh truy vấn SQL từ ngôn ngữ tự nhiên
    • Chỉ cung cấp schema bảng có tên cột làm ngữ cảnh có thể đã đủ
    • Nhưng nếu thêm mô tả cột và một số giá trị đại diện thì sao?
  • Chi tiết bổ sung có thể giúp LLM hiểu rõ hơn ý nghĩa của bảng và tạo ra SQL chính xác hơn

Đừng quên tìm kiếm theo từ khóa, và hãy dùng nó cho baseline cũng như truy xuất hybrid

• Vì các bản demo RAG dựa trên embedding rất phổ biến, nên rất dễ quên hoặc bỏ qua hàng chục năm nghiên cứu và các giải pháp trong lĩnh vực truy xuất thông tin
  • Dù vậy, embedding chắc chắn là một công cụ mạnh, nhưng không phải vạn năng
• Ưu điểm của tìm kiếm dựa trên từ khóa
  • Thứ nhất, embedding rất giỏi trong việc nắm bắt sự tương đồng ngữ nghĩa ở mức cao, nhưng có thể gặp khó khăn với các truy vấn cụ thể hơn, dựa trên từ khóa, chẳng hạn khi người dùng tìm theo tên (ví dụ: Ilya), từ viết tắt (ví dụ: RAG) hoặc ID (ví dụ: claude-3-sonnet)
    • Tìm kiếm dựa trên từ khóa như BM25 được thiết kế tường minh cho mục đích này
    • Người dùng đã quen với tìm kiếm từ khóa từ rất lâu nên có thể xem đó là điều hiển nhiên, và sẽ cảm thấy thất vọng nếu tài liệu họ muốn tìm không được trả về
  • Thứ hai, việc hiểu vì sao một tài liệu được truy xuất bằng tìm kiếm từ khóa là trực quan hơn
    • Vì có thể kiểm tra các từ khóa khớp với truy vấn
    • Trong khi đó, truy xuất dựa trên embedding khó diễn giải hơn
  • Thứ ba, nhờ các hệ thống như Lucene hay OpenSearch đã được tối ưu trong hàng chục năm và kiểm chứng thực tế, tìm kiếm từ khóa nhìn chung hiệu quả tính toán hơn
• Trong phần lớn trường hợp, cách tiếp cận hybrid là hiệu quả nhất
  • Dùng đối sánh từ khóa cho các kết quả khớp hiển nhiên, và dùng embedding cho từ đồng nghĩa, từ khái quát hơn, lỗi chính tả và dữ liệu đa phương thức (ví dụ: hình ảnh và văn bản)
  • Shortwave từng chia sẻ cách họ xây dựng pipeline RAG của mình, bao gồm query rewriting, tìm kiếm từ khóa + embedding, xếp hạng, v.v.

Với tri thức mới, hãy ưu tiên RAG hơn fine-tuning

• Cả RAG và fine-tuning đều có thể được dùng để tích hợp thông tin mới vào LLM và cải thiện hiệu năng cho các tác vụ cụ thể
  • Vậy nên thử cách nào trước?
• Ưu điểm của RAG
  • Nghiên cứu gần đây cho thấy RAG có thể vượt trội hơn
  • Một nghiên cứu đã đánh giá và so sánh RAG với fine-tuning không giám sát (còn gọi là continual pretraining) trên MMLU và một tập con các vấn đề thời sự
    • RAG liên tục cho hiệu năng tốt hơn fine-tuning, cả với tri thức đã gặp trong quá trình huấn luyện lẫn tri thức hoàn toàn mới
  • Một bài báo khác so sánh RAG với supervised fine-tuning trên một bộ dữ liệu nông nghiệp
    • Tương tự, mức cải thiện hiệu năng của RAG lớn hơn fine-tuning, đặc biệt nổi bật với GPT-4 (xem bảng 20 trong bài báo)
  • Ngoài cải thiện hiệu năng, RAG còn có nhiều lợi thế thực tế
    • Thứ nhất, việc giữ chỉ mục truy xuất luôn cập nhật dễ hơn và rẻ hơn so với continual pretraining hay fine-tuning
    • Thứ hai, nếu trong chỉ mục truy xuất có tài liệu có vấn đề chứa nội dung độc hại hoặc thiên lệch, có thể dễ dàng xóa hoặc chỉnh sửa tài liệu đó
  • Ngoài ra, chữ R trong RAG còn cho phép kiểm soát chi tiết hơn đối với cách truy xuất tài liệu
    • Ví dụ, nếu đang lưu trữ một hệ thống RAG cho nhiều tổ chức, có thể phân vùng chỉ mục truy xuất để mỗi tổ chức chỉ truy xuất tài liệu trong chỉ mục riêng của họ
    • Điều này giúp tránh việc vô tình làm lộ thông tin của tổ chức này cho tổ chức khác

Mô hình ngữ cảnh dài sẽ không khiến RAG trở nên vô dụng

• Khi Gemini 1.5 cung cấp cửa sổ ngữ cảnh lên tới 10 triệu token, một số người đã bắt đầu đặt câu hỏi về tương lai của RAG
  • Cửa sổ ngữ cảnh 10 triệu token khiến phần lớn các framework RAG hiện có trở nên không còn cần thiết
    • Chỉ cần đưa dữ liệu vào ngữ cảnh rồi trò chuyện với mô hình như bình thường
  • Hãy tưởng tượng điều này sẽ ảnh hưởng ra sao đến các startup, agent và dự án langchain nơi phần lớn nỗ lực kỹ thuật đang đổ vào RAG
    • Tóm gọn trong một câu: ngữ cảnh 10 triệu token sẽ giết chết RAG
• Nhu cầu lâu dài đối với RAG
  • Dù đúng là ngữ cảnh dài sẽ là bước ngoặt cho các trường hợp sử dụng như phân tích nhiều tài liệu hoặc trò chuyện với PDF, nhưng tin đồn về cái chết của RAG là phóng đại quá mức
    • Thứ nhất, ngay cả khi có cửa sổ ngữ cảnh 10 triệu token, vẫn cần một cách để chọn thông tin nào sẽ đưa vào mô hình
    • Thứ hai, ngoài các bài đánh giá kiểu luồn kim hẹp, vẫn chưa thấy dữ liệu đủ thuyết phục rằng mô hình có thể suy luận hiệu quả trên ngữ cảnh lớn đến vậy
    • Vì thế, nếu không có truy xuất tốt (và xếp hạng), bạn có nguy cơ làm mô hình quá tải bằng thông tin gây phân tán chú ý, hoặc thậm chí lấp đầy cửa sổ ngữ cảnh bằng thông tin hoàn toàn không liên quan
• Cuối cùng là vấn đề chi phí
  • Chi phí suy luận của Transformer tăng theo bình phương của độ dài ngữ cảnh (hoặc tăng tuyến tính cả về không gian lẫn thời gian)
  • Việc tồn tại một mô hình có thể đọc toàn bộ nội dung Google Drive của tổ chức không có nghĩa là nên làm vậy trước khi trả lời mọi câu hỏi
  • Hãy thử nghĩ theo phép so sánh với cách dùng RAM
    • Có những instance tính toán với RAM lên tới hàng chục terabyte, nhưng ta vẫn đọc và ghi từ đĩa
• Vì vậy, đừng vội vứt RAG vào sọt rác
  • Mẫu này vẫn sẽ hữu ích khi kích thước cửa sổ ngữ cảnh tiếp tục tăng

Chiến thuật 3. Tinh chỉnh và tối ưu hóa workflow

• Đưa prompt cho LLM mới chỉ là điểm khởi đầu
  • Để tận dụng tối đa LLM, cần vượt ra ngoài một prompt đơn lẻ và chấp nhận workflow
  • Ví dụ, có thể chia một tác vụ đơn phức tạp thành nhiều tác vụ đơn giản hơn như thế nào?
  • Khi nào fine-tuning hoặc caching sẽ giúp tăng hiệu năng và giảm độ trễ/chi phí?
• Phần này chia sẻ các chiến lược đã được kiểm chứng và ví dụ thực tế để giúp tối ưu và xây dựng workflow LLM

“Flow” nhiều bước, nhiều lượt có thể mang lại cải thiện hiệu năng lớn

• Chúng ta đã biết rằng có thể đạt kết quả tốt hơn bằng cách tách một prompt lớn thành nhiều prompt nhỏ
  • AlphaCodium là một ví dụ
    • Bằng cách chuyển từ một prompt đơn sang workflow nhiều bước, họ đã nâng độ chính xác GPT-4 (pass@5) trên CodeContests từ 19% lên 44%
  • Workflow bao gồm
    • Suy ngẫm về bài toán
    • Suy luận về các bài test công khai
    • Tạo các lời giải khả dĩ
    • Xếp hạng các lời giải khả dĩ
    • Tạo test tổng hợp
    • Lặp lại lời giải trên cả test công khai và test tổng hợp
• Những tác vụ nhỏ với mục tiêu rõ ràng tạo nên prompt agent hoặc flow tốt nhất
  • Không phải mọi prompt agent đều cần yêu cầu đầu ra có cấu trúc, nhưng đầu ra có cấu trúc rất hữu ích cho giao diện với hệ thống điều phối tương tác giữa agent và môi trường
• Những điều đáng thử
  • Bước lập kế hoạch tường minh được chỉ định càng chặt chẽ càng tốt
    • Hãy cân nhắc việc chọn từ các kế hoạch được định nghĩa sẵn
  • Viết lại prompt người dùng ban đầu thành prompt agent
    • Hãy cẩn thận vì quá trình này có thể làm mất thông tin
  • Hành vi agent dưới dạng chuỗi tuyến tính, DAG và máy trạng thái
    • Các phụ thuộc và quan hệ logic khác nhau có thể phù hợp hoặc kém phù hợp hơn ở những quy mô khác nhau
    • Liệu có thể khai thác tối ưu hiệu năng từ các kiến trúc tác vụ khác nhau không?
  • Xác minh kế hoạch
    • Kế hoạch có thể bao gồm hướng dẫn về cách đánh giá phản hồi từ các agent khác để bảo đảm đầu ra cuối cùng hoạt động tốt
  • Prompt engineering với trạng thái upstream cố định
    • Hãy bảo đảm prompt agent được đánh giá trước các biến thể khác nhau có thể xảy ra ở các bước trước đó

Hiện tại, hãy ưu tiên workflow mang tính quyết định

• AI agent có thể phản ứng động với yêu cầu người dùng và môi trường, nhưng bản chất không quyết định của chúng khiến việc triển khai trở nên khó khăn
  • Mỗi bước mà agent thực hiện đều có khả năng thất bại, và khả năng phục hồi sau lỗi là thấp
  • Vì vậy, xác suất agent hoàn thành thành công một tác vụ nhiều bước giảm theo cấp số nhân khi số bước tăng lên
  • Kết quả là các đội xây dựng agent gặp khó khăn trong việc triển khai agent đáng tin cậy
• Một hướng tiếp cận đầy hứa hẹn là có một hệ thống agent tạo ra kế hoạch mang tính quyết định và thực thi nó theo cách có cấu trúc, có thể tái lập
  • Ở bước đầu tiên, khi được cung cấp mục tiêu cấp cao hoặc prompt, agent sẽ tạo kế hoạch
  • Sau đó kế hoạch được thực thi một cách quyết định
  • Điều này giúp mỗi bước trở nên dễ dự đoán và đáng tin cậy hơn
  • Ưu điểm
    • Kế hoạch được tạo ra có thể được dùng làm mẫu few-shot để cung cấp prompt hoặc fine-tune cho agent
    • Việc thực thi mang tính quyết định giúp hệ thống đáng tin cậy hơn, từ đó kiểm thử và gỡ lỗi dễ hơn. Ngoài ra, lỗi có thể được truy vết về một bước cụ thể trong kế hoạch
    • Kế hoạch được tạo ra có thể được biểu diễn dưới dạng đồ thị có hướng không chu trình (DAG), dễ hiểu và dễ thích ứng với tình huống mới hơn so với prompt tĩnh
• Những người xây agent thành công nhất có thể là những người có kinh nghiệm mạnh trong việc quản lý kỹ sư junior
  • Vì quá trình tạo kế hoạch tương tự với cách chỉ đạo và quản lý junior
  • Cũng như khi làm việc với junior, thay vì đưa ra định hướng mơ hồ và mở, cần cung cấp mục tiêu rõ ràng và kế hoạch cụ thể; với agent cũng phải làm tương tự
• Cuối cùng, cốt lõi của một agent đáng tin cậy và thực sự hoạt động có khả năng nằm ở
  • áp dụng cách tiếp cận có cấu trúc và mang tính quyết định hơn, và
  • thu thập dữ liệu để cải thiện prompt và fine-tune mô hình
• Nếu không có điều này, bạn sẽ xây ra một agent đôi khi hoạt động rất tốt nhưng trung bình lại làm người dùng thất vọng, dẫn đến tỷ lệ giữ chân thấp

Tạo đầu ra đa dạng theo nhiều cách hơn là chỉ dùng tham số nhiệt độ

• Giả sử có một tác vụ cần sự đa dạng trong đầu ra của LLM
  • Có thể bạn đang viết một pipeline LLM để đề xuất sản phẩm nên mua từ catalog, có xét đến danh sách sản phẩm mà người dùng đã mua trước đó
  • Bạn có thể nhận ra rằng khi chạy prompt nhiều lần, các đề xuất trả về quá giống nhau
  • Vì vậy, bạn có thể tăng tham số Temperature (nhiệt độ) của yêu cầu LLM
• Khi tăng tham số nhiệt độ, phản hồi của LLM sẽ đa dạng hơn
  • Khi lấy mẫu, phân phối xác suất của token tiếp theo trở nên phẳng hơn, khiến các token vốn ít có khả năng được chọn hơn lại xuất hiện thường xuyên hơn
• Tuy nhiên, khi tăng nhiệt độ có thể xuất hiện một số kiểu lỗi liên quan đến tính đa dạng của đầu ra
  • Ví dụ, một số sản phẩm trong catalog có thể phù hợp nhưng lại không được LLM đưa ra
  • Nếu LLM có xu hướng làm theo những gì nó đã học trong quá trình huấn luyện hơn là bám sát prompt, cùng một nhóm nhỏ sản phẩm có thể bị đại diện quá mức trong đầu ra
  • Nếu nhiệt độ quá cao, đầu ra có thể tham chiếu đến những sản phẩm không tồn tại (hoặc nội dung vô nghĩa)
• Việc tăng nhiệt độ không đảm bảo rằng LLM sẽ lấy mẫu đầu ra từ phân phối xác suất mà bạn kỳ vọng, chẳng hạn như ngẫu nhiên đồng đều
• Dù vậy, vẫn có những mẹo khác để tăng tính đa dạng của đầu ra
  • Cách đơn giản nhất là điều chỉnh các thành phần trong prompt
    • Ví dụ, nếu template prompt có danh sách các mục như lịch sử mua hàng, thì việc xáo trộn thứ tự mỗi lần chèn các mục này vào prompt có thể tạo ra khác biệt đáng kể
  • Ngoài ra, giữ một danh sách ngắn các đầu ra gần đây cũng giúp tránh trùng lặp
    • Trong ví dụ đề xuất sản phẩm, bạn có thể yêu cầu LLM tránh gợi ý các mục nằm trong danh sách gần đây này, hoặc làm cho phản hồi đa dạng hơn nữa bằng cách từ chối những đầu ra tương tự đề xuất gần đây rồi lấy mẫu lại
  • Một chiến lược hiệu quả khác là đa dạng hóa cách diễn đạt dùng trong prompt
    • Ví dụ, đưa vào các câu như “chọn mục mà người dùng sẽ thích sử dụng thường xuyên” hoặc “chọn sản phẩm mà người dùng có khả năng giới thiệu cho bạn bè” có thể làm dịch chuyển trọng tâm và ảnh hưởng đến độ đa dạng của các sản phẩm được đề xuất

Caching đang bị đánh giá thấp

• Bộ nhớ đệm giúp giảm chi phí và loại bỏ độ trễ sinh nội dung bằng cách không cần tính toán lại phản hồi cho cùng một đầu vào
  • Ngoài ra, nếu phản hồi trước đó đã được áp dụng guardrail, có thể cung cấp lại các phản hồi đã được xác thực này để giảm rủi ro tạo ra nội dung độc hại hoặc không phù hợp
• Một cách tiếp cận đơn giản với bộ nhớ đệm là dùng một ID duy nhất cho mục đang được xử lý, chẳng hạn khi tóm tắt bài viết mới hoặc bài đánh giá sản phẩm
  • Khi có yêu cầu, có thể kiểm tra xem bản tóm tắt đã tồn tại trong bộ nhớ đệm hay chưa
    • Nếu có thì có thể trả về ngay, nếu không thì tạo, áp dụng guardrail và cung cấp, sau đó lưu vào bộ nhớ đệm cho các yêu cầu trong tương lai
• Với các truy vấn mở hơn, có thể mượn các kỹ thuật từ lĩnh vực tìm kiếm để tận dụng bộ nhớ đệm ngay cả với đầu vào mở
  • Các tính năng như tự động hoàn thành và sửa chính tả giúp chuẩn hóa đầu vào của người dùng để tăng tỷ lệ cache hit

Khi nào cần finetune (fine-tuning)

• Có thể có những tác vụ mà ngay cả prompt được thiết kế khéo léo nhất cũng vẫn chưa đủ
  • Ví dụ, ngay cả sau một lượng prompt engineering đáng kể, hệ thống vẫn có thể còn xa mới trả về đầu ra đáng tin cậy và chất lượng cao
  • Trong trường hợp đó, có thể cần fine-tune mô hình cho tác vụ cụ thể
• Các trường hợp fine-tuning thành công
  • Natural Language Query Assistant của Honeycomb
    • Ban đầu, một “sổ tay lập trình” được đưa vào prompt cùng với các ví dụ n-shot cho in-context learning
    • Cách này hoạt động ổn, nhưng khi fine-tune mô hình thì có thể đạt được đầu ra tốt hơn về cú pháp và quy tắc của ngôn ngữ đặc thù miền
  • Lucy của Rechat
    • LLM phải tạo phản hồi theo một định dạng rất cụ thể, kết hợp dữ liệu có cấu trúc và phi cấu trúc để frontend có thể render chính xác
    • Fine-tuning là yếu tố thiết yếu để điều này hoạt động ổn định
• Fine-tuning có thể hiệu quả nhưng đi kèm chi phí đáng kể
  • Cần gán nhãn dữ liệu fine-tuning, fine-tune và đánh giá mô hình, rồi cuối cùng tự host
  • Vì vậy cần cân nhắc liệu chi phí ban đầu cao hơn có xứng đáng hay không
• Nếu có thể đạt 90% bằng prompting, thì có thể không đáng để đầu tư vào fine-tuning
  • Tuy nhiên, nếu quyết định fine-tune, có thể tạo và fine-tune trên dữ liệu tổng hợp hoặc bootstrap từ dữ liệu mã nguồn mở để giảm chi phí thu thập dữ liệu được con người gán nhãn

Chiến thuật 4. Đánh giá và giám sát

• Đánh giá LLM có thể là một bãi mìn
  • Đầu vào và đầu ra của LLM là văn bản tùy ý, và các tác vụ được thiết lập cũng rất đa dạng
  • Dù vậy, đánh giá nghiêm ngặt và cẩn trọng vẫn rất quan trọng
    • Không phải ngẫu nhiên mà các lãnh đạo kỹ thuật của OpenAI tham gia vào việc đánh giá và đưa phản hồi cho từng bài đánh giá riêng lẻ
• Việc đánh giá ứng dụng LLM đòi hỏi nhiều cách định nghĩa và quy giản khác nhau
  • Nó có thể đơn giản là unit test, hoặc giống với observability hơn, hoặc đơn thuần là khoa học dữ liệu
  • Chúng tôi nhận thấy tất cả các góc nhìn này đều hữu ích
• Trong phần này, bài viết đưa ra những bài học rút ra về các yếu tố quan trọng khi xây dựng pipeline đánh giá và giám sát

Tạo một vài unit test dựa trên assertion từ các mẫu đầu vào/đầu ra thực tế

• Tạo các unit test (tức assertion) từ các mẫu đầu vào và đầu ra trong production, đồng thời đặt kỳ vọng cho đầu ra theo ít nhất 3 tiêu chí
  • 3 tiêu chí có thể trông có vẻ tùy ý, nhưng là một con số thực tế để bắt đầu
    • Nếu ít hơn, có thể tác vụ chưa được định nghĩa đủ rõ hoặc quá mở, như chatbot đa dụng
  • Các unit test hoặc assertion này nên được kích hoạt bởi những thay đổi trong pipeline, chẳng hạn chỉnh sửa prompt, thêm ngữ cảnh mới qua RAG, hoặc các sửa đổi khác
• Hãy cân nhắc bắt đầu với các assertion quy định những cụm từ hoặc ý tưởng phải có hoặc không được có trong mọi phản hồi
  • Cũng nên cân nhắc các kiểm tra xem số lượng từ, mục hoặc câu có nằm trong phạm vi hay không
  • Với các kiểu sinh nội dung khác, assertion có thể trông khác đi
    • Ví dụ, trong đánh giá thực thi, một cách mạnh để đánh giá sinh mã, người ta chạy đoạn mã được tạo ra và kiểm tra xem trạng thái runtime có đáp ứng đầy đủ yêu cầu của người dùng hay không
• Ví dụ, nếu người dùng yêu cầu một hàm mới tên là foo, thì sau khi chạy đoạn mã do agent sinh ra, phải có thể gọi được foo
• Một thách thức của đánh giá thực thi là mã của agent thường để lại runtime ở trạng thái hơi khác so với mã mục tiêu
  • Có thể hiệu quả khi “nới lỏng” assertion về mức giả định yếu nhất nhưng vẫn đủ để thỏa mãn bất kỳ câu trả lời hợp lệ nào
• Việc sử dụng sản phẩm đúng như cách khách hàng dự kiến sẽ dùng (tức “dogfooding”) có thể mang lại hiểu biết về các failure mode trên dữ liệu thực tế
  • Cách tiếp cận này không chỉ giúp xác định các điểm yếu tiềm ẩn mà còn cung cấp nguồn mẫu production hữu ích có thể chuyển thành đánh giá

LLM-as-Judge có thể hoạt động (ở một mức độ nào đó) nhưng không phải vạn năng

• LLM-as-Judge là cách dùng một LLM mạnh để đánh giá đầu ra của LLM khác, và bị một số người đón nhận với sự hoài nghi
• Dù vậy, nếu được triển khai tốt, LLM-as-Judge có thể đạt được mức tương quan đáng kể với phán đoán của con người, và ít nhất có thể giúp xây dựng thông tin ban đầu về cách một prompt hay kỹ thuật mới có thể hoạt động
  • Đặc biệt khi so sánh theo cặp (ví dụ: đối chứng so với thử nghiệm), LLM-as-Judge thường xác định đúng hướng, dù độ lớn thắng/thua có thể nhiễu
• Các đề xuất để tận dụng tối đa LLM-as-Judge
  • Dùng so sánh theo cặp
    • Thay vì yêu cầu LLM đánh giá một đầu ra đơn lẻ theo thang Likert, hãy đưa ra hai lựa chọn và yêu cầu chọn phương án tốt hơn
    • Cách này có xu hướng cho kết quả ổn định hơn
  • Kiểm soát thiên lệch vị trí
    • Thứ tự các lựa chọn được đưa ra có thể làm lệch quyết định của LLM
    • Để giảm tác động này, hãy chạy mỗi phép so sánh cặp hai lần và đảo thứ tự cặp ở mỗi lần
    • Sau khi hoán đổi, cần quy chiến thắng về đúng lựa chọn
  • Cho phép hòa
    • Trong một số trường hợp, hai lựa chọn có thể tốt ngang nhau
    • Vì vậy nên cho phép LLM tuyên bố hòa để không phải chọn ngẫu nhiên người thắng
  • Dùng Chain-of-Thought
    • Nếu yêu cầu LLM giải thích quyết định trước khi đưa ra lựa chọn cuối cùng, độ tin cậy của đánh giá có thể được cải thiện
    • Một lợi ích thêm là nhờ đó có thể dùng LLM yếu hơn nhưng nhanh hơn mà vẫn đạt kết quả tương tự
    • Vì phần này của pipeline thường chạy ở chế độ batch, nên độ trễ bổ sung do CoT không phải vấn đề lớn
  • Kiểm soát độ dài phản hồi
    • LLM có xu hướng nghiêng về các phản hồi dài hơn
    • Để giảm điều này, hãy đảm bảo độ dài của cặp phản hồi là tương đương nhau
• Một ứng dụng đặc biệt mạnh của LLM-as-Judge là kiểm tra hồi quy cho các chiến lược prompt mới
  • Nếu đã theo dõi một tập hợp kết quả production, đôi khi có thể chạy lại các ví dụ production đó với chiến lược prompt mới và dùng LLM-as-Judge để nhanh chóng đánh giá những nơi chiến lược mới có thể gặp khó khăn
• Một ví dụ về cách tiếp cận đơn giản nhưng hiệu quả với LLM-as-Judge
  • Chỉ cần ghi lại phản hồi của LLM, phần phê bình của giám khảo (tức CoT) và kết quả cuối cùng
  • Sau đó cùng các bên liên quan xem xét để xác định các lĩnh vực cần cải thiện
  • Sau 3 vòng lặp, mức độ nhất quán giữa con người và LLM đã tăng từ 68% lên 94%
• Tuy nhiên, LLM-as-Judge không phải vạn năng
  • Ngay cả những mô hình mạnh nhất cũng có những khía cạnh ngôn ngữ tinh tế mà chúng không thể đánh giá một cách đáng tin cậy
• Ngoài ra, chúng tôi nhận thấy các bộ phân loại và reward model truyền thống có thể đạt độ chính xác cao hơn LLM-as-Judge, đồng thời có chi phí và độ trễ thấp hơn
  • Đối với sinh mã, LLM-as-Judge có thể yếu hơn các chiến lược đánh giá trực tiếp hơn như đánh giá thực thi

“Bài kiểm tra thực tập sinh” để đánh giá kết quả sinh nội dung

• Khi đánh giá kết quả sinh, nên dùng một kiểu "bài kiểm tra thực tập sinh" như sau
  • Nếu lấy đúng đầu vào cho mô hình ngôn ngữ kèm theo ngữ cảnh và giao thành bài tập cho một sinh viên đại học mức trung bình thuộc chuyên ngành liên quan, liệu họ có làm được không?
  • Sẽ mất bao lâu?
• Nếu câu trả lời là không
  • Nếu do thiếu kiến thức cần thiết cho LLM, hãy cân nhắc cách làm phong phú thêm ngữ cảnh
  • Nếu cải thiện ngữ cảnh mà vẫn không giải quyết được, đó có thể là tác vụ quá khó với các LLM hiện đại
• Nếu câu trả lời là có nhưng mất thời gian
  • Có thể thử giảm độ phức tạp của tác vụ
    • Có thể tách nhỏ không?
    • Khía cạnh nào của tác vụ có thể được mẫu hóa hơn nữa?
• Nếu câu trả lời là có và có thể làm nhanh
  • Khi đào sâu vào dữ liệu
    • Mô hình đang làm sai điều gì?
    • Có thể tìm ra các mẫu thất bại không?
  • Thử yêu cầu mô hình tự giải thích trước hoặc sau khi trả lời

Quá tập trung vào một phép đánh giá cụ thể có thể làm giảm hiệu năng tổng thể

"Khi một chỉ số đo lường trở thành mục tiêu, nó sẽ không còn là một chỉ số đo lường tốt nữa." - định luật Goodhart

• Một ví dụ cho điều này là phép đánh giá Needle-in-a-Haystack (NIAH)
  • Ban đầu, phép đánh giá này giúp định lượng khả năng hồi tưởng của mô hình khi kích thước ngữ cảnh tăng lên và kiểm tra vị trí của "cây kim" ảnh hưởng đến mức độ hồi tưởng ra sao
  • Tuy nhiên, nó đã được nhấn mạnh quá mức đến mức xuất hiện dưới dạng Figure 1 trong báo cáo Gemini 1.5
  • Phép đánh giá này bao gồm việc chèn một cụm từ cụ thể ("The special magic {city} number is: {number}") vào một tài liệu dài lặp lại các bài luận của Paul Graham, sau đó yêu cầu mô hình nhớ lại con số ma thuật
• Một số mô hình đạt mức hồi tưởng gần như hoàn hảo, nhưng vẫn có câu hỏi liệu NIAH có thực sự phản ánh năng lực suy luận và hồi tưởng cần thiết trong ứng dụng thực tế hay không
• Hãy xem xét các kịch bản thực tế hơn
  • Nếu được cung cấp bản chép lời của một cuộc họp kéo dài 1 giờ, liệu LLM có thể tóm tắt các quyết định chính và các bước tiếp theo, đồng thời gán đúng từng mục cho người phụ trách liên quan không?
  • Tác vụ này thực tế hơn vì không chỉ vượt ra ngoài việc ghi nhớ đơn thuần mà còn xét đến khả năng nắm bắt thảo luận phức tạp, xác định thông tin liên quan và tổng hợp bản tóm tắt
• Ví dụ về một phép đánh giá NIAH thực dụng
  • Dùng bản chép lời cuộc gọi video bác sĩ-bệnh nhân để hỏi LLM về thuốc của bệnh nhân
  • Cũng bao gồm NIAH khó hơn, chẳng hạn chèn các cụm từ về nguyên liệu ngẫu nhiên cần cho topping pizza như chà là ngâm espresso, chanh và phô mai dê
  • Ở tác vụ thuốc, mức hồi tưởng khoảng 80%, còn ở tác vụ pizza là 30%
• Quá nhấn mạnh phép đánh giá NIAH có thể làm giảm hiệu năng ở các tác vụ trích xuất và tóm tắt
  • Vì các LLM như vậy được tinh chỉnh để chú ý đến mọi câu, chúng có thể bắt đầu coi cả chi tiết không liên quan và yếu tố gây xao nhãng là quan trọng
  • Khi đó, những thứ này có thể xuất hiện trong đầu ra cuối cùng (ngay cả khi lẽ ra không nên!)
• Điều này cũng có thể áp dụng cho các phép đánh giá và trường hợp sử dụng khác
  • Ví dụ như tóm tắt
    • Nếu nhấn mạnh tính nhất quán thực tế, mô hình có thể tạo ra các bản tóm tắt kém cụ thể hơn (và do đó ít có khả năng sai sự thật hơn) nhưng cũng kém liên quan hơn
    • Ngược lại, nếu nhấn mạnh phong cách viết và sự hùng biện, mô hình có thể tạo ra thứ ngôn ngữ kiểu marketing bóng bẩy hơn nhưng dễ dẫn đến sai lệch thực tế

Đơn giản hóa việc gán nhãn thành tác vụ nhị phân hoặc so sánh theo cặp

• Việc đưa ra phản hồi mở hoặc chấm điểm theo thang Likert cho đầu ra của mô hình là một việc đòi hỏi nhận thức cao
  • Kết quả là dữ liệu thu thập được trở nên nhiễu hơn do sự biến thiên giữa các đánh giá viên con người, và vì vậy kém hữu ích hơn
• Cách tiếp cận hiệu quả hơn là đơn giản hóa tác vụ và giảm gánh nặng nhận thức cho người gán nhãn
  • Hai loại tác vụ hoạt động tốt là phân loại nhị phân và so sánh theo cặp
• Trong phân loại nhị phân, người gán nhãn được yêu cầu đưa ra phán đoán đơn giản có/không về đầu ra của mô hình
  • Có thể hỏi liệu bản tóm tắt được tạo ra có nhất quán về mặt thực tế với tài liệu nguồn hay không, phản hồi đề xuất có liên quan hay không, có chứa nội dung độc hại hay không, v.v.
  • So với thang Likert, quyết định nhị phân chính xác hơn, có độ nhất quán giữa các đánh giá viên cao hơn và thông lượng cao hơn
  • Cách Doordash thiết lập hàng đợi gán nhãn để gắn thẻ các món trong thực đơn thông qua một loạt câu hỏi có/không
• Trong so sánh theo cặp (Pairwise Comparison), người gán nhãn nhận một cặp phản hồi của mô hình và được hỏi cái nào tốt hơn
  • Vì con người thấy dễ nói "A tốt hơn B" hơn là chấm điểm riêng lẻ cho A hoặc B, điều này dẫn đến việc gán nhãn nhanh hơn và đáng tin cậy hơn (so với thang Likert)
• Tại meetup về Llama2, Thomas Scialom, một trong các tác giả của bài báo Llama2, đã xác nhận rằng so sánh theo cặp nhanh và rẻ hơn việc thu thập dữ liệu tinh chỉnh có giám sát như các phản hồi được viết sẵn
  • Loại đầu tiên có chi phí $3.5 mỗi đơn vị, còn loại sau là $25 mỗi đơn vị

Đánh giá không cần tham chiếu (reference-free) và guardrail có thể được dùng thay thế cho nhau

• Guardrail giúp chặn nội dung không phù hợp hoặc độc hại, trong khi đánh giá giúp đo chất lượng và độ chính xác của đầu ra mô hình
  • Với các đánh giá không cần tham chiếu, có thể xem chúng là hai mặt của một đồng xu
    • Đánh giá không cần tham chiếu là kiểu đánh giá có thể chấm chất lượng đầu ra chỉ từ prompt đầu vào và phản hồi của mô hình, mà không phụ thuộc vào một tham chiếu "golden" như câu trả lời do con người viết
• Ví dụ về đánh giá không cần tham chiếu: đánh giá tóm tắt
  • Chỉ cần xem xét tài liệu đầu vào là có thể đánh giá tính nhất quán thực tế và mức độ liên quan của bản tóm tắt
  • Nếu bản tóm tắt có điểm thấp ở các chỉ số này, có thể chọn không hiển thị cho người dùng, tức là dùng đánh giá như một guardrail một cách hiệu quả
• Đánh giá "dịch" không cần tham chiếu:
  • Có thể đánh giá chất lượng bản dịch ngay cả khi không có bản dịch tham chiếu của con người, và vì vậy lại có thể dùng như một guardrail

LLM vẫn trả về đầu ra ngay cả khi lẽ ra không nên

• Một thách thức lớn khi làm việc với LLM là chúng thường vẫn tạo đầu ra ngay cả khi không nên
  • Điều này có thể dẫn đến các phản hồi vô hại nhưng vô nghĩa, hoặc những lỗi nghiêm trọng hơn như nội dung độc hại hay nguy hiểm
  • Ví dụ, khi được yêu cầu trích xuất một thuộc tính hoặc metadata cụ thể từ tài liệu, LLM có thể tự tin trả về một giá trị ngay cả khi giá trị đó thực sự không tồn tại
  • Hoặc mô hình có thể trả lời bằng ngôn ngữ không phải tiếng Anh vì ngữ cảnh được cung cấp là tài liệu không phải tiếng Anh
• Có thể viết prompt để LLM trả về "không áp dụng" hoặc "không biết", nhưng điều này không hoàn hảo
  • Ngay cả khi có thể dùng log probability, đây cũng là chỉ báo kém về chất lượng đầu ra
    • Log probability biểu thị khả năng một token xuất hiện trong đầu ra, nhưng không phản ánh độ chính xác của văn bản được tạo ra
  • Thậm chí, với các mô hình instruction-tuned được huấn luyện để trả lời truy vấn và tạo phản hồi mạch lạc, log probability có thể không được hiệu chỉnh tốt
    • Vì vậy, log probability cao có thể chỉ cho thấy đầu ra trôi chảy và nhất quán, chứ không có nghĩa là chính xác hay liên quan
• Prompt engineering cẩn thận có thể giúp ở một mức độ nào đó, nhưng nên được bổ sung bằng các guardrail mạnh để phát hiện và lọc/tái sinh đầu ra không mong muốn
  • Ví dụ, OpenAI cung cấp API kiểm duyệt nội dung có thể nhận diện các phản hồi không an toàn như phát ngôn thù ghét, tự hại bản thân hoặc đầu ra mang tính tình dục
  • Tương tự, có rất nhiều package để phát hiện thông tin nhận dạng cá nhân (PII)
• Một lợi thế của guardrail là chúng phần lớn không phụ thuộc vào trường hợp sử dụng, vì vậy có thể được áp dụng rộng rãi cho mọi đầu ra bằng một ngôn ngữ nhất định
  • Ngoài ra, với truy xuất đủ chính xác, nếu không có tài liệu liên quan thì hệ thống có thể dứt khoát trả lời "Tôi không biết"
• LLM cũng có thể không tạo đầu ra ngay cả khi đầu ra được mong đợi
  • Điều này có thể xảy ra vì nhiều lý do, từ vấn đề đơn giản như độ trễ dài của nhà cung cấp API đến các vấn đề phức tạp hơn như đầu ra bị chặn bởi bộ lọc kiểm duyệt nội dung
• Vì vậy, điều quan trọng là phải ghi log đầu vào một cách nhất quán để phục vụ gỡ lỗi và giám sát, cùng với cả việc thiếu đầu ra (nếu có)

Ảo giác (Hallucination) là một vấn đề dai dẳng

• Trong khi các lỗi về an toàn nội dung hoặc PII nhận được rất nhiều sự chú ý nên hiếm khi xảy ra, thì các sai lệch thực tế lại dai dẳng và khó phát hiện hơn
  • Chúng xảy ra phổ biến hơn nhiều, với tỷ lệ nền khoảng 5–10%, và theo những gì học được từ các nhà cung cấp LLM, có thể rất khó hạ xuống dưới 2% ngay cả với các tác vụ đơn giản như tóm tắt
• Để giải quyết điều này, có thể kết hợp kỹ thuật prompt (ở thượng nguồn giai đoạn sinh) với guardrail cho sai lệch thực tế (ở hạ nguồn giai đoạn sinh)
  • Với kỹ thuật prompt, các kỹ thuật như CoT giúp giảm ảo giác bằng cách buộc LLM giải thích suy luận trước khi trả về đầu ra cuối cùng
  • Sau đó có thể áp dụng guardrail cho sai lệch thực tế để đánh giá tính đúng thực tế của bản tóm tắt, đồng thời lọc bỏ hoặc tạo lại các nội dung ảo giác
• Trong một số trường hợp, ảo giác có thể được phát hiện một cách tất định
  • Khi sử dụng tài nguyên từ truy xuất RAG, nếu đầu ra có cấu trúc và xác định được tài nguyên là gì, thì về nguyên tắc phải có thể kiểm tra thủ công xem nó có được lấy từ ngữ cảnh đầu vào hay không

[Vận hành: công việc hằng ngày (Day-to-Day) và các vấn đề tổ chức ]

Vận hành 1. Dữ liệu

• Cũng như chất lượng nguyên liệu quyết định hương vị món ăn, chất lượng dữ liệu đầu vào giới hạn hiệu năng của hệ thống machine learning
• Ngoài ra, dữ liệu đầu ra là cách duy nhất để biết sản phẩm có đang hoạt động hay không
• Tất cả tác giả đều dành vài giờ mỗi tuần để xem xét kỹ đầu vào và đầu ra nhằm hiểu rõ hơn phân phối dữ liệu (các mode, edge case, giới hạn của mô hình)

Kiểm tra độ lệch dev-production

• Trong các pipeline machine learning truyền thống, một nguyên nhân lỗi phổ biến là training-serving skew
  • Điều này xảy ra khi dữ liệu dùng để huấn luyện khác với dữ liệu mà mô hình gặp trong production
• Vì có thể dùng LLM mà không cần huấn luyện hay fine-tuning, nên không có tập huấn luyện, nhưng lại nảy sinh một vấn đề tương tự là độ lệch dữ liệu giữa giai đoạn phát triển và production
  • Về cơ bản, dữ liệu dùng để kiểm thử hệ thống trong quá trình phát triển phải phản ánh dữ liệu mà hệ thống sẽ gặp trong production
    • Nếu không, độ chính xác trong production có thể suy giảm
• Độ lệch dev-production của LLM có thể được chia thành hai loại: độ lệch cấu trúc và độ lệch dựa trên nội dung
  • Độ lệch cấu trúc bao gồm các vấn đề như không khớp định dạng, chẳng hạn khác biệt giữa JSON dictionary có giá trị dạng danh sách và JSON list, viết hoa không nhất quán, hoặc các lỗi như typo hay mảnh câu
    • Những lỗi này có thể dẫn đến hiệu năng mô hình khó đoán vì nhiều LLM được huấn luyện trên các định dạng dữ liệu cụ thể và prompt có thể rất nhạy với những thay đổi nhỏ
  • Độ lệch dựa trên nội dung, hay “ngữ nghĩa”, đề cập đến sự khác biệt về ý nghĩa hoặc ngữ cảnh của dữ liệu
• Tương tự ML truyền thống, việc định kỳ đo độ lệch giữa các cặp đầu vào/đầu ra của LLM là hữu ích
  • Các chỉ số đơn giản như độ dài đầu vào và đầu ra hoặc các yêu cầu định dạng cụ thể (ví dụ: JSON hoặc XML) là cách dễ theo dõi thay đổi
• Để phát hiện độ lệch “nâng cao” hơn, hãy cân nhắc gom cụm embedding của các cặp đầu vào/đầu ra nhằm phát hiện độ lệch ngữ nghĩa, chẳng hạn sự thay đổi trong các chủ đề người dùng bàn luận, điều có thể cho thấy người dùng đang khám phá những vùng mà mô hình chưa từng được tiếp xúc trước đó
• Khi kiểm thử các thay đổi như kỹ thuật prompt, hãy bảo đảm tập dữ liệu holdout luôn được cập nhật và phản ánh các kiểu tương tác người dùng mới nhất
  • Ví dụ, nếu typo là phổ biến trong đầu vào production thì tập holdout cũng nên có
• Ngoài việc chỉ đo độ lệch bằng con số, việc thực hiện đánh giá định tính đối với đầu ra cũng có ích
  • Việc xem xét đầu ra của mô hình một cách định kỳ (thực hành thường được gọi là “vibe check”) giúp xác nhận rằng kết quả phù hợp với kỳ vọng và vẫn liên quan đến nhu cầu người dùng
• Cũng hữu ích khi đưa tính không tất định vào việc kiểm tra độ lệch
  • Bằng cách chạy pipeline nhiều lần cho mỗi đầu vào trong tập dữ liệu kiểm thử và phân tích mọi đầu ra, bạn có nhiều khả năng bắt được những bất thường chỉ thỉnh thoảng mới xuất hiện

Kiểm tra mẫu đầu vào/đầu ra LLM mỗi ngày

• LLM có tính động và liên tục tiến hóa
  • Dù có năng lực zero-shot ấn tượng và đầu ra thường dễ chịu, các chế độ thất bại của LLM lại rất khó dự đoán
• Với các tác vụ tùy biến, việc thường xuyên xem xét các mẫu dữ liệu là thiết yếu để xây dựng hiểu biết trực quan về hiệu năng của LLM
  • Các cặp đầu vào/đầu ra trong production là “vật thật, nơi thật” (genchi genbutsu) của ứng dụng LLM và không gì thay thế được
• Nghiên cứu gần đây nhấn mạnh rằng khi nhà phát triển tương tác với nhiều dữ liệu hơn, nhận thức của họ về đầu ra “tốt” và “xấu” sẽ thay đổi (tức là criteria drift)
  • Nhà phát triển có thể đưa ra trước một số tiêu chí để đánh giá đầu ra của LLM, nhưng các tiêu chí được định nghĩa sẵn này thường không đầy đủ
• Ví dụ, trong quá trình phát triển, có thể cập nhật prompt để tăng xác suất có phản hồi tốt và giảm xác suất có phản hồi xấu
  • Quy trình lặp gồm đánh giá, đánh giá lại và cập nhật tiêu chí này là cần thiết vì rất khó dự đoán hành vi của LLM hay sở thích của con người nếu không trực tiếp quan sát đầu ra
• Để quản lý hiệu quả, cần ghi log đầu vào và đầu ra của LLM
  • Việc kiểm tra mẫu các log này mỗi ngày cho phép nhanh chóng nhận diện và thích ứng với các mẫu mới hoặc chế độ thất bại mới
  • Khi phát hiện một vấn đề mới, có thể ngay lập tức viết assertion hoặc eval cho nó
• Tương tự, mọi cập nhật trong cách định nghĩa chế độ thất bại cũng phải được phản ánh vào tiêu chí đánh giá
  • Những “vibe check” này là tín hiệu của đầu ra sai, còn code và assertion là cách vận hành hóa chúng
• Cuối cùng, thái độ này cần được lan tỏa trong tổ chức
  • Ví dụ, thêm việc rà soát hoặc gắn chú thích cho đầu vào và đầu ra vào lịch trực on-call

Vận hành 2. Làm việc cùng mô hình

• Việc sử dụng API LLM đồng nghĩa có thể phụ thuộc vào trí tuệ của một số ít nhà cung cấp
  • Đây là điều tốt, nhưng sự phụ thuộc này đi kèm các đánh đổi về hiệu năng, độ trễ, throughput và chi phí
• Ngoài ra, khi trong năm qua gần như tháng nào cũng có mô hình mới và tốt hơn được phát hành, bạn phải sẵn sàng cập nhật sản phẩm khi loại bỏ mô hình cũ và di chuyển sang mô hình mới
  • Phần này chia sẻ những bài học rút ra khi dùng một công nghệ mà bạn không thể kiểm soát hoàn toàn, tức là công nghệ mà bạn không thể tự host và tự quản lý mô hình
• Trong hầu hết các use case thực tế, đầu ra của LLM sẽ được ứng dụng downstream tiêu thụ thông qua một dạng định dạng máy có thể đọc được
  • Ví dụ, ReChat, một CRM bất động sản, cần phản hồi có cấu trúc để render widget ở frontend
  • Tương tự, Boba, công cụ tạo ý tưởng chiến lược sản phẩm, cần đầu ra có cấu trúc với các trường tiêu đề, tóm tắt, điểm khả thi và khung thời gian
  • Cuối cùng, LinkedIn đã chia sẻ cách họ ràng buộc LLM để sinh YAML, thứ được dùng để quyết định công cụ cần dùng và cung cấp các tham số để gọi công cụ đó
• Mẫu ứng dụng này là một phiên bản cực đoan của định luật Postel
  • Hãy rộng rãi với thứ bạn chấp nhận (ngôn ngữ tự nhiên tùy ý) và bảo thủ với thứ bạn gửi đi (đối tượng có kiểu, máy đọc được)
  • Vì vậy, họ kỳ vọng đây sẽ là một mô hình rất bền vững
• Hiện tại, Instructor và Outlines là các tiêu chuẩn thực tế để dẫn dắt LLM tạo đầu ra có cấu trúc
  • Nếu dùng API LLM (ví dụ: Anthropic, OpenAI), hãy dùng Instructor; nếu dùng mô hình tự host (ví dụ: Huggingface), hãy dùng Outlines

Di chuyển prompt giữa các mô hình là việc đau đầu

• Đôi khi một prompt được xây dựng cẩn thận hoạt động rất tốt với một mô hình, nhưng lại không hoạt động đúng với mô hình khác
  • Điều này có thể xảy ra không chỉ khi chuyển đổi giữa các nhà cung cấp mô hình khác nhau mà còn khi nâng cấp giữa các phiên bản của cùng một mô hình
• Ví dụ, Voiceflow phát hiện rằng khi di chuyển từ gpt-3.5-turbo-0301 sang gpt-3.5-turbo-1106, hiệu năng của tác vụ phân loại ý định giảm 10%
  • (May mắn là họ đã có bộ đánh giá!)
• Tương tự, GoDaddy quan sát thấy một xu hướng tích cực rằng khi nâng cấp lên phiên bản 1106, khoảng cách hiệu năng giữa gpt-3.5-turbo và gpt-4 được thu hẹp
  • (Hoặc nếu bạn là người nhìn ly nước vơi một nửa, bạn có thể thất vọng vì bản nâng cấp mới đã làm giảm lợi thế dẫn trước của gpt-4)
• Vì vậy, nếu cần di chuyển prompt giữa các mô hình, hãy kỳ vọng rằng việc này sẽ tốn nhiều thời gian hơn là chỉ thay API endpoint
  • Đừng cho rằng chỉ cần cắm cùng một prompt vào là sẽ cho ra kết quả tương tự hoặc tốt hơn
• Ngoài ra, các bộ đánh giá tự động đáng tin cậy còn giúp đo lường hiệu năng tác vụ trước và sau khi di chuyển, đồng thời giảm công sức cần thiết cho việc kiểm tra thủ công

Quản lý và cố định phiên bản mô hình

• Trong mọi pipeline machine learning, “chỉ cần thay đổi một thứ là mọi thứ đều thay đổi”
  • Điều này đặc biệt đúng khi chúng ta phụ thuộc vào các thành phần như mô hình ngôn ngữ lớn (LLM), vốn không do chính chúng ta huấn luyện và có thể bị thay đổi mà ta không hề biết
• May mắn là nhiều nhà cung cấp mô hình cung cấp tùy chọn “cố định” một phiên bản mô hình cụ thể, chẳng hạn như gpt-4-turbo-1106
  • Điều này cho phép sử dụng một phiên bản cụ thể của trọng số mô hình để tránh bị thay đổi
• Việc cố định phiên bản mô hình trong production có thể ngăn các thay đổi bất ngờ trong hành vi của mô hình
  • Điều này có thể giúp tránh các phàn nàn từ khách hàng về những vấn đề như đầu ra quá dài dòng hoặc các kiểu lỗi bất ngờ khác có thể xảy ra khi mô hình bị thay thế
• Cũng nên cân nhắc duy trì một “shadow pipeline” phản chiếu cấu hình production nhưng sử dụng phiên bản mô hình mới nhất
  • Nhờ đó, bạn có thể thử nghiệm và kiểm tra an toàn với các bản phát hành mới
• Sau khi xác minh được độ ổn định và chất lượng đầu ra trên các mô hình mới này, bạn có thể tự tin cập nhật phiên bản mô hình trong môi trường production

Chọn mô hình nhỏ nhất có thể hoàn thành công việc

• Khi làm việc trên một ứng dụng mới, ta thường bị cám dỗ muốn dùng mô hình lớn nhất và mạnh nhất hiện có
  • Tuy nhiên, một khi đã xác nhận rằng tác vụ về mặt kỹ thuật là khả thi, thì rất đáng để thử xem liệu có thể đạt kết quả tương tự với mô hình nhỏ hơn hay không
• Ưu điểm của mô hình nhỏ là độ trễ và chi phí thấp hơn
  • Dù có thể yếu hơn, các kỹ thuật như Chain-of-Thought, prompt n-shot và học trong ngữ cảnh có thể giúp mô hình nhỏ vượt lên trên năng lực vốn có của nó
• Ngoài LLM API, fine-tuning cho các tác vụ cụ thể cũng có thể giúp cải thiện hiệu năng
• Nói chung, một workflow được thiết kế cẩn thận với mô hình nhỏ có thể nhanh hơn, rẻ hơn mà vẫn đạt hoặc thậm chí vượt chất lượng đầu ra của một mô hình lớn đơn lẻ
  • Ví dụ, tweet này chia sẻ một giai thoại về cách Haiku + prompt 10-shot vượt qua Opus zero-shot và GPT-4
• Về lâu dài, nhiều trường hợp flow engineering với mô hình nhỏ hơn được tối ưu tốt hơn giữa chất lượng đầu ra, độ trễ và chi phí có thể sẽ xuất hiện
• Một ví dụ khác là tác vụ phân loại tưởng như đơn giản
  • Các mô hình nhẹ như DistilBERT (67 triệu tham số) là một baseline mạnh đến đáng ngạc nhiên
  • DistilBART với 400 triệu tham số là một lựa chọn tuyệt vời khác
    • Khi được fine-tune trên dữ liệu mã nguồn mở, nó có thể phát hiện hallucination với ROC-AUC 0,84, vượt qua hầu hết các LLM với dưới 5% độ trễ và chi phí
• Điểm mấu chốt là không nên bỏ qua các mô hình nhỏ
  • Rất dễ áp một mô hình khổng lồ cho mọi vấn đề, nhưng với một chút sáng tạo và thử nghiệm, chúng ta thường có thể tìm ra các giải pháp hiệu quả hơn

Vận hành 3. Sản phẩm

• Công nghệ mới mở ra những khả năng mới, nhưng các nguyên tắc để tạo ra một sản phẩm tốt thì luôn trường tồn
  • Vì vậy, ngay cả khi đang giải quyết một vấn đề mới lần đầu tiên, bạn cũng không cần phải phát minh lại bánh xe trong thiết kế sản phẩm
• Có rất nhiều điều để đạt được khi xây dựng phát triển ứng dụng LLM trên nền tảng các nguyên tắc cơ bản vững chắc của sản phẩm
  • Điều này giúp chúng ta mang lại giá trị thực cho những người mà mình phục vụ

Đưa thiết kế vào cuộc ngay từ đầu

• Có nhà thiết kế sẽ giúp bạn hiểu và suy nghĩ sâu hơn về cách xây dựng sản phẩm cũng như cách trình bày nó cho người dùng
  • Đôi khi chúng ta rập khuôn rằng nhà thiết kế là người làm cho mọi thứ trông đẹp mắt
  • Nhưng họ còn xem xét lại cách cải thiện trải nghiệm người dùng, kể cả khi phải phá vỡ các quy tắc và khuôn mẫu hiện có, chứ không chỉ dừng ở giao diện người dùng
• Các nhà thiết kế đặc biệt giỏi trong việc tái cấu trúc nhu cầu của người dùng thành nhiều dạng khác nhau
  • Một số dạng trong đó dễ giải quyết hơn những dạng khác, vì thế có thể mở ra nhiều hoặc ít cơ hội hơn cho giải pháp AI
• Cũng như nhiều sản phẩm khác, việc xây dựng sản phẩm AI nên xoay quanh công việc cần hoàn thành, chứ không phải công nghệ vận hành sản phẩm
• Hãy tập trung đặt cho mình những câu hỏi như sau
  • “Người dùng đang giao cho sản phẩm này công việc gì? Đó có phải là kiểu việc mà chatbot làm tốt không? Hay tự động hoàn thành thì sao? Biết đâu lại là một thứ khác!”
• Hãy cân nhắc các mẫu thiết kế hiện có và mối liên hệ của chúng với công việc cần thực hiện
  • Đây là những tài sản quý giá mà nhà thiết kế bổ sung vào năng lực của cả nhóm

Thiết kế UX cho human-in-the-loop

• Một cách để có được dữ liệu gán nhãn chất lượng cao là tích hợp Human-in-the-Loop (HITL) vào trải nghiệm người dùng (UX)
  • Nếu cho phép người dùng dễ dàng cung cấp phản hồi và chỉnh sửa, có thể vừa cải thiện đầu ra ngay lập tức vừa thu thập dữ liệu hữu ích cho việc cải thiện mô hình
• Hãy tưởng tượng một nền tảng thương mại điện tử nơi người dùng tải sản phẩm lên và phân loại chúng
  • Có nhiều cách để thiết kế UX
    1. Người dùng tự chọn đúng danh mục sản phẩm, còn LLM định kỳ kiểm tra sản phẩm mới và sửa các phân loại sai ở backend
    2. Người dùng hoàn toàn không chọn danh mục, còn LLM định kỳ phân loại sản phẩm ở backend (bao gồm cả các lỗi tiềm ẩn)
    3. LLM đề xuất danh mục sản phẩm theo thời gian thực, và người dùng có thể xác minh cũng như cập nhật khi cần
• Cả ba cách tiếp cận đều có LLM, nhưng mang lại UX rất khác nhau
  • Cách tiếp cận thứ nhất đặt gánh nặng ban đầu lên người dùng, còn LLM đóng vai trò kiểm tra hậu kỳ
  • Cách tiếp cận thứ hai không đòi hỏi người dùng phải nỗ lực gì, nhưng không cung cấp tính minh bạch hay quyền kiểm soát
  • Cách tiếp cận thứ ba giữ được sự cân bằng phù hợp
    • Bằng cách để LLM chủ động đề xuất danh mục, nó giảm tải nhận thức cho người dùng và giúp họ không cần phải học hệ phân loại của chúng ta để phân loại sản phẩm
    • Đồng thời, bằng cách cho phép người dùng xem lại và chỉnh sửa đề xuất, quyền quyết định cuối cùng về cách phân loại sản phẩm vẫn được trao chắc chắn vào tay người dùng
  • Thêm một lợi ích nữa là cách tiếp cận thứ ba tạo ra một vòng lặp phản hồi tự nhiên để cải thiện mô hình
    • Đề xuất tốt sẽ được chấp nhận (nhãn dương), còn đề xuất kém sẽ được cập nhật (nhãn âm rồi đến nhãn dương)
• Mẫu hình gồm đề xuất, người dùng xác minh và thu thập dữ liệu này thường thấy trong nhiều ứng dụng
  • Trợ lý lập trình: người dùng có thể chấp nhận đề xuất (dương mạnh), chấp nhận rồi điều chỉnh (dương) hoặc bỏ qua (âm)
  • Midjourney: người dùng có thể upscale và tải xuống hình ảnh (dương mạnh), chỉnh sửa hình ảnh (dương), hoặc tạo một bộ hình ảnh mới (âm)
  • Chatbot: người dùng có thể bấm thích cho phản hồi (dương) hoặc không thích (âm), hoặc nếu phản hồi thực sự tệ thì chọn tạo lại phản hồi (âm mạnh)
• Phản hồi có thể là tường minh hoặc ngầm định
  • Phản hồi tường minh là thông tin do người dùng cung cấp để đáp lại yêu cầu từ sản phẩm
  • Phản hồi ngầm định là thông tin học được từ tương tác của người dùng mà không cần họ phải cố ý đưa ra phản hồi
• Trợ lý lập trình và Midjourney là ví dụ về phản hồi ngầm định, còn lượt thích và không thích là phản hồi tường minh
  • Nếu thiết kế UX tốt như trợ lý lập trình và Midjourney, có thể thu thập được rất nhiều phản hồi ngầm định để cải thiện cả sản phẩm lẫn mô hình

Ưu tiên tàn nhẫn cho hệ phân cấp yêu cầu

• Khi nghĩ đến việc đưa một bản demo vào production, cần xem xét các yêu cầu sau
  • Độ tin cậy: uptime 99,9%, tuân thủ đầu ra có cấu trúc
  • Tính vô hại: không tạo ra nội dung xúc phạm, NSFW hoặc các nội dung có hại khác
  • Tính nhất quán thực tế: bám sát ngữ cảnh được cung cấp và không bóp méo sự thật
  • Tính hữu ích: liên quan đến nhu cầu và yêu cầu của người dùng
  • Khả năng mở rộng: SLA về độ trễ, thông lượng được hỗ trợ
  • Chi phí: vì ngân sách không phải là vô hạn
  • Khác: bảo mật, quyền riêng tư, công bằng, GDPR, DMA, v.v.
• Nếu cố gắng giải quyết tất cả các yêu cầu này cùng một lúc thì sẽ không thể phát hành được gì cả
  • Vì vậy phải đặt ưu tiên. Một cách tàn nhẫn.
• Điều này có nghĩa là phải làm rõ những yếu tố không thể thỏa hiệp — những thứ nếu thiếu thì sản phẩm sẽ không hoạt động hoặc không khả thi (ví dụ: độ tin cậy, tính vô hại)
  • Điều quan trọng là xác định được MVP (Minimum Lovable Product)
• Phải chấp nhận rằng phiên bản đầu tiên sẽ không hoàn hảo, rồi phát hành và lặp lại

Điều chỉnh mức chấp nhận rủi ro theo use case

• Khi quyết định mức độ rà soát cho mô hình ngôn ngữ và ứng dụng, cần cân nhắc use case và đối tượng sử dụng
  • Với chatbot đối diện khách hàng cung cấp lời khuyên y tế hoặc tài chính, cần tiêu chuẩn rất cao về độ an toàn và độ chính xác
    • Sai sót hoặc đầu ra không chính xác có thể gây ra tác hại thực tế và làm mất niềm tin
  • Tuy nhiên, với các ứng dụng ít quan trọng hơn như hệ thống gợi ý, hoặc các ứng dụng đối diện nội bộ như phân loại nội dung hay tóm tắt, các yêu cầu quá nghiêm ngặt chỉ làm chậm tiến độ mà không mang lại nhiều giá trị bổ sung
• Điều này phù hợp với một báo cáo gần đây của a16z cho thấy nhiều công ty đang tiến nhanh hơn với các ứng dụng LLM nội bộ so với ứng dụng bên ngoài
  • Bằng cách thử nghiệm AI cho năng suất nội bộ, các tổ chức có thể bắt đầu nắm bắt giá trị đồng thời học cách quản lý rủi ro trong một môi trường được kiểm soát hơn
  • Sau đó, khi đã có đủ tự tin, họ có thể mở rộng sang các use case đối diện khách hàng

Vận hành 4. Đội ngũ và vai trò (Roles)

• Không có chức danh công việc nào là dễ định nghĩa, nhưng viết mô tả công việc cho vai trò trong lĩnh vực mới này còn khó hơn nhiều
  • Tôi sẽ bỏ qua sơ đồ Venn về các chức danh giao thoa hoặc các gợi ý về mô tả công việc
  • Tuy nhiên, tôi sẽ thừa nhận sự tồn tại của một vai trò mới là AI engineer và thảo luận về vai trò này
• Điều quan trọng hơn là thảo luận về việc phần còn lại của đội ngũ và trách nhiệm nên được phân bổ như thế nào

Tập trung vào quy trình, không phải công cụ

• Khi đối mặt với một mô hình mới như LLM, các kỹ sư phần mềm có xu hướng thiên về công cụ
  • Kết quả là họ bỏ qua vấn đề và quy trình mà công cụ đó định giải quyết
  • Làm như vậy, nhiều kỹ sư tự đưa thêm độ phức tạp ngẫu nhiên vào hệ thống, điều này gây tác động tiêu cực đến năng suất dài hạn của đội ngũ
• Ví dụ, bài viết này mô tả cách một công cụ cụ thể có thể tự động tạo prompt cho mô hình ngôn ngữ lớn
  • Bài viết cho rằng những kỹ sư sử dụng các công cụ như vậy mà không hiểu trước phương pháp luận hoặc quy trình giải quyết vấn đề thì cuối cùng sẽ gánh khoản nợ kỹ thuật không cần thiết (theo tôi thì nhận định này là hợp lý)
• Ngoài độ phức tạp ngẫu nhiên, công cụ thường còn được đặc tả chưa đầy đủ
  • Ví dụ, đang có sự phát triển của ngành công cụ đánh giá LLM cung cấp "hộp công cụ đánh giá LLM" với các evaluator tổng quát cho độ độc hại, tính ngắn gọn, giọng điệu, v.v.
  • Tôi thấy nhiều đội ngũ áp dụng các công cụ này mà không suy nghĩ một cách phản biện về những failure mode đặc thù trong miền của mình
• Trái lại, EvalGen tập trung vào việc dạy người dùng quy trình tạo đánh giá theo miền cụ thể, bằng cách để họ tham gia sâu vào từng bước như đặc tả tiêu chí, gán nhãn dữ liệu, xác nhận đánh giá, v.v.
  • Phần mềm hướng dẫn người dùng qua quy trình làm việc như sau
• Các thực hành tốt nhất mà EvalGen hướng dẫn để xây dựng đánh giá LLM
  1. Định nghĩa các bài kiểm tra theo miền cụ thể (được bootstrap tự động từ prompt)
     • Được định nghĩa dưới dạng assertion bằng code hoặc LLM-as-a-Judge
  2. Tầm quan trọng của việc căn chỉnh bài kiểm tra với đánh giá của con người để người dùng có thể xác nhận rằng bài kiểm tra nắm bắt đúng tiêu chí đã đặc tả
  3. Lặp lại bài kiểm tra khi hệ thống (prompt, v.v.) thay đổi
• EvalGen cung cấp cho nhà phát triển một mental model về quy trình xây dựng đánh giá, nhưng không khóa họ vào một công cụ cụ thể
  • Chúng tôi nhận thấy rằng sau khi cung cấp bối cảnh này cho AI engineer, họ thường quyết định chọn những công cụ đơn giản hơn hoặc tự xây dựng công cụ của riêng mình
• Ngoài viết prompt và đánh giá, còn quá nhiều thành phần của LLM nên không thể liệt kê hết ở đây
  • Tuy nhiên, điều quan trọng là AI engineer phải cố gắng hiểu quy trình trước khi áp dụng công cụ

Luôn thử nghiệm

• Sản phẩm ML gắn chặt với việc thử nghiệm
  • Không chỉ là A/B testing hay thử nghiệm đối chứng ngẫu nhiên, mà còn là những lần thử thường xuyên nhằm chỉnh sửa thành phần nhỏ nhất có thể của hệ thống và thực hiện đánh giá offline
  • Lý do mọi người hào hứng với đánh giá không thực sự là vì độ tin cậy và sự tự tin, mà là vì nó giúp việc thử nghiệm trở nên khả thi!
    • Đánh giá càng tốt thì có thể lặp lại thử nghiệm càng nhanh, từ đó hội tụ nhanh hơn đến phiên bản tốt nhất của hệ thống
• Vì việc thử nghiệm đã trở nên rất rẻ, nên việc thử nhiều cách tiếp cận khác nhau để giải cùng một bài toán đã trở thành điều phổ biến
  • Chi phí cao của việc thu thập dữ liệu và huấn luyện mô hình đã được giảm thiểu
    • Chi phí cho prompt engineering chỉ nhỉnh hơn một chút so với thời gian của con người
  • Hãy tổ chức đội ngũ để ai cũng có thể học các nguyên tắc cơ bản của prompt engineering
    • Điều này khuyến khích mọi người thử nghiệm và dẫn đến nhiều ý tưởng đa dạng trong toàn tổ chức
• Đừng chỉ thử nghiệm để khám phá, hãy dùng thử nghiệm để khai thác nữa!
  • Đã có một phiên bản hoạt động được cho tác vụ mới chưa?
    • Hãy cân nhắc để một người khác trong nhóm tiếp cận theo cách khác
  • Hãy thử theo một cách khác có thể nhanh hơn
  • Hãy nghiên cứu các kỹ thuật prompt như Chain-of-Thought hoặc Few-Shot để nâng cao chất lượng
  • Đừng để công cụ cản trở việc thử nghiệm
    • Nếu đang như vậy, hãy mua thứ gì đó có thể thay thế hoặc cải thiện, hoặc tự xây lại
• Trong quá trình lập kế hoạch sản phẩm/dự án, hãy dành riêng thời gian để xây dựng đánh giá và thực hiện nhiều thí nghiệm
  • Hãy suy nghĩ về product spec cho sản phẩm kỹ thuật, và bổ sung vào đó các tiêu chí rõ ràng cho đánh giá
• Khi lập roadmap, đừng đánh giá thấp lượng thời gian cần cho thử nghiệm
  • Hãy dự kiến nhiều vòng lặp phát triển và đánh giá trước khi được duyệt đưa vào production

Trao quyền để mọi người đều có thể sử dụng các công nghệ AI mới

• Khi việc áp dụng AI tạo sinh tăng lên, bạn sẽ muốn không chỉ chuyên gia mà cả toàn bộ nhóm cảm thấy họ có thể hiểu và sử dụng công nghệ mới này
  • Không có cách nào tốt hơn để phát triển trực giác về cách LLM hoạt động (ví dụ: độ trễ, chế độ lỗi, UX)
  • LLM tương đối dễ tiếp cận
    • Không cần biết lập trình để cải thiện hiệu năng của pipeline, và ai cũng có thể đóng góp thông qua prompt engineering và đánh giá
• Một phần lớn của việc này là đào tạo
  • Có thể bắt đầu từ các nền tảng của prompt engineering, như cách các kỹ thuật như n-shot prompting và CoT giúp điều kiện hóa mô hình theo hướng đầu ra mong muốn
• Những người có kiến thức cũng có thể đào tạo về các khía cạnh kỹ thuật hơn, chẳng hạn việc LLM về bản chất là tự hồi quy
  • Nghĩa là token đầu vào được xử lý song song, nhưng token đầu ra được tạo ra tuần tự
  • Vì vậy, độ trễ là một hàm của độ dài đầu ra hơn là độ dài đầu vào
    • Đây là một yếu tố cần cân nhắc quan trọng khi thiết kế UX và thiết lập kỳ vọng về hiệu năng
• Cũng có thể tạo cơ hội thực hành để thử nghiệm và khám phá
  • Còn hackathon thì sao?
    • Có thể sẽ thấy tốn kém khi cả nhóm dành vài ngày để hack các dự án mang tính suy đoán, nhưng kết quả có thể sẽ khiến bạn bất ngờ
  • Có đội ngũ đã gần như hoàn thành roadmap 3 năm chỉ trong 1 năm nhờ hackathon
    • Một đội khác đã thông qua hackathon đi đến một UX chuyển đổi mô hình tư duy, vốn nay trở nên khả thi nhờ LLM, và giờ đã trở thành ưu tiên cho năm nay và xa hơn nữa

Đừng rơi vào cái bẫy "AI engineering là tất cả"

• Khi một chức danh mới xuất hiện, ở giai đoạn đầu thường có xu hướng đánh giá quá cao các năng lực gắn với vai trò đó
  • Điều này thường dẫn đến những điều chỉnh đau đớn khi phạm vi thực tế của công việc dần trở nên rõ ràng
  • Người mới trong lĩnh vực này và quản lý tuyển dụng có thể đưa ra những tuyên bố phóng đại hoặc kỳ vọng quá mức
• Một số ví dụ đáng chú ý trong 10 năm qua gồm có
  • Data scientist: "người làm thống kê giỏi hơn mọi kỹ sư phần mềm và làm kỹ thuật phần mềm giỏi hơn mọi nhà thống kê"
  • Machine learning engineer (MLE): góc nhìn lấy kỹ thuật phần mềm làm trung tâm đối với machine learning
• Ban đầu, nhiều người cho rằng các dự án dựa trên dữ liệu chỉ cần data scientist là đủ
  • Nhưng rồi trở nên rõ ràng rằng data scientist phải hợp tác với software engineer và data engineer để phát triển và triển khai hiệu quả các sản phẩm dữ liệu
• Sự hiểu lầm này lại tái diễn với vai trò mới là AI engineer, khi một số nhóm tin rằng AI engineer là tất cả những gì họ cần
  • Trên thực tế, để xây dựng sản phẩm machine learning hoặc AI cần một loạt vai trò chuyên môn rộng hơn
• Chúng tôi đã tư vấn cho hơn 12 công ty về sản phẩm AI, và liên tục quan sát thấy họ rơi vào cái bẫy tin rằng "AI engineering là tất cả những gì cần có"
  • Kết quả là sản phẩm thường gặp khó khăn khi mở rộng vượt quá mức demo, trong khi bỏ sót các khía cạnh quan trọng cần thiết để xây dựng sản phẩm
• Ví dụ, đánh giá và đo lường là yếu tố then chốt để mở rộng sản phẩm vượt ra ngoài mức kiểm tra cảm tính
  • Các kỹ năng để đánh giá hiệu quả vốn tương ứng với một số thế mạnh thường thấy ở machine learning engineer
    • Một đội ngũ chỉ gồm AI engineer nhiều khả năng sẽ thiếu những kỹ năng này
• Đồng tác giả Hamel Husain giải thích tầm quan trọng của các kỹ năng này trong các công việc gần đây liên quan đến phát hiện thiên lệch dữ liệu và thiết kế đánh giá theo miền cụ thể
• Các loại vai trò cần thiết và thời điểm cần đến chúng trong hành trình xây dựng sản phẩm AI
  1. Trước tiên, hãy tập trung vào việc xây dựng sản phẩm
  • Có thể có AI engineer, nhưng không nhất thiết phải có
  • AI engineer hữu ích trong việc tạo prototype cho sản phẩm (UX, plumbing, v.v.) và lặp nhanh
  2. Tiếp theo, hãy instrument hệ thống và thu thập dữ liệu để tạo nền tảng phù hợp
  • Tùy loại và quy mô dữ liệu, có thể cần platform engineer và/hoặc data engineer
  • Cũng cần có hệ thống để truy vấn và phân tích dữ liệu này nhằm debug vấn đề
  3. Tiếp theo, hãy tối ưu hóa hệ thống AI
  • Điều này không nhất thiết bao gồm huấn luyện mô hình
  • Những phần cơ bản gồm các bước như thiết kế chỉ số, xây dựng hệ thống đánh giá, chạy thử nghiệm, tối ưu truy xuất RAG, debug hệ thống xác suất, v.v.
  • MLE rất giỏi ở lĩnh vực này (dĩ nhiên AI engineer cũng có thể học được)
  • Nếu chưa hoàn thành các bước trước đó thì việc tuyển MLE thường không hợp lý
• Ngoài ra, luôn cần có chuyên gia miền
  • Ở công ty nhỏ, lý tưởng nhất là đội ngũ sáng lập đảm nhiệm vai trò này; ở công ty lớn, product manager có thể đảm nhiệm
• Điều quan trọng là phải nhận thức được tiến trình và thời điểm của các vai trò
  • Tuyển sai người vào sai thời điểm (ví dụ: tuyển MLE quá sớm) hoặc xây dựng sai thứ tự đều là lãng phí thời gian và tiền bạc, đồng thời gây ra nghỉ việc
• Ngoài ra, việc thường xuyên check-in với MLE ở giai đoạn 1-2 (nhưng không tuyển toàn thời gian) sẽ giúp công ty xây dựng đúng nền tảng

[Chiến lược: Cách không bị tụt lại phía sau khi xây dựng với LLM]

• Để phát triển sản phẩm thành công, cần có kế hoạch cẩn trọng và sắp xếp ưu tiên, thay vì chỉ lao vào làm prototype hoặc chạy theo mô hình hay xu hướng mới nhất
• Khi phát triển sản phẩm AI, cần xem xét các trade-off quan trọng như nên tự xây hay đi mua
• Đưa ra một "playbook" cho việc phát triển các ứng dụng LLM giai đoạn đầu

Chiến lược 1: Không GPU trước PMF

• Để trở thành một sản phẩm tuyệt vời, chỉ bọc mỏng API của người khác là chưa đủ
• Nhưng sai lầm theo hướng ngược lại còn có thể gây tốn kém hơn
  • Trong năm qua, một lượng lớn vốn đầu tư mạo hiểm đã được đổ vào việc huấn luyện và tùy biến mô hình mà không có tầm nhìn sản phẩm rõ ràng hay thị trường mục tiêu cụ thể
  • Có công ty thậm chí đã nhận được vòng Series A lên tới 6 tỷ USD
• Phần này sẽ giải thích vì sao việc ngay lập tức bắt đầu huấn luyện mô hình riêng là một sai lầm, đồng thời xem xét vai trò của tự lưu trữ

Việc huấn luyện lại (gần như) từ đầu ngay từ ban đầu là không có ý nghĩa

• Với phần lớn tổ chức, việc pretrain LLM từ đầu ngay từ đầu là điều thiếu thực tế và đi chệch khỏi phát triển sản phẩm
  • Việc phát triển và duy trì hạ tầng machine learning tiêu tốn rất nhiều nguồn lực
    • Bao gồm thu thập dữ liệu, huấn luyện và đánh giá mô hình, triển khai, v.v.
  • Nếu đang ở giai đoạn kiểm chứng product-market fit, những nỗ lực này sẽ làm phân tán nguồn lực khỏi việc phát triển sản phẩm cốt lõi
  • Ngay cả khi có tài nguyên tính toán, dữ liệu và năng lực kỹ thuật, một LLM đã pretrain có thể trở nên lỗi thời chỉ sau vài tháng
• Trường hợp của BloombergGPT
  • BloombergGPT, một LLM chuyên cho tác vụ tài chính, đã được pretrain với 363B token
  • Nỗ lực khổng lồ của 9 nhân sự toàn thời gian đã được đổ vào đó, gồm 4 kỹ sư AI và 5 người phụ trách sản phẩm/nghiên cứu ML
  • Dù vậy, trong vòng một năm nó vẫn bị gpt-3.5-turbo và gpt-4 vượt qua trong chính các tác vụ đó
• Những ví dụ này cho thấy, trong hầu hết ứng dụng thực tế, pretrain LLM từ đầu không phải là cách dùng tài nguyên tốt nhất
  • Thay vào đó, đội ngũ nên fine-tune mô hình mã nguồn mở mạnh nhất hiện có cho phù hợp với nhu cầu cụ thể
• Tất nhiên vẫn có ngoại lệ
  • Mô hình code của Replit là một ví dụ tốt về pretraining chuyên biệt cho sinh và hiểu mã
  • Nhờ pretraining, nó cho thấy hiệu năng vượt các mô hình lớn hơn như CodeLlama7b
  • Tuy nhiên, khi các mô hình mạnh hơn được phát hành, vẫn cần đầu tư liên tục để duy trì tính hữu dụng

Đừng fine-tune cho đến khi xác nhận là cần thiết

• Ở phần lớn tổ chức, fine-tuning được thúc đẩy bởi FOMO (Fear Of Missing Out, nỗi sợ bị bỏ lỡ) hơn là tư duy chiến lược
  • Các tổ chức đầu tư vào fine-tuning quá sớm để tránh bị chê là “chỉ là một wrapper đơn giản”
  • Trên thực tế, fine-tuning giống như vũ khí hạng nặng chỉ nên triển khai sau khi đã tích lũy đủ nhiều trường hợp cho thấy các cách tiếp cận khác là không đủ
• Một năm trước, nhiều đội ngũ tỏ ra hào hứng với fine-tuning, nhưng chỉ một số ít tìm được product-market fit và đa số đều hối tiếc với quyết định đó
  • Nếu định fine-tune, bạn phải sẵn sàng lặp lại việc này mỗi khi mô hình nền được cải thiện
    • Xem phần “Mô hình không phải là sản phẩm” và “Xây dựng LLMOps” bên dưới
• Các trường hợp mà fine-tuning thực sự có thể là lựa chọn đúng
  • Khi cần dữ liệu không có trong phần lớn các bộ dữ liệu web quy mô lớn mở đã được dùng để huấn luyện các mô hình hiện tại
  • Khi bạn đã xây dựng một MVP cho thấy các mô hình hiện tại là chưa đủ
  • Nhưng hãy cẩn thận: nếu ngay cả các nhà xây dựng mô hình cũng không dễ có được dữ liệu huấn luyện chất lượng cao, thì bạn sẽ lấy nó từ đâu?
• Ứng dụng dựa trên LLM không phải là dự án hội chợ khoa học
  • Mức đầu tư phải tương xứng với mục tiêu chiến lược và mức độ đóng góp vào khác biệt cạnh tranh

Hãy bắt đầu với inference API, nhưng đừng ngại self-hosting

• Dùng API LLM cho phép startup dễ dàng tiếp nhận và tích hợp năng lực language modeling mà không cần tự huấn luyện mô hình từ đầu
  • Các nhà cung cấp như Anthropic, OpenAI, v.v. cung cấp API tổng quát giúp đưa intelligence vào sản phẩm chỉ với vài dòng code
  • Dùng các dịch vụ này giúp giảm công sức và tập trung vào tạo giá trị cho khách hàng, nhờ đó kiểm chứng ý tưởng và lặp lại để tìm product-market fit nhanh hơn
• Tuy nhiên, giống như cơ sở dữ liệu, dịch vụ managed không phù hợp với mọi use case khi quy mô và yêu cầu tăng lên
  • Trên thực tế, self-hosting có thể là cách duy nhất để dùng mô hình mà không gửi dữ liệu bí mật/cá nhân ra ngoài mạng, theo yêu cầu của các ngành bị quản lý như y tế và tài chính, hoặc do nghĩa vụ hợp đồng và yêu cầu bảo mật
• Self-hosting cũng giúp vượt qua các ràng buộc như rate limit, việc ngừng hỗ trợ mô hình, hay giới hạn sử dụng do nhà cung cấp inference áp đặt
  • Self-hosting mang lại toàn quyền kiểm soát mô hình, giúp dễ xây dựng các hệ thống khác biệt và chất lượng cao hơn
• Cuối cùng, self-hosting, đặc biệt là fine-tuning, có thể giúp giảm chi phí ở quy mô lớn
  • Ví dụ, Buzzfeed đã chia sẻ trường hợp giảm 80% chi phí bằng cách fine-tune một LLM mã nguồn mở

Chiến lược 2: Lặp lại để hướng tới thứ tốt hơn

• Để duy trì lợi thế cạnh tranh trong dài hạn, cần nghĩ tới những yếu tố có thể tạo khác biệt cho sản phẩm vượt ra ngoài bản thân mô hình
• Tốc độ thực thi rất quan trọng, nhưng không nên là lợi thế duy nhất

Mô hình không phải là sản phẩm, hệ thống bao quanh mô hình mới là sản phẩm

• Với các đội ngũ không tự xây dựng mô hình, tốc độ đổi mới nhanh là một phước lành
  • Vì họ có thể di chuyển sang các mô hình mới nhất để tạo ra sản phẩm tốt hơn, theo đuổi các cải thiện về kích thước ngữ cảnh, năng lực suy luận, giá trị trên chi phí, v.v.
  • Những tiến bộ này thú vị đến mức gần như có thể dự đoán được
  • Tổng hợp lại, mô hình nhiều khả năng là thành phần kém bền vững nhất trong cả hệ thống
• Thay vào đó, nên tập trung công sức vào những phần có thể tạo ra giá trị lâu dài
  • Evals: để đo lường hiệu năng tác vụ một cách ổn định trên nhiều mô hình
  • Guardrails: để ngăn đầu ra không mong muốn bất kể là mô hình nào
  • Caching: để giảm độ trễ và chi phí bằng cách tránh hẳn việc gọi mô hình
  • Data flywheel: để thúc đẩy cải tiến lặp lại cho tất cả những yếu tố trên
  • Các thành phần này tạo ra một hào lũy chất lượng sản phẩm dày hơn so với chỉ dựa vào năng lực thô của mô hình
• Tuy nhiên, điều đó không có nghĩa là xây ở lớp ứng dụng là không có rủi ro
  • Nếu muốn OpenAI hay các nhà cung cấp mô hình khác cung cấp phần mềm doanh nghiệp khả dụng, đừng cắt xén ở những chỗ đáng ra cần được đầu tư
• Ví dụ, một số đội ngũ đã đầu tư xây công cụ tùy chỉnh để kiểm chứng đầu ra có cấu trúc từ các mô hình độc quyền
  • Đầu tư tối thiểu ở đây là quan trọng, nhưng đầu tư quá sâu không phải là cách dùng thời gian hiệu quả
  • OpenAI phải đảm bảo rằng khi yêu cầu function calling, bạn sẽ nhận được function call hợp lệ, vì đó là điều mọi khách hàng đều muốn
  • Hãy áp dụng “trì hoãn chiến lược” ở đây: chỉ xây những gì thực sự cần thiết, rồi chờ nhà cung cấp mở rộng tính năng

Bắt đầu nhỏ để xây dựng niềm tin

• Xây một sản phẩm cố làm mọi thứ cho mọi người là công thức của sự tầm thường
• Để tạo ra sản phẩm thực sự thuyết phục, doanh nghiệp phải chuyên môn hóa vào việc xây dựng trải nghiệm đủ “dính” để người dùng tiếp tục quay lại
• Hãy xem một hệ thống RAG tổng quát với mục tiêu trả lời mọi câu hỏi của người dùng
  • Thiếu chuyên môn hóa đồng nghĩa hệ thống không thể ưu tiên thông tin mới nhất, phân tích các định dạng chuyên biệt theo miền, hoặc hiểu được sắc thái của những tác vụ cụ thể
  • Kết quả là người dùng có trải nghiệm hời hợt, thiếu độ tin cậy, không đáp ứng được nhu cầu và rồi rời đi
• Để giải quyết điều này, cần tập trung vào miền và use case cụ thể
  • Cần thu hẹp phạm vi bằng cách tăng chiều sâu thay vì chiều rộng
  • Làm như vậy sẽ giúp tạo ra các công cụ chuyên biệt theo miền có sức cộng hưởng với người dùng
• Chuyên môn hóa cũng cho phép truyền đạt trung thực về khả năng và giới hạn của hệ thống
  • Minh bạch về những gì hệ thống có thể và không thể làm thể hiện sự tự nhận thức, giúp người dùng hiểu được nơi nó có thể tạo nhiều giá trị nhất, và từ đó xây dựng niềm tin cùng sự tự tin vào đầu ra

Xây dựng LLMOps, nhưng phải có lý do phù hợp: lặp lại nhanh

• DevOps về bản chất không phải là workflow có thể tái lập, hay shift-left, hay trao quyền cho đội hai chiếc pizza. Càng không phải là viết file YAML
• DevOps là rút ngắn vòng phản hồi giữa công việc và kết quả của nó để các cải tiến được tích lũy thay vì lỗi
  • Gốc rễ của nó có thể truy về lean startup, xa hơn nữa là lean manufacturing và Toyota Production System, với trọng tâm là single-minute die exchange và kaizen
• MLOps đã áp dụng hình thức của DevOps vào ML
  • Có các bộ công cụ all-in-one cho thí nghiệm có thể tái lập và trao quyền để người xây dựng mô hình có thể triển khai. Cũng có rất nhiều file YAML
• Tuy nhiên, với tư cách là một ngành, MLOps đã không tiếp nhận chức năng của DevOps. Nó không thu hẹp khoảng cách phản hồi giữa mô hình và suy luận cũng như tương tác trong production
• May mắn là lĩnh vực LLMOps đã chuyển hướng khỏi những vấn đề vụn vặt như quản lý prompt sang cải tiến liên tục, dẫn tới các vấn đề khó cản trở việc lặp như giám sát production và đánh giá
• Đã có các arena đối thoại cho đánh giá trung lập và crowdsourced đối với mô hình chat và coding. Đây là vòng lặp bên ngoài của cải tiến tập thể và lặp lại
  • Các công cụ như LangSmith, Log10, LangFuse, W&B Weave, HoneyHive không chỉ hứa hẹn thu thập và sắp xếp dữ liệu về kết quả hệ thống trong production mà còn tích hợp sâu với phát triển để dùng dữ liệu đó cải thiện hệ thống. Hãy dùng các công cụ này hoặc tự xây dựng

Đừng xây dựng năng lực LLM mà bạn có thể mua

• Phần lớn doanh nghiệp thành công không phải là doanh nghiệp LLM. Đồng thời, phần lớn doanh nghiệp đều có cơ hội được cải thiện bằng LLM
• Hai quan sát này thường khiến lãnh đạo hiểu sai, vội vàng cải tạo hệ thống bằng LLM rồi tung ra các tính năng “AI” giả tạo, thiên về phô trương, vừa tăng chi phí vừa giảm chất lượng. Biểu tượng lấp lánh đáng sợ của hiện tại đã hoàn tất
• Có một cách tốt hơn: tập trung vào các ứng dụng LLM thực sự phù hợp với mục tiêu sản phẩm và củng cố hoạt động cốt lõi
• Hãy xem xét vài nỗ lực sai lầm làm lãng phí thời gian của đội ngũ
  • Xây dựng tính năng text-to-SQL tùy chỉnh cho doanh nghiệp
  • Xây dựng chatbot có thể trò chuyện với tài liệu
  • Tích hợp knowledge base của công ty vào chatbot hỗ trợ khách hàng
• Những thứ trên là hello world của ứng dụng LLM, nhưng công ty sản phẩm tự xây dựng chúng thì không hợp lý
  • Đây là các bài toán phổ quát, chung cho nhiều doanh nghiệp, nơi khoảng cách giữa demo hứa hẹn và thành phần đáng tin cậy là rất lớn, và thuộc phạm vi quen thuộc của các công ty phần mềm
  • Đầu tư nguồn lực R&D quý giá vào các bài toán phổ quát đang được giải ở quy mô lớn trong batch Y Combinator hiện tại là lãng phí
• Nếu điều này nghe như lời khuyên kinh doanh sáo rỗng, đó là vì trong sự hưng phấn của làn sóng cường điệu hiện tại, người ta rất dễ nhầm “LLM” là thứ khác biệt và tối tân, rồi bỏ qua những ứng dụng vốn đã thành hàng hóa

Đặt AI vào trong vòng lặp, và đặt con người ở trung tâm

• Các ứng dụng dựa trên LLM hiện nay còn mong manh. Chúng cần lượng lớn biện pháp an toàn và kỹ thuật phòng thủ nhưng vẫn khó dự đoán. Đồng thời, nếu được giới hạn phạm vi chặt chẽ, các ứng dụng này có thể cực kỳ hữu ích. Điều này có nghĩa LLM là công cụ tuyệt vời để tăng tốc workflow của người dùng
• Có thể bạn muốn hình dung các ứng dụng dựa trên LLM sẽ thay thế hoàn toàn workflow hoặc đảm nhiệm chức năng công việc, nhưng mô hình hiệu quả nhất hiện nay là nhân mã người-máy (Centaur chess)
  • Khi con người có năng lực kết hợp với khả năng LLM được điều chỉnh để họ tận dụng nhanh, năng suất và cảm giác hài lòng khi hoàn thành công việc có thể tăng mạnh
  • GitHub CoPilot, một trong những ứng dụng tiêu biểu của LLM, đã chứng minh sức mạnh của workflow này
    • "Nhìn chung, các lập trình viên nói rằng khi dùng GitHub Copilot và GitHub Copilot Chat, việc lập trình trở nên dễ hơn, ít lỗi hơn, dễ đọc hơn, tái sử dụng tốt hơn, gọn hơn, dễ bảo trì hơn và bền vững hơn." - Mario Rodriguez, GitHub
• Những người đã làm việc với ML lâu năm có thể nhanh chóng nghĩ tới ý tưởng “human-in-the-loop”, nhưng đừng vội như vậy
  • Machine learning HITL là một mô hình dựa trên chuyên gia con người để bảo đảm mô hình ML hoạt động đúng như dự đoán
  • Điều được đề xuất ở đây có liên quan, nhưng tinh tế hơn. Các hệ thống dựa trên LLM không nên là động lực chính của hầu hết workflow ngày nay, mà chỉ nên là một nguồn lực
• Đặt con người ở trung tâm và hỏi xem LLM có thể hỗ trợ workflow như thế nào sẽ tạo ra tác động rất khác lên quyết định sản phẩm và thiết kế
  • Cuối cùng, bạn sẽ tạo ra một sản phẩm khác với đối thủ đang vội vàng chuyển toàn bộ trách nhiệm cho LLM: một sản phẩm tốt hơn, hữu ích hơn và ít rủi ro hơn

Chiến lược 3. Bắt đầu với prompting, eval và thu thập dữ liệu

• Ở phần trước, chúng ta đã dồn dập khá nhiều kỹ thuật và lời khuyên. Đây là lượng thông tin lớn để tiếp nhận. Hãy xem tập tối thiểu những lời khuyên hữu ích.
  • Nếu đội ngũ muốn xây dựng sản phẩm LLM, thì nên bắt đầu từ đâu?
• Trong một năm qua, đã thấy đủ nhiều để tin rằng các ứng dụng LLM thành công đi theo một quỹ đạo nhất quán. Phần này sẽ xem qua playbook “bắt đầu” cơ bản đó
• Ý tưởng cốt lõi là bắt đầu đơn giản và chỉ thêm độ phức tạp khi cần
  • Rule of Thumb: mỗi mức độ tinh vi thường đòi hỏi ít nhất nhiều hơn một bậc độ lớn công sức so với bước trước đó. Hãy ghi nhớ điều này...

Prompt engineering là ưu tiên số một

• Hãy bắt đầu bằng prompt engineering
  • Sử dụng mọi kỹ thuật đã thảo luận trước đó trong phần chiến thuật
  • Chain-of-thought, ví dụ n-shot, và input/output có cấu trúc gần như luôn là ý hay
  • Hãy tạo prototype với mô hình mạnh nhất trước khi cố vắt hiệu năng từ mô hình yếu
• Chỉ nên cân nhắc fine-tuning nếu không thể đạt mức hiệu năng mong muốn bằng prompt engineering
  • Điều này sẽ xảy ra thường xuyên hơn nếu có các yêu cầu phi chức năng ngăn dùng mô hình độc quyền và yêu cầu self-hosting, ví dụ quyền riêng tư dữ liệu, toàn quyền kiểm soát, chi phí
  • Hãy cẩn thận để các yêu cầu riêng tư đó không đồng thời ngăn việc dùng dữ liệu người dùng cho fine-tuning

Xây dựng đánh giá và khởi động data flywheel

• Ngay cả các đội mới bắt đầu cũng cần evals. Nếu không, bạn sẽ không biết prompt engineering đã đủ chưa, hoặc mô hình fine-tuned đã sẵn sàng thay thế mô hình nền tảng hay chưa
• Đánh giá hiệu quả là đánh giá đặc thù theo tác vụ và phản ánh đúng use case dự định
  • Cấp độ đánh giá đầu tiên được khuyến nghị là unit test
  • Những assertion đơn giản này giúp phát hiện các failure mode đã biết hoặc được giả định, đồng thời hỗ trợ đưa ra các quyết định thiết kế ban đầu
  • Cũng nên tham khảo các đánh giá theo tác vụ khác cho phân loại, tóm tắt, v.v.
• Unit test và đánh giá dựa trên mô hình rất hữu ích, nhưng không thay thế được nhu cầu đánh giá của con người
  • Hãy để người dùng sử dụng mô hình/sản phẩm và đưa phản hồi
  • Việc này phục vụ hai mục đích: đo hiệu năng thực tế và tỷ lệ lỗi, đồng thời thu thập dữ liệu gán nhãn chất lượng cao có thể dùng để fine-tuning mô hình trong tương lai
  • Nó tạo ra một vòng phản hồi tích cực, hay data flywheel, có tác dụng lãi kép theo thời gian
    • Đánh giá của con người để đo hiệu năng mô hình hoặc tìm lỗi
    • Dùng dữ liệu gán nhãn để fine-tuning mô hình hoặc cập nhật prompt
    • Lặp lại
• Ví dụ, khi kiểm toán lỗi trong phần tóm tắt do LLM sinh ra, bạn có thể gán các nhãn phản hồi chi tiết cho từng câu để xác định sai lệch sự thật, không liên quan hoặc văn phong kém
  • Sau đó có thể dùng các chú thích về sai lệch sự thật để huấn luyện bộ phân loại hallucination, hoặc dùng chú thích về mức độ liên quan để huấn luyện mô hình reward về độ liên quan
• LinkedIn đã chia sẻ trường hợp thành công dùng evaluator dựa trên mô hình để ước lượng hallucination, vi phạm responsible AI, tính nhất quán, v.v.
• Bằng cách tạo ra tài sản tăng giá trị theo thời gian, việc xây dựng evals được chuyển từ một chi phí vận hành đơn thuần thành khoản đầu tư chiến lược, đồng thời xây dựng data flywheel trong quá trình đó

Chiến lược 4. Xu hướng cấp cao của nhận thức chi phí thấp (The high-level trend of low-cost cognition)

• Năm 1971, các nhà nghiên cứu tại Xerox PARC đã dự đoán thế giới máy tính cá nhân được kết nối bằng mạng mà chúng ta đang sống ngày nay
  • Họ cũng góp phần tạo ra tương lai đó bằng cách đóng vai trò then chốt trong việc phát minh ra các công nghệ làm cho nó trở nên khả thi, như Ethernet, kết xuất đồ họa, chuột, cửa sổ giao diện và hơn thế nữa
• Họ cũng đã thực hiện một bài tập đơn giản
  • Họ xem xét các ứng dụng rất hữu ích nhưng chưa hiệu quả về mặt kinh tế (ví dụ: màn hình video), khi RAM đủ để vận hành màn hình video có giá tới hàng nghìn USD
  • Sau đó, họ xem xét xu hướng giá trong lịch sử của công nghệ đó, tương tự như định luật Moore, và dự đoán khi nào công nghệ ấy sẽ trở nên kinh tế
• Ta cũng có thể làm điều tương tự với công nghệ LLM, dù nó không gọn gàng như số transistor trên mỗi đô la
  • Chọn một benchmark phổ biến đã được dùng lâu năm (ví dụ: bộ dữ liệu Massively-Multitask Language Understanding) và một cách tiếp cận đầu vào nhất quán (prompting 5-shot)
  • Sau đó so sánh chi phí chạy các mô hình ngôn ngữ đạt những mức hiệu năng khác nhau trên benchmark này theo thời gian
• Với chi phí cố định, năng lực đang tăng lên rất nhanh. Với mức năng lực cố định, chi phí đang giảm xuống rất nhanh
  • Trong 4 năm kể từ khi mô hình davinci của OpenAI được phát hành qua API, chi phí để chạy một mô hình có hiệu năng tương đương cho tác vụ đó ở quy mô 1 triệu token (khoảng 100 bản sao của tài liệu này) đã giảm từ 20 USD xuống dưới 10 xu. Chu kỳ bán rã chỉ khoảng 6 tháng
  • Tương tự, tính đến tháng 5 năm 2024, chi phí để chạy Meta LLaMA 3 8B thông qua nhà cung cấp API hoặc tự chạy chỉ vào khoảng 20 xu cho mỗi 1 triệu token, với hiệu năng tương đương OpenAI text-davinci-003, mô hình đã làm nên ChatGPT
  • Mô hình đó khi mới ra mắt vào cuối tháng 11 năm 2023 vẫn có chi phí khoảng 20 USD cho mỗi 1 triệu token. Chỉ trong 18 tháng đã tạo ra chênh lệch hai chữ số. Đây cũng là khoảng thời gian mà định luật Moore chỉ dự đoán một mức tăng gấp đôi đơn giản
• Giờ hãy xem xét các ứng dụng LLM rất hữu ích nhưng vẫn chưa hiệu quả về mặt kinh tế, như điều khiển nhân vật game tạo sinh kiểu Park et al, với chi phí ước tính là 625 USD mỗi giờ
  • Kể từ khi bài báo đó được công bố vào tháng 8 năm 2023, chi phí đã giảm khoảng một bậc xuống còn khoảng 62,50 USD mỗi giờ
  • Sau 9 tháng nữa, có thể kỳ vọng nó sẽ giảm xuống còn 6,25 USD mỗi giờ
• Trong khi đó, khi Pac-Man ra mắt vào năm 1980, 1 USD theo giá trị ngày nay có thể mua số credit để chơi trong vài phút hoặc vài chục phút. Hãy gọi đó là 6 ván mỗi giờ, hay 6 USD mỗi giờ
  • Phép tính nhanh này cho thấy các trải nghiệm game hấp dẫn được tăng cường bởi LLM có thể sẽ trở nên kinh tế vào khoảng năm 2025
• Những xu hướng này là mới và chỉ mới xuất hiện trong vài năm. Tuy vậy, gần như không có lý do gì để kỳ vọng quá trình này sẽ chậm lại trong vài năm tới
  • Ngay cả khi đã tận dụng hết các “quả thấp dễ hái” về thuật toán và bộ dữ liệu, chẳng hạn như mở rộng vượt quá “tỷ lệ Chinchilla” khoảng 20 token trên mỗi tham số, những đổi mới sâu hơn và đầu tư vào bên trong trung tâm dữ liệu cũng như các lớp silicon sẽ lấp đầy khoảng trống đó
• Và đây có lẽ là sự thật chiến lược quan trọng nhất
  • Những demo hào nhoáng hoặc bài báo nghiên cứu hoàn toàn không khả thi ngày nay sẽ trở thành tính năng cao cấp sau vài năm, và ngay sau đó sẽ trở thành hàng hóa phổ thông
  • Cần xây dựng hệ thống và tổ chức với điều đó trong tâm trí

[Demo từ 0 đến 1 giờ đã đủ. Giờ là lúc tạo ra sản phẩm đi từ 1 đến N]

• Làm một demo LLM thật sự rất vui. Chỉ với vài dòng code, một vector database và những prompt được viết cẩn thận là có thể tạo ra “phép màu”
• Trong năm qua, thứ “phép màu” này đã được so sánh với Internet, smartphone, thậm chí cả máy in
• Đáng tiếc là, như bất kỳ ai từng làm công việc phát hành phần mềm thực tế đều biết, có một khoảng cách rất lớn giữa một demo hoạt động trong môi trường kiểm soát và một sản phẩm vận hành ổn định ở quy mô lớn
• Có rất nhiều vấn đề mà việc tưởng tượng và làm demo thì dễ, nhưng biến thành sản phẩm lại cực kỳ khó
  • Ví dụ như xe tự lái: để trình diễn việc một chiếc xe tự lái đi qua một dãy nhà là khá dễ, nhưng biến nó thành sản phẩm thì mất 10 năm - Andrej Karpathy
• Hãy lấy xe tự lái làm ví dụ
  • Năm 1988, chiếc xe đầu tiên được điều khiển bằng mạng nơ-ron đã xuất hiện
  • 25 năm sau, Andrej Karpathy đã có chuyến đi demo đầu tiên với Waymo
  • 10 năm sau đó, công ty đã nhận được giấy phép vận hành không người lái
  • Từ nguyên mẫu đến sản phẩm thương mại là 35 năm kỹ thuật nghiêm ngặt, kiểm thử, cải tiến và điều hướng quy định
• Trong suốt năm qua, chúng tôi đã quan sát những thăng trầm trên cả giới công nghiệp lẫn học thuật: Năm đầu tiên của N đối với các ứng dụng LLM (Year 1 of N for LLM applications)
  • Chúng tôi hy vọng những bài học đã học được, từ các chiến thuật như đánh giá, prompt engineering, guardrail cho đến các góc nhìn chiến lược như kỹ năng vận hành, xây dựng đội ngũ và lựa chọn những gì nên tự xây trong nội bộ, sẽ hữu ích cho năm thứ 2 và xa hơn nữa
  • Chúng tôi mong được cùng nhau thúc đẩy công nghệ mới đầy hứng khởi này tiến về phía trước

[inthelife]

Nội dung rất hay nên tôi đã thử làm thành một Mindmap để xem lại lâu dài ^^;

https://drive.google.com/file/d/…

[hheungsu]

Bài viết quá hay!! Có rất nhiều điều hữu ích để ngẫm lại từ đầu đến cuối. Cảm ơn bạn đã dịch và đăng một bài viết quý giá như thế này!!

[nutella]

Ở thời điểm hiện tại, nội dung này thực sự rất hữu ích.

[komanabi]

Megastudy đã kết thúc rồi, Omega 3 đang đến!!!

[ssifood]

Giờ thì Skynet đã hết rồi, MegaStudy mới là thứ đang đến.

[my0075425]

Giờ thì nhân loại đã hết rồi, Skynet sắp tới!!

[zihado]

Sự nghiệp của tác giả bài gốc cũng rất thú vị.
https://vi.news.hada.io/topic?id=1626

[eungook]

Wow.. thật sự truyền cảm hứng quá.. cảm ơn vì phần giới thiệu

[humblebee]

Đây là một bài viết rất hay, truyền tải sống động những góc nhìn sâu sắc và trải nghiệm thực tế! Có lẽ sẽ là nguồn hỗ trợ rất lớn cho tôi và cả đội ngũ của mình. Tôi đã đọc với sự thích thú. Xin cảm ơn ☺️