Trí thông minh dữ liệu tạo

AI

FMOps/LLMOps: Vận hành AI tổng quát và sự khác biệt với MLOps | Dịch vụ web của Amazon

Tái bản bởi Plato
Tái bản bởi Plato

Ngày:

Lượt xem: 98

Ngày nay, phần lớn khách hàng của chúng tôi rất hào hứng với các mô hình ngôn ngữ lớn (LLM) và nghĩ đến việc AI có thể tạo ra nhiều thay đổi có thể biến đổi hoạt động kinh doanh của họ. Tuy nhiên, việc đưa những giải pháp, mô hình như vậy vào hoạt động kinh doanh thông thường không phải là một việc dễ dàng. Trong bài đăng này, chúng tôi thảo luận về cách vận hành các ứng dụng AI tổng quát bằng cách sử dụng các nguyên tắc MLOps dẫn đến hoạt động mô hình nền tảng (FMOps). Hơn nữa, chúng tôi đi sâu vào trường hợp sử dụng AI tổng quát phổ biến nhất của các ứng dụng chuyển văn bản thành văn bản và hoạt động LLM (LLMOps), một tập hợp con của FMOps. Hình dưới đây minh họa các chủ đề chúng ta thảo luận.

Cụ thể, chúng tôi giới thiệu ngắn gọn các nguyên tắc MLOps và tập trung vào những điểm khác biệt chính so với FMOps và LLMOps về quy trình, con người, lựa chọn và đánh giá mô hình, quyền riêng tư dữ liệu và triển khai mô hình. Điều này áp dụng cho những khách hàng sử dụng chúng ngay từ đầu, tạo mô hình nền tảng từ đầu hoặc tinh chỉnh chúng. Cách tiếp cận của chúng tôi áp dụng cho cả mô hình nguồn mở và độc quyền như nhau.

Tóm tắt vận hành ML

Như đã định nghĩa trong bài Lộ trình nền tảng MLOps cho các doanh nghiệp với Amazon SageMaker, ML và hoạt động (MLOps) là sự kết hợp giữa con người, quy trình và công nghệ để tạo ra các giải pháp máy học (ML) một cách hiệu quả. Để đạt được điều này, cần có sự kết hợp giữa các nhóm và cá nhân để cộng tác, như được minh họa trong hình sau.

Các đội này như sau:

  • Nhóm phân tích nâng cao (hồ dữ liệu và lưới dữ liệu) – Kỹ sư dữ liệu chịu trách nhiệm chuẩn bị và nhập dữ liệu từ nhiều nguồn, xây dựng quy trình ETL (trích xuất, chuyển đổi và tải) để quản lý và lập danh mục dữ liệu, đồng thời chuẩn bị dữ liệu lịch sử cần thiết cho các trường hợp sử dụng ML. Những chủ sở hữu dữ liệu này tập trung vào việc cung cấp quyền truy cập vào dữ liệu của họ cho nhiều đơn vị hoặc nhóm kinh doanh.
  • Nhóm khoa học dữ liệu – Các nhà khoa học dữ liệu cần tập trung vào việc tạo ra mô hình tốt nhất dựa trên các chỉ số hiệu suất chính (KPI) được xác định trước làm việc trong sổ ghi chép. Sau khi hoàn thành giai đoạn nghiên cứu, các nhà khoa học dữ liệu cần cộng tác với các kỹ sư ML để tạo ra các quy trình tự động hóa cho việc xây dựng (đường dẫn ML) và triển khai các mô hình vào sản xuất bằng cách sử dụng đường dẫn CI/CD.
  • Đội ngũ kinh doanh – Chủ sở hữu sản phẩm chịu trách nhiệm xác định trường hợp kinh doanh, các yêu cầu và KPI được sử dụng để đánh giá hiệu suất của mô hình. Người tiêu dùng ML là các bên liên quan kinh doanh khác sử dụng kết quả suy luận (dự đoán) để đưa ra quyết định.
  • Nhóm nền tảng – Kiến trúc sư chịu trách nhiệm về kiến ​​trúc đám mây tổng thể của doanh nghiệp và cách tất cả các dịch vụ khác nhau được kết nối với nhau. Các doanh nghiệp vừa và nhỏ về bảo mật xem xét kiến ​​trúc dựa trên các chính sách và nhu cầu bảo mật kinh doanh. Các kỹ sư MLOps chịu trách nhiệm cung cấp một môi trường an toàn cho các nhà khoa học dữ liệu và kỹ sư ML để tạo ra các trường hợp sử dụng ML. Cụ thể, họ chịu trách nhiệm chuẩn hóa các quy trình CI/CD, vai trò của người dùng và dịch vụ cũng như việc tạo vùng chứa, sử dụng mô hình, thử nghiệm và phương pháp triển khai dựa trên các yêu cầu kinh doanh và bảo mật.
  • Nhóm rủi ro và tuân thủ – Đối với những môi trường hạn chế hơn, kiểm toán viên có trách nhiệm đánh giá dữ liệu, mã và các tạo phẩm mô hình, đồng thời đảm bảo rằng doanh nghiệp tuân thủ các quy định, chẳng hạn như quyền riêng tư dữ liệu.

Lưu ý rằng nhiều cá nhân có thể được đảm nhiệm bởi cùng một người tùy thuộc vào quy mô và mức độ trưởng thành MLOps của doanh nghiệp.

Những cá nhân này cần môi trường chuyên dụng để thực hiện các quy trình khác nhau, như được minh họa trong hình sau.

Các môi trường như sau:

  • Quản trị nền tảng – Môi trường quản trị nền tảng là nơi nhóm nền tảng có quyền truy cập để tạo tài khoản AWS và liên kết đúng người dùng và dữ liệu
  • Ngày – Lớp dữ liệu, thường được gọi là hồ dữ liệu hoặc lưới dữ liệu, là môi trường mà các kỹ sư hoặc chủ sở hữu dữ liệu và các bên liên quan trong kinh doanh sử dụng để chuẩn bị, tương tác và trực quan hóa dữ liệu
  • Thử nghiệm – Các nhà khoa học dữ liệu sử dụng hộp cát hoặc môi trường thử nghiệm để kiểm tra các thư viện và kỹ thuật ML mới nhằm chứng minh rằng bằng chứng về khái niệm của họ có thể giải quyết các vấn đề kinh doanh
  • Xây dựng mô hình, thử nghiệm mô hình, triển khai mô hình – Môi trường xây dựng, thử nghiệm và triển khai mô hình là lớp MLOps, nơi các nhà khoa học dữ liệu và kỹ sư ML cộng tác để tự động hóa và chuyển nghiên cứu sang sản xuất
  • Quản trị ML – Phần cuối cùng của câu đố là môi trường quản trị ML, nơi tất cả các tạo phẩm mô hình và mã được lưu trữ, xem xét và kiểm tra bởi các cá nhân tương ứng

Sơ đồ sau minh họa kiến ​​trúc tham chiếu, đã được thảo luận trong Lộ trình nền tảng MLOps cho các doanh nghiệp với Amazon SageMaker.

Mỗi đơn vị kinh doanh có mỗi nhóm tài khoản phát triển (đào tạo và xây dựng mô hình tự động), tiền sản xuất (thử nghiệm tự động) và sản xuất (triển khai và phục vụ mô hình) để tạo ra các trường hợp sử dụng ML, lấy dữ liệu từ hồ dữ liệu hoặc dữ liệu tập trung hoặc phi tập trung lưới tương ứng. Tất cả các mô hình được sản xuất và tự động hóa mã được lưu trữ trong tài khoản công cụ tập trung bằng khả năng đăng ký mô hình. Mã cơ sở hạ tầng cho tất cả các tài khoản này được phiên bản trong một tài khoản dịch vụ dùng chung (tài khoản quản trị phân tích nâng cao) mà nhóm nền tảng có thể trừu tượng hóa, tạo khuôn mẫu, duy trì và sử dụng lại để đưa vào nền tảng MLOps của mọi nhóm mới.

Các định nghĩa và sự khác biệt của AI sáng tạo đối với MLOps

Trong ML cổ điển, sự kết hợp trước đó giữa con người, quy trình và công nghệ có thể giúp bạn tạo ra các trường hợp sử dụng ML của mình. Tuy nhiên, trong Generative AI, bản chất của các trường hợp sử dụng đòi hỏi phải mở rộng các khả năng đó hoặc các khả năng mới. Một trong những khái niệm mới này là mô hình nền tảng (FM). Chúng được gọi như vậy vì chúng có thể được sử dụng để tạo ra nhiều mô hình AI khác, như được minh họa trong hình dưới đây.

FM đã được đào tạo dựa trên hàng terabyte dữ liệu và có hàng trăm tỷ tham số để có thể dự đoán câu trả lời tốt nhất tiếp theo dựa trên ba loại trường hợp sử dụng AI tổng hợp chính:

  • Chuyển văn bản thành văn bản – FM (LLM) đã được đào tạo dựa trên dữ liệu chưa được gắn nhãn (chẳng hạn như văn bản tự do) và có thể dự đoán từ hoặc chuỗi từ tốt nhất tiếp theo (đoạn văn hoặc bài tiểu luận dài). Các trường hợp sử dụng chính xoay quanh các chatbot giống con người, tóm tắt hoặc tạo nội dung khác như mã lập trình.
  • chuyển văn bản thành hình ảnh – Dữ liệu được dán nhãn, chẳng hạn như các cặp , đã được sử dụng để huấn luyện FM, có khả năng dự đoán sự kết hợp pixel tốt nhất. Các trường hợp sử dụng ví dụ là tạo thiết kế quần áo hoặc hình ảnh cá nhân hóa tưởng tượng.
  • Chuyển văn bản thành âm thanh hoặc video – Cả dữ liệu được dán nhãn và không được gắn nhãn đều có thể được sử dụng để huấn luyện FM. Một ví dụ về trường hợp sử dụng AI tổng quát chính là sáng tác âm nhạc.

Để tạo ra các trường hợp sử dụng AI tổng quát đó, chúng tôi cần mượn và mở rộng miền MLOps để bao gồm những điều sau:

  • Hoạt động FM (FMOps) – Điều này có thể tạo ra các giải pháp AI tổng quát, bao gồm mọi loại trường hợp sử dụng
  • Hoạt động LLM (LLMOps) – Đây là tập hợp con của FMOps tập trung vào việc sản xuất các giải pháp dựa trên LLM, chẳng hạn như chuyển văn bản thành văn bản

Hình dưới đây minh họa sự chồng chéo của các trường hợp sử dụng này.

So với ML và MLOps cổ điển, FMOps và LLMOps trì hoãn dựa trên bốn danh mục chính mà chúng tôi đề cập trong các phần sau: con người và quy trình, lựa chọn và điều chỉnh FM, đánh giá và giám sát FM, quyền riêng tư dữ liệu và triển khai mô hình cũng như nhu cầu công nghệ. Chúng tôi sẽ đề cập đến việc giám sát trong một bài viết riêng.

Hành trình vận hành theo loại người dùng AI tổng quát

Để đơn giản hóa việc mô tả các quy trình, chúng ta cần phân loại các loại người dùng AI tổng quát chính, như thể hiện trong hình dưới đây.

Các loại người dùng như sau:

  • Nhà cung cấp – Người dùng xây dựng FM từ đầu và cung cấp chúng dưới dạng sản phẩm cho những người dùng khác (người tinh chỉnh và người tiêu dùng). Họ có chuyên môn sâu về ML và xử lý ngôn ngữ tự nhiên (NLP) cũng như kỹ năng khoa học dữ liệu cũng như đội ngũ biên tập và gắn nhãn dữ liệu khổng lồ.
  • Bộ tinh chỉnh – Người dùng đào tạo lại (tinh chỉnh) FM từ nhà cung cấp để phù hợp với yêu cầu tùy chỉnh. Họ điều phối việc triển khai mô hình như một dịch vụ để người tiêu dùng sử dụng. Những người dùng này cần kiến ​​thức chuyên môn về khoa học dữ liệu và ML toàn diện cũng như kiến ​​thức về triển khai và suy luận mô hình. Kiến thức vững chắc về miền để điều chỉnh, bao gồm cả kỹ thuật nhanh chóng, cũng được yêu cầu.
  • Người tiêu dùng – Người dùng tương tác với các dịch vụ AI tổng hợp từ nhà cung cấp hoặc công cụ tinh chỉnh bằng lời nhắc bằng văn bản hoặc giao diện trực quan để hoàn thành các hành động mong muốn. Không yêu cầu chuyên môn về ML nhưng chủ yếu là các nhà phát triển ứng dụng hoặc người dùng cuối có hiểu biết về khả năng dịch vụ. Chỉ có kỹ thuật nhanh chóng là cần thiết để có kết quả tốt hơn.

Theo định nghĩa và chuyên môn ML cần thiết, MLOps chủ yếu được yêu cầu đối với các nhà cung cấp và người tinh chỉnh, trong khi người tiêu dùng có thể sử dụng các nguyên tắc sản xuất ứng dụng, chẳng hạn như DevOps và AppDev để tạo ra các ứng dụng AI tổng quát. Hơn nữa, chúng tôi đã quan sát thấy sự chuyển động giữa các loại người dùng, trong đó nhà cung cấp có thể trở thành người tinh chỉnh để hỗ trợ các trường hợp sử dụng dựa trên một ngành dọc cụ thể (chẳng hạn như lĩnh vực tài chính) hoặc người tiêu dùng có thể trở thành người tinh chỉnh để đạt được kết quả chính xác hơn. Nhưng hãy quan sát các quy trình chính cho mỗi loại người dùng.

Hành trình của người tiêu dùng

Hình dưới đây minh họa hành trình của người tiêu dùng.

Như đã đề cập trước đó, người tiêu dùng được yêu cầu lựa chọn, kiểm tra và sử dụng FM, tương tác với nó bằng cách cung cấp đầu vào cụ thể, còn được gọi là nhắc nhở. Lời nhắc, trong bối cảnh lập trình máy tính và AI, đề cập đến đầu vào được cung cấp cho một mô hình hoặc hệ thống để tạo ra phản hồi. Điều này có thể ở dạng văn bản, lệnh hoặc câu hỏi mà hệ thống sử dụng để xử lý và tạo đầu ra. Sau đó, đầu ra do FM tạo ra có thể được sử dụng bởi người dùng cuối, những người này cũng có thể xếp hạng các đầu ra này để nâng cao phản hồi trong tương lai của mô hình.

Ngoài các quy trình cơ bản này, chúng tôi nhận thấy người tiêu dùng bày tỏ mong muốn tinh chỉnh một mô hình bằng cách khai thác chức năng do bộ tinh chỉnh cung cấp. Lấy ví dụ, một trang web tạo ra hình ảnh. Tại đây, người dùng cuối có thể thiết lập tài khoản riêng tư, tải ảnh cá nhân lên và sau đó tạo nội dung liên quan đến những hình ảnh đó (ví dụ: tạo hình ảnh mô tả người dùng cuối đi xe máy cầm kiếm hoặc ở một địa điểm kỳ lạ). Trong trường hợp này, ứng dụng AI tổng quát do người tiêu dùng thiết kế phải tương tác với phần phụ trợ tinh chỉnh thông qua API để cung cấp chức năng này cho người dùng cuối.

Tuy nhiên, trước khi đi sâu vào vấn đề đó, trước tiên chúng ta hãy tập trung vào hành trình lựa chọn, thử nghiệm, sử dụng, tương tác đầu vào và đầu ra cũng như xếp hạng, như minh họa trong hình sau.

*Tham chiếu FM có sẵn 15K

Bước 1. Tìm hiểu các khả năng FM hàng đầu

Có nhiều khía cạnh cần được xem xét khi lựa chọn mô hình nền móng, tùy thuộc vào trường hợp sử dụng, dữ liệu có sẵn, các quy định, v.v. Một danh sách kiểm tra tốt, mặc dù không toàn diện, có thể như sau:

  • FM độc quyền hoặc nguồn mở – Các mô hình độc quyền thường có chi phí tài chính cao nhưng chúng thường mang lại hiệu suất tốt hơn (về chất lượng của văn bản hoặc hình ảnh được tạo ra), thường được phát triển và duy trì bởi các nhóm nhà cung cấp mô hình tận tâm đảm bảo hiệu suất và độ tin cậy tối ưu. Mặt khác, chúng tôi cũng thấy việc áp dụng các mô hình nguồn mở, ngoài việc miễn phí, còn mang lại các lợi ích bổ sung là có thể truy cập và linh hoạt (ví dụ: mọi mô hình nguồn mở đều có thể tinh chỉnh được). Một ví dụ về mô hình độc quyền là mô hình Claude của Anthropic và một ví dụ về mô hình nguồn mở hiệu suất cao là Falcon-40B, tính đến tháng 2023 năm XNUMX.
  • Giấy phép thương mại – Việc cân nhắc cấp phép là rất quan trọng khi quyết định sử dụng FM. Điều quan trọng cần lưu ý là một số mô hình là nguồn mở nhưng không thể sử dụng cho mục đích thương mại do các hạn chế hoặc điều kiện cấp phép. Sự khác biệt có thể rất nhỏ: Phiên bản mới được phát hành xgen-7b-8k-cơ sở ví dụ: mô hình là mã nguồn mở và có thể sử dụng được về mặt thương mại (giấy phép Apache-2.0), trong khi phiên bản hướng dẫn được tinh chỉnh của mô hình xgen-7b-8k-inst chỉ được phát hành cho mục đích nghiên cứu. Khi chọn FM cho ứng dụng thương mại, điều cần thiết là phải xác minh thỏa thuận cấp phép, hiểu các hạn chế của nó và đảm bảo nó phù hợp với mục đích sử dụng dự định của dự án.
  • Thông số – Số lượng tham số, bao gồm trọng số và độ lệch trong mạng lưới thần kinh, là một yếu tố quan trọng khác. Nhiều tham số hơn thường có nghĩa là một mô hình phức tạp hơn và có tiềm năng mạnh mẽ hơn, bởi vì nó có thể nắm bắt được các mẫu và mối tương quan phức tạp hơn trong dữ liệu. Tuy nhiên, sự đánh đổi là nó đòi hỏi nhiều tài nguyên tính toán hơn và do đó tốn nhiều chi phí hơn để chạy. Ngoài ra, chúng tôi nhận thấy xu hướng hướng tới các mô hình nhỏ hơn, đặc biệt là trong không gian nguồn mở (các mô hình có quy mô từ 7–40 tỷ) hoạt động tốt, đặc biệt là khi được tinh chỉnh.
  • Tốc độ – Tốc độ của một mô hình bị ảnh hưởng bởi kích thước của nó. Các mô hình lớn hơn có xu hướng xử lý dữ liệu chậm hơn (độ trễ cao hơn) do độ phức tạp tính toán tăng lên. Do đó, điều quan trọng là phải cân bằng giữa nhu cầu về một mô hình có khả năng dự đoán cao (thường là các mô hình lớn hơn) với các yêu cầu thực tế về tốc độ, đặc biệt là trong các ứng dụng, như bot trò chuyện, yêu cầu phản hồi theo thời gian thực hoặc gần thời gian thực.
  • Kích thước cửa sổ ngữ cảnh (số lượng mã thông báo) – Cửa sổ ngữ cảnh, được xác định bằng số lượng mã thông báo tối đa có thể được nhập hoặc xuất trên mỗi lời nhắc, rất quan trọng trong việc xác định lượng ngữ cảnh mà mô hình có thể xem xét tại một thời điểm (một mã thông báo tạm dịch là 0.75 từ cho tiếng Anh). Các mô hình có cửa sổ ngữ cảnh lớn hơn có thể hiểu và tạo ra các chuỗi văn bản dài hơn, điều này có thể hữu ích cho các tác vụ liên quan đến các cuộc hội thoại hoặc tài liệu dài hơn.
  • Tập dữ liệu đào tạo – Điều quan trọng nữa là phải hiểu loại dữ liệu mà FM được đào tạo. Một số mô hình có thể được đào tạo trên các tập dữ liệu văn bản đa dạng như dữ liệu internet, tập lệnh mã hóa, hướng dẫn hoặc phản hồi của con người. Những người khác cũng có thể được đào tạo về bộ dữ liệu đa phương thức, như kết hợp dữ liệu văn bản và hình ảnh. Điều này có thể ảnh hưởng đến sự phù hợp của mô hình cho các nhiệm vụ khác nhau. Ngoài ra, một tổ chức có thể có những lo ngại về bản quyền tùy thuộc vào nguồn chính xác mà một mô hình đã được đào tạo—do đó, bắt buộc phải kiểm tra chặt chẽ tập dữ liệu đào tạo.
  • Chất lượng – Chất lượng của FM có thể thay đổi tùy theo loại của nó (độc quyền so với nguồn mở), kích thước và nội dung nó được đào tạo. Chất lượng phụ thuộc vào ngữ cảnh, nghĩa là những gì được coi là chất lượng cao đối với ứng dụng này có thể không dành cho ứng dụng khác. Ví dụ: một mô hình được đào tạo trên dữ liệu internet có thể được coi là chất lượng cao để tạo văn bản đàm thoại, nhưng lại kém hơn đối với các nhiệm vụ kỹ thuật hoặc chuyên môn.
  • Tinh chỉnh – Khả năng tinh chỉnh FM bằng cách điều chỉnh trọng lượng hoặc lớp mô hình của nó có thể là một yếu tố quan trọng. Tinh chỉnh cho phép mô hình thích ứng tốt hơn với bối cảnh cụ thể của ứng dụng, cải thiện hiệu suất đối với nhiệm vụ cụ thể trước mắt. Tuy nhiên, việc tinh chỉnh đòi hỏi thêm nguồn lực tính toán và chuyên môn kỹ thuật và không phải tất cả các mô hình đều hỗ trợ tính năng này. Các mô hình nguồn mở (nói chung) luôn có thể tinh chỉnh được vì các tạo phẩm mô hình có sẵn để tải xuống và người dùng có thể mở rộng và sử dụng chúng theo ý muốn. Các mô hình độc quyền đôi khi có thể cung cấp tùy chọn tinh chỉnh.
  • Kỹ năng khách hàng hiện tại – Việc lựa chọn FM cũng có thể bị ảnh hưởng bởi kỹ năng và sự quen thuộc của khách hàng hoặc nhóm phát triển. Nếu một tổ chức không có chuyên gia AI/ML trong nhóm của họ thì dịch vụ API có thể phù hợp hơn với họ. Ngoài ra, nếu một nhóm có nhiều kinh nghiệm với một FM cụ thể, việc tiếp tục sử dụng nó có thể sẽ hiệu quả hơn thay vì đầu tư thời gian và nguồn lực để tìm hiểu và thích ứng với một FM mới.

Sau đây là ví dụ về hai danh sách rút gọn, một dành cho các mô hình độc quyền và một dành cho các mô hình nguồn mở. Bạn có thể biên soạn các bảng tương tự dựa trên nhu cầu cụ thể của mình để có cái nhìn tổng quan nhanh về các tùy chọn có sẵn. Lưu ý rằng hiệu suất và thông số của các mô hình đó thay đổi nhanh chóng và có thể lỗi thời tại thời điểm đọc, trong khi các khả năng khác có thể quan trọng đối với các khách hàng cụ thể, chẳng hạn như ngôn ngữ được hỗ trợ.

Sau đây là ví dụ về FM độc quyền đáng chú ý có sẵn trong AWS (tháng 2023 năm XNUMX).

Sau đây là ví dụ về FM nguồn mở đáng chú ý có sẵn trong AWS (tháng 2023 năm XNUMX).

Sau khi bạn đã tổng hợp tổng quan về 10–20 mô hình ứng cử viên tiềm năng, bạn cần phải tinh chỉnh thêm danh sách rút gọn này. Trong phần này, chúng tôi đề xuất một cơ chế nhanh chóng sẽ mang lại hai hoặc ba mô hình cuối cùng khả thi làm ứng cử viên cho vòng tiếp theo.

Sơ đồ sau đây minh họa quá trình đưa vào danh sách rút gọn ban đầu.

Thông thường, các kỹ sư nhắc nhở là chuyên gia trong việc tạo ra các lời nhắc chất lượng cao cho phép các mô hình AI hiểu và xử lý thông tin đầu vào của người dùng, thử nghiệm nhiều phương pháp khác nhau để thực hiện cùng một nhiệm vụ (chẳng hạn như tóm tắt) trên một mô hình. Chúng tôi đề xuất rằng những lời nhắc này không được tạo nhanh chóng mà được trích xuất một cách có hệ thống từ danh mục lời nhắc. Danh mục lời nhắc này là vị trí trung tâm để lưu trữ các lời nhắc nhằm tránh trùng lặp, cho phép kiểm soát phiên bản và chia sẻ lời nhắc trong nhóm nhằm đảm bảo tính nhất quán giữa những người thử nghiệm lời nhắc khác nhau trong các giai đoạn phát triển khác nhau mà chúng tôi sẽ giới thiệu trong phần tiếp theo. Danh mục lời nhắc này tương tự như kho lưu trữ Git của cửa hàng tính năng. Sau đó, nhà phát triển AI tổng quát, người có thể là cùng một người với kỹ sư nhắc việc, sau đó cần đánh giá kết quả đầu ra để xác định xem liệu nó có phù hợp với ứng dụng AI tổng quát mà họ đang tìm cách phát triển hay không.

Bước 2. Kiểm tra và đánh giá FM top

Sau khi danh sách rút gọn giảm xuống còn khoảng ba FM, chúng tôi khuyên bạn nên thực hiện một bước đánh giá để kiểm tra thêm khả năng và tính phù hợp của FM đối với trường hợp sử dụng. Tùy thuộc vào tính sẵn có và tính chất của dữ liệu đánh giá, chúng tôi đề xuất các phương pháp khác nhau, như được minh họa trong hình sau.

Phương pháp sử dụng đầu tiên phụ thuộc vào việc bạn đã dán nhãn dữ liệu thử nghiệm hay chưa.

Nếu đã gắn nhãn dữ liệu, bạn có thể sử dụng dữ liệu đó để tiến hành đánh giá mô hình, giống như chúng tôi thực hiện với các mô hình ML truyền thống (nhập một số mẫu và so sánh kết quả đầu ra với nhãn). Tùy thuộc vào việc dữ liệu thử nghiệm có các nhãn riêng biệt (chẳng hạn như phân tích cảm tính tích cực, tiêu cực hay trung tính) hay là văn bản phi cấu trúc (chẳng hạn như tóm tắt), chúng tôi đề xuất các phương pháp đánh giá khác nhau:

  • Số liệu chính xác – Trong trường hợp đầu ra rời rạc (chẳng hạn như phân tích cảm xúc), chúng ta có thể sử dụng các số liệu về độ chính xác tiêu chuẩn như độ chính xác, khả năng thu hồi và điểm F1
  • Số liệu tương tự – Nếu đầu ra không có cấu trúc (chẳng hạn như bản tóm tắt), chúng tôi đề xuất các số liệu tương tự như độ tương tự ROUGE và cosine

Một số trường hợp sử dụng không cho phép có một câu trả lời đúng (ví dụ: “Tạo một câu chuyện ngắn dành cho trẻ em cho cô con gái 5 tuổi của tôi”). Trong những trường hợp như vậy, việc đánh giá các mô hình sẽ trở nên khó khăn hơn vì bạn không có dữ liệu thử nghiệm được gắn nhãn. Chúng tôi đề xuất hai cách tiếp cận, tùy thuộc vào tầm quan trọng của việc đánh giá mô hình của con người so với đánh giá tự động:

  • Con người trong vòng lặp (HIL) – Trong trường hợp này, một nhóm người kiểm tra kịp thời sẽ xem xét các phản hồi từ một mô hình. Tùy thuộc vào mức độ quan trọng của ứng dụng, người kiểm tra kịp thời có thể xem xét 100% kết quả đầu ra của mô hình hoặc chỉ một mẫu.
  • Đánh giá dựa trên LLM – Trong trường hợp này, những người thử nghiệm nhanh chóng được thay thế bằng LLM, lý tưởng nhất là LLM mạnh hơn (mặc dù có lẽ chậm hơn và tốn kém nhất) so với những người đang được thử nghiệm. LLM sẽ xem xét tất cả các phản hồi do mô hình tạo ra và cho điểm chúng. Phương pháp này có thể mang lại chất lượng thấp hơn, nhưng đây là tùy chọn đánh giá rẻ hơn và nhanh hơn, có thể cung cấp thước đo ban đầu tốt về hiệu suất của mô hình.

Ví dụ: chúng tôi có thể sử dụng lời nhắc ví dụ sau cho LLM, bao gồm truy vấn đầu vào, phản hồi LLM và hướng dẫn: “Chúng tôi muốn yêu cầu phản hồi của bạn về hiệu suất của trợ lý AI để trả lời câu hỏi của người dùng được hiển thị ở trên . Vui lòng đánh giá mức độ hữu ích, mức độ phù hợp, độ chính xác, mức độ chi tiết trong câu trả lời của trợ lý. Trợ lý sẽ nhận được điểm tổng thể theo thang điểm từ 1 đến 10, trong đó điểm cao hơn cho thấy hiệu suất tổng thể tốt hơn.”

Lời nhắc này sẽ được gửi đến một LLM khác (EvalLLM) để đánh giá. Sau đây là ví dụ trong đó phản hồi của mẫu Falcon-40B đã được đánh giá bởi EvalLLM (trong trường hợp này là Claude). Chúng tôi sử dụng câu hỏi “Điều gì sẽ xảy ra nếu kênh đào Suez chưa bao giờ được xây dựng?” Câu trả lời như sau:

Câu hỏi: Điều gì sẽ xảy ra nếu kênh đào Suez chưa bao giờ được xây dựng?

falcon-40b-hướng dẫn

Nếu kênh đào Suez chưa bao giờ được xây dựng, tàu bè sẽ phải đi vòng quanh châu Phi để di chuyển giữa Địa Trung Hải và Biển Đỏ. Điều này sẽ làm tăng thêm thời gian và khoảng cách đáng kể cho chuyến đi, khiến nó kém hiệu quả hơn và tốn kém hơn. Ngoài ra, nếu không có kênh đào Suez, nhiều quốc gia ở Trung Đông và Bắc Phi sẽ ít kết nối hơn với phần còn lại của thế giới, cản trở sự phát triển kinh tế và văn hóa.

Đánh giá (Điểm: 9/10)

Phản hồi của trợ lý rất phù hợp, chính xác và chi tiết. Nó cung cấp câu trả lời xuất sắc cho câu hỏi giả định của người dùng về sự không tồn tại của Kênh đào Suez. Người trợ lý chỉ ra một cách chính xác những tác động đối với việc đi lại bằng đường biển cũng như tác động về kinh tế và văn hóa đối với Trung Đông và Bắc Phi. Tuy nhiên, nó có thể trình bày chi tiết hơn về những tác động địa chính trị hoặc tác động lên mô hình thương mại toàn cầu để có phản ứng toàn diện hơn.

Hình dưới đây minh họa ví dụ về quy trình đánh giá từ đầu đến cuối.

Dựa trên ví dụ này, để thực hiện đánh giá, chúng tôi cần cung cấp các lời nhắc mẫu mà chúng tôi lưu trữ trong danh mục lời nhắc và tập dữ liệu được gắn nhãn hoặc không gắn nhãn đánh giá dựa trên các ứng dụng cụ thể của chúng tôi. Ví dụ: với tập dữ liệu đánh giá được gắn nhãn, chúng tôi có thể cung cấp lời nhắc (đầu vào và truy vấn), chẳng hạn như “Hãy cho tôi biết tên đầy đủ của Thủ tướng Vương quốc Anh vào năm 2023” cũng như các kết quả đầu ra và câu trả lời, chẳng hạn như “Rishi Sunak”. Với tập dữ liệu không được gắn nhãn, chúng tôi chỉ cung cấp câu hỏi hoặc hướng dẫn, chẳng hạn như “Tạo mã nguồn cho trang web bán lẻ”. Chúng tôi gọi sự kết hợp giữa danh mục kịp thời và tập dữ liệu đánh giá là danh mục nhắc nhở đánh giá. Lý do chúng tôi phân biệt danh mục lời nhắc và danh mục lời nhắc đánh giá là vì danh mục sau được dành riêng cho một trường hợp sử dụng cụ thể thay vì các lời nhắc và hướng dẫn chung chung (chẳng hạn như trả lời câu hỏi) có trong danh mục lời nhắc.

Với danh mục lời nhắc đánh giá này, bước tiếp theo là cung cấp lời nhắc đánh giá cho các FM hàng đầu. Kết quả là một tập dữ liệu kết quả đánh giá chứa các lời nhắc, đầu ra của từng FM và đầu ra được gắn nhãn cùng với điểm số (nếu có). Trong trường hợp danh mục lời nhắc đánh giá không được gắn nhãn, có một bước bổ sung để HIL hoặc LLM xem xét kết quả và đưa ra điểm số cũng như phản hồi (như chúng tôi đã mô tả trước đó). Kết quả cuối cùng sẽ là kết quả tổng hợp kết hợp điểm số của tất cả kết quả đầu ra (tính độ chính xác trung bình hoặc đánh giá của con người) và cho phép người dùng đánh giá chất lượng của mô hình.

Sau khi thu thập được kết quả đánh giá, chúng tôi đề xuất lựa chọn mô hình dựa trên một số khía cạnh. Những điều này thường liên quan đến các yếu tố như độ chính xác, tốc độ và chi phí. Hình dưới đây cho thấy một ví dụ.

Mỗi mô hình sẽ có những điểm mạnh và những đánh đổi nhất định theo các khía cạnh này. Tùy thuộc vào trường hợp sử dụng, chúng ta nên chỉ định mức độ ưu tiên khác nhau cho các thứ nguyên này. Trong ví dụ trước, chúng tôi đã chọn ưu tiên chi phí là yếu tố quan trọng nhất, tiếp theo là độ chính xác và sau đó là tốc độ. Mặc dù nó chậm hơn và không hiệu quả như FM1 nhưng nó vẫn đủ hiệu quả và rẻ hơn đáng kể để lưu trữ. Do đó, chúng tôi có thể chọn FM2 là lựa chọn hàng đầu.

Bước 3. Phát triển phần phụ trợ và giao diện người dùng của ứng dụng AI tổng quát

Tại thời điểm này, các nhà phát triển AI sáng tạo đã chọn FM phù hợp cho ứng dụng cụ thể cùng với sự trợ giúp của các kỹ sư và người thử nghiệm nhanh chóng. Bước tiếp theo là bắt đầu phát triển ứng dụng AI tổng quát. Chúng tôi đã tách quá trình phát triển ứng dụng Generative AI thành hai lớp, lớp phụ trợ và giao diện người dùng, như trong hình sau.

Ở phần phụ trợ, các nhà phát triển AI tổng quát kết hợp FM đã chọn vào các giải pháp và làm việc cùng với các kỹ sư nhắc nhở để tạo ra tính năng tự động hóa nhằm chuyển đổi đầu vào của người dùng cuối thành lời nhắc FM thích hợp. Người kiểm tra lời nhắc tạo các mục cần thiết vào danh mục lời nhắc để kiểm tra tự động hoặc thủ công (HIL hoặc LLM). Sau đó, các nhà phát triển AI sáng tạo tạo ra cơ chế ứng dụng và chuỗi nhanh chóng để cung cấp đầu ra cuối cùng. Trong bối cảnh này, chuỗi nhắc nhở là một kỹ thuật để tạo ra các ứng dụng LLM năng động hơn và nhận biết theo ngữ cảnh hơn. Nó hoạt động bằng cách chia nhỏ một nhiệm vụ phức tạp thành một loạt các nhiệm vụ phụ nhỏ hơn, dễ quản lý hơn. Ví dụ: nếu chúng tôi hỏi LLM câu hỏi “Thủ tướng Vương quốc Anh sinh ra ở đâu và địa điểm đó cách London bao xa”, thì nhiệm vụ có thể được chia thành các lời nhắc riêng lẻ, trong đó lời nhắc có thể được xây dựng dựa trên câu trả lời. của một đánh giá kịp thời trước đó, chẳng hạn như “Thủ tướng Vương quốc Anh là ai”, “Nơi sinh của họ là gì” và “Nơi đó cách London bao xa?” Để đảm bảo chất lượng đầu vào và đầu ra nhất định, các nhà phát triển AI tổng quát cũng cần tạo cơ chế giám sát và lọc đầu vào và đầu ra ứng dụng của người dùng cuối. Ví dụ: nếu ứng dụng LLM được cho là tránh các yêu cầu và phản hồi độc hại, họ có thể áp dụng trình phát hiện độc tính cho đầu vào và đầu ra và lọc chúng ra. Cuối cùng, họ cần cung cấp một cơ chế xếp hạng để hỗ trợ việc tăng cường danh mục gợi ý đánh giá với các ví dụ tốt và xấu. Một trình bày chi tiết hơn về các cơ chế đó sẽ được trình bày trong các bài viết sau.

Để cung cấp chức năng cho người dùng cuối AI tổng quát, việc phát triển một trang web giao diện người dùng tương tác với phần phụ trợ là cần thiết. Do đó, các cá nhân DevOps và AppDev (nhà phát triển ứng dụng trên đám mây) cần tuân theo các phương pháp phát triển tốt nhất để triển khai chức năng đầu vào/đầu ra và xếp hạng.

Ngoài chức năng cơ bản này, giao diện người dùng và phụ trợ cần kết hợp tính năng tạo tài khoản người dùng cá nhân, tải lên dữ liệu, bắt đầu tinh chỉnh dưới dạng hộp đen và sử dụng mô hình được cá nhân hóa thay vì FM cơ bản. Việc sản xuất một ứng dụng AI tổng quát cũng tương tự như một ứng dụng thông thường. Hình dưới đây mô tả một kiến ​​trúc ví dụ.

Trong kiến ​​trúc này, các nhà phát triển AI tổng quát, kỹ sư nhắc nhở và DevOps hoặc AppDev tạo và kiểm tra ứng dụng theo cách thủ công bằng cách triển khai ứng dụng đó qua CI/CD đến môi trường phát triển (Nhà phát triển ứng dụng AI tổng quát trong hình trước) bằng cách sử dụng kho lưu trữ mã chuyên dụng và hợp nhất với nhánh dev. Ở giai đoạn này, các nhà phát triển AI tổng quát sẽ sử dụng FM tương ứng bằng cách gọi API như đã được cung cấp bởi các nhà cung cấp bộ điều chỉnh FM. Sau đó, để kiểm tra ứng dụng một cách rộng rãi, họ cần quảng bá mã đến nhánh thử nghiệm, điều này sẽ kích hoạt quá trình triển khai thông qua CI/CD đến môi trường tiền sản xuất (generative AI App Pre-prod). Ở môi trường này, người kiểm tra lời nhắc cần thử một lượng lớn các kết hợp lời nhắc và xem xét kết quả. Sự kết hợp của các lời nhắc, đầu ra và đánh giá cần được chuyển sang danh mục lời nhắc đánh giá để tự động hóa quy trình thử nghiệm trong tương lai. Sau thử nghiệm mở rộng này, bước cuối cùng là thúc đẩy ứng dụng Generative AI vào sản xuất thông qua CI/CD bằng cách hợp nhất với nhánh chính (Generative AI App Prod). Lưu ý rằng tất cả dữ liệu, bao gồm danh mục lời nhắc, dữ liệu và kết quả đánh giá, dữ liệu và siêu dữ liệu của người dùng cuối cũng như siêu dữ liệu mô hình đã được tinh chỉnh, cần phải được lưu trữ trong hồ dữ liệu hoặc lớp lưới dữ liệu. Các đường dẫn và kho lưu trữ CI/CD cần được lưu trữ trong một tài khoản công cụ riêng biệt (tương tự như tài khoản được mô tả cho MLOps).

Hành trình của nhà cung cấp

Các nhà cung cấp FM cần đào tạo FM, chẳng hạn như các mô hình học sâu. Đối với họ, vòng đời và cơ sở hạ tầng MLOps từ đầu đến cuối là cần thiết. Cần bổ sung trong việc chuẩn bị dữ liệu lịch sử, đánh giá mô hình và giám sát. Hình dưới đây minh họa cuộc hành trình của họ.

Trong ML cổ điển, dữ liệu lịch sử thường được tạo ra bằng cách cung cấp thông tin cơ bản thông qua các đường dẫn ETL. Ví dụ: trong trường hợp sử dụng dự đoán tỷ lệ rời bỏ, tính năng tự động hóa sẽ cập nhật bảng cơ sở dữ liệu dựa trên trạng thái mới của khách hàng để tự động rời bỏ/không rời bỏ. Trong trường hợp FM, chúng cần hàng tỷ điểm dữ liệu được dán nhãn hoặc không được gắn nhãn. Trong trường hợp sử dụng tính năng chuyển văn bản thành hình ảnh, một nhóm người gắn nhãn dữ liệu cần gắn nhãn cặp theo cách thủ công. Đây là một hoạt động tốn kém đòi hỏi một lượng lớn nguồn nhân lực. Amazon SageMaker Ground Truth Plus có thể cung cấp một nhóm người gắn nhãn để thực hiện hoạt động này cho bạn. Đối với một số trường hợp sử dụng, quy trình này cũng có thể được tự động hóa một phần, chẳng hạn như bằng cách sử dụng các mô hình giống CLIP. Trong trường hợp LLM, chẳng hạn như chuyển văn bản thành văn bản, dữ liệu không được gắn nhãn. Tuy nhiên, chúng cần phải được chuẩn bị và tuân theo định dạng của dữ liệu lịch sử chưa được gắn nhãn hiện có. Vì vậy, cần có người chỉnh sửa dữ liệu để thực hiện việc chuẩn bị dữ liệu cần thiết và đảm bảo tính nhất quán.

Với dữ liệu lịch sử đã được chuẩn bị, bước tiếp theo là đào tạo và sản xuất mô hình. Lưu ý rằng có thể sử dụng các kỹ thuật đánh giá tương tự như chúng tôi đã mô tả cho người tiêu dùng.

Hành trình của những người tinh chỉnh

Bộ tinh chỉnh nhằm mục đích điều chỉnh FM hiện có cho phù hợp với bối cảnh cụ thể của chúng. Ví dụ: mô hình FM có thể tóm tắt văn bản có mục đích chung nhưng báo cáo tài chính không chính xác hoặc không thể tạo mã nguồn cho ngôn ngữ lập trình không phổ biến. Trong những trường hợp đó, người tinh chỉnh cần gắn nhãn dữ liệu, tinh chỉnh mô hình bằng cách chạy công việc đào tạo, triển khai mô hình, kiểm tra mô hình dựa trên quy trình của người tiêu dùng và giám sát mô hình. Sơ đồ sau đây minh họa quá trình này.

Hiện tại, có hai cơ chế tinh chỉnh:

  • Tinh chỉnh – Bằng cách sử dụng FM và dữ liệu được dán nhãn, công việc đào tạo sẽ tính toán lại trọng số và độ lệch của các lớp mô hình học sâu. Quá trình này có thể đòi hỏi nhiều tính toán và đòi hỏi một lượng dữ liệu lớn nhưng có thể tạo ra kết quả chính xác.
  • Tinh chỉnh tham số hiệu quả (PEFT) – Thay vì tính toán lại tất cả các trọng số và độ lệch, các nhà nghiên cứu đã chỉ ra rằng bằng cách thêm các lớp nhỏ bổ sung vào các mô hình deep learning, họ có thể đạt được kết quả khả quan (ví dụ: LoRA). PEFT yêu cầu sức mạnh tính toán thấp hơn so với tinh chỉnh sâu và công việc đào tạo với ít dữ liệu đầu vào hơn. Hạn chế là độ chính xác có thể thấp hơn.

Sơ đồ sau đây minh họa các cơ chế này.

Bây giờ chúng tôi đã xác định hai phương pháp tinh chỉnh chính, bước tiếp theo là xác định cách chúng tôi có thể triển khai và sử dụng FM độc quyền và nguồn mở.

Với FM nguồn mở, người tinh chỉnh có thể tải xuống tạo phẩm mô hình và mã nguồn từ web, chẳng hạn bằng cách sử dụng Trung tâm mô hình khuôn mặt ôm. Điều này mang lại cho bạn sự linh hoạt để tinh chỉnh sâu mô hình, lưu trữ nó vào sổ đăng ký mô hình cục bộ và triển khai nó vào một máy chủ. Amazon SageMaker điểm cuối. Quá trình này yêu cầu kết nối internet. Để hỗ trợ các môi trường an toàn hơn (chẳng hạn như dành cho khách hàng trong lĩnh vực tài chính), bạn có thể tải xuống mô hình tại cơ sở, chạy tất cả các bước kiểm tra bảo mật cần thiết và tải chúng lên bộ chứa cục bộ trên tài khoản AWS. Sau đó, bộ điều chỉnh sử dụng FM từ bộ chứa cục bộ mà không cần kết nối internet. Điều này đảm bảo quyền riêng tư của dữ liệu và dữ liệu không truyền qua internet. Sơ đồ sau đây minh họa phương pháp này.

Với FM độc quyền, quy trình triển khai sẽ khác vì những người tinh chỉnh không có quyền truy cập vào tạo phẩm mô hình hoặc mã nguồn. Các mô hình được lưu trữ trong tài khoản AWS và cơ quan đăng ký mô hình của nhà cung cấp FM độc quyền. Để triển khai mô hình như vậy đến điểm cuối SageMaker, người tinh chỉnh chỉ có thể yêu cầu gói mô hình sẽ được triển khai trực tiếp đến điểm cuối. Quá trình này yêu cầu sử dụng dữ liệu khách hàng trong tài khoản của nhà cung cấp FM độc quyền, điều này đặt ra câu hỏi liên quan đến dữ liệu nhạy cảm với khách hàng đang được sử dụng trong tài khoản từ xa để thực hiện tinh chỉnh và các mô hình được lưu trữ trong sổ đăng ký mô hình được chia sẻ giữa nhiều khách hàng . Điều này dẫn đến vấn đề nhiều người thuê nhà trở nên khó khăn hơn nếu các nhà cung cấp FM độc quyền cần phục vụ các mô hình này. Nếu bộ tinh chỉnh sử dụng nền tảng Amazon, những thách thức này đã được giải quyết—dữ liệu không truyền qua internet và các nhà cung cấp FM không có quyền truy cập vào dữ liệu của người tinh chỉnh. Những thách thức tương tự cũng xảy ra đối với các mô hình nguồn mở nếu những người tinh chỉnh muốn phục vụ các mô hình từ nhiều khách hàng, chẳng hạn như ví dụ chúng tôi đã đưa ra trước đó với trang web mà hàng nghìn khách hàng sẽ tải hình ảnh được cá nhân hóa lên. Tuy nhiên, những tình huống này có thể được coi là có thể kiểm soát được vì chỉ có bộ điều chỉnh tinh chỉnh tham gia. Sơ đồ sau đây minh họa phương pháp này.

Từ góc độ công nghệ, kiến ​​trúc mà bộ tinh chỉnh cần hỗ trợ giống như kiến ​​trúc dành cho MLOps (xem hình sau). Việc tinh chỉnh cần được tiến hành trong nhà phát triển bằng cách tạo các đường dẫn ML, chẳng hạn như sử dụng Đường ống Amazon SageMaker; thực hiện tiền xử lý, tinh chỉnh (công việc đào tạo) và xử lý hậu kỳ; và gửi các mô hình đã tinh chỉnh đến cơ quan đăng ký mô hình cục bộ trong trường hợp FM nguồn mở (nếu không, mô hình mới sẽ được lưu trữ trong môi trường cung cấp FM độc quyền). Sau đó, trong giai đoạn tiền sản xuất, chúng tôi cần thử nghiệm mô hình như chúng tôi mô tả cho trường hợp của người tiêu dùng. Cuối cùng, mô hình sẽ được phục vụ và giám sát trong sản phẩm. Lưu ý rằng FM hiện tại (được tinh chỉnh) yêu cầu điểm cuối của phiên bản GPU. Nếu chúng ta cần triển khai từng mô hình tinh chỉnh đến một điểm cuối riêng biệt, điều này có thể làm tăng chi phí trong trường hợp có hàng trăm mô hình. Do đó, chúng ta cần sử dụng các điểm cuối đa mô hình và giải quyết thách thức nhiều bên thuê.

Những người tinh chỉnh điều chỉnh mô hình FM dựa trên bối cảnh cụ thể để sử dụng nó cho mục đích kinh doanh của họ. Điều đó có nghĩa là trong hầu hết các trường hợp, người tinh chỉnh cũng là người tiêu dùng được yêu cầu hỗ trợ tất cả các lớp, như chúng tôi đã mô tả trong các phần trước, bao gồm phát triển ứng dụng AI tổng quát, hồ dữ liệu và lưới dữ liệu cũng như MLOps.

Hình dưới đây minh họa vòng đời tinh chỉnh FM hoàn chỉnh mà bộ tinh chỉnh cần cung cấp cho người dùng cuối AI tổng quát.

Hình dưới đây minh họa các bước chính.

Các bước chính như sau:

  1. Người dùng cuối tạo một tài khoản cá nhân và tải lên dữ liệu riêng tư.
  2. Dữ liệu được lưu trữ trong hồ dữ liệu và được xử lý trước để tuân theo định dạng mà FM mong đợi.
  3. Điều này kích hoạt một quy trình ML tinh chỉnh để thêm mô hình vào sổ đăng ký mô hình,
  4. Từ đó, mô hình được triển khai vào sản xuất với thử nghiệm tối thiểu hoặc mô hình đẩy mạnh thử nghiệm rộng rãi với HIL và các cổng phê duyệt thủ công.
  5. Mô hình tinh chỉnh được cung cấp cho người dùng cuối.

Vì cơ sở hạ tầng này phức tạp đối với khách hàng phi doanh nghiệp nên AWS đã phát hành Amazon Bedrock để giảm bớt nỗ lực tạo ra những kiến ​​trúc như vậy và đưa FM tinh chỉnh đến gần hơn với hoạt động sản xuất.

Các yếu tố phân biệt và phân biệt quy trình của FMOps và LLMOps

Dựa trên hành trình của loại người dùng trước đó (người tiêu dùng, nhà sản xuất và người tinh chỉnh), cần có những nhân cách mới với các kỹ năng cụ thể, như được minh họa trong hình sau.

Các nhân vật mới như sau:

  • Trình gắn nhãn và biên tập dữ liệu – Những người dùng này gắn nhãn dữ liệu, chẳng hạn như ghép nối hoặc chuẩn bị dữ liệu chưa được gắn nhãn, chẳng hạn như văn bản tự do, đồng thời mở rộng nhóm phân tích nâng cao và môi trường hồ dữ liệu.
  • Bộ tinh chỉnh – Những người dùng này có kiến ​​thức sâu về FM và biết cách điều chỉnh chúng, mở rộng nhóm khoa học dữ liệu sẽ tập trung vào ML cổ điển.
  • Các nhà phát triển AI sáng tạo – Họ có kiến ​​thức sâu về việc chọn FM, chuỗi lời nhắc và ứng dụng cũng như lọc đầu vào và đầu ra. Họ thuộc về một nhóm mới—nhóm ứng dụng AI sáng tạo.
  • Kỹ sư nhắc nhở – Những người dùng này thiết kế lời nhắc đầu vào và đầu ra để điều chỉnh giải pháp cho phù hợp với ngữ cảnh, đồng thời thử nghiệm và tạo phiên bản ban đầu của danh mục lời nhắc. Nhóm của họ là nhóm ứng dụng AI tổng quát.
  • Người kiểm tra nhanh chóng – Họ thử nghiệm trên quy mô lớn giải pháp AI tổng quát (phụ trợ và giao diện người dùng) và cung cấp kết quả của mình để bổ sung cho danh mục nhanh chóng và tập dữ liệu đánh giá. Nhóm của họ là nhóm ứng dụng AI tổng quát.
  • AppDev và DevOps – Họ phát triển giao diện người dùng (chẳng hạn như trang web) của ứng dụng AI tổng quát. Nhóm của họ là nhóm ứng dụng AI tổng quát.
  • Người dùng cuối AI sáng tạo – Những người dùng này sử dụng các ứng dụng AI tổng hợp dưới dạng hộp đen, chia sẻ dữ liệu và đánh giá chất lượng đầu ra.

Phiên bản mở rộng của bản đồ quy trình MLOps để kết hợp AI tổng hợp có thể được minh họa bằng hình sau.

Lớp ứng dụng mới là môi trường nơi các nhà phát triển AI tổng quát, kỹ sư nhắc nhở, người thử nghiệm và AppDev tạo ra phần phụ trợ và giao diện người dùng của các ứng dụng AI tổng quát. Người dùng cuối AI tổng quát tương tác với giao diện người dùng AI tổng quát thông qua internet (chẳng hạn như giao diện người dùng web). Mặt khác, người gắn nhãn và biên tập dữ liệu cần xử lý trước dữ liệu mà không cần truy cập vào phần phụ trợ của hồ dữ liệu hoặc lưới dữ liệu. Do đó, cần có giao diện người dùng web (trang web) có trình chỉnh sửa để tương tác an toàn với dữ liệu. SageMaker Ground Truth cung cấp chức năng này ngay lập tức.

Kết luận

MLOps có thể giúp chúng tôi sản xuất các mô hình ML một cách hiệu quả. Tuy nhiên, để vận hành các ứng dụng AI tổng quát, bạn cần có thêm các kỹ năng, quy trình và công nghệ, dẫn đến FMOps và LLMOps. Trong bài đăng này, chúng tôi đã xác định các khái niệm chính về FMOps và LLMOps, đồng thời mô tả các điểm khác biệt chính so với khả năng của MLOps về mặt con người, quy trình, công nghệ, lựa chọn và đánh giá mô hình FM. Hơn nữa, chúng tôi đã minh họa quá trình suy nghĩ của một nhà phát triển AI có tính sáng tạo và vòng đời phát triển của một ứng dụng AI có tính sáng tạo.

Trong tương lai, chúng tôi sẽ tập trung vào việc cung cấp các giải pháp cho từng lĩnh vực mà chúng tôi đã thảo luận và sẽ cung cấp thêm chi tiết về cách tích hợp giám sát FM (chẳng hạn như độc tính, sai lệch và ảo giác) và các mẫu kiến ​​trúc nguồn dữ liệu riêng tư hoặc bên thứ ba, chẳng hạn như Truy xuất thế hệ tăng cường (RAG), thành FMOps/LLMOps.

Để tìm hiểu thêm, hãy tham khảo Lộ trình nền tảng MLOps cho các doanh nghiệp với Amazon SageMaker và thử giải pháp toàn diện trong Triển khai các phương pháp MLOps với các mô hình được đào tạo trước Amazon SageMaker JumpStart.

Nếu bạn có bất kỳ ý kiến ​​hoặc câu hỏi nào, vui lòng để lại trong phần bình luận.

Về các tác giả

Tiến sĩ Sokratis Kartakis là Kiến trúc sư giải pháp chuyên gia vận hành và học máy cấp cao cho Dịch vụ web của Amazon. Sokratis tập trung vào việc hỗ trợ khách hàng doanh nghiệp công nghiệp hóa các giải pháp Machine Learning (ML) của họ bằng cách khai thác các dịch vụ AWS và định hình mô hình hoạt động của họ, tức là nền tảng MLOps và lộ trình chuyển đổi tận dụng các phương pháp phát triển tốt nhất. Ông đã dành hơn 15 năm để phát minh, thiết kế, dẫn dắt và triển khai các giải pháp ML và Internet of Things (IoT) cấp sản xuất cải tiến từ đầu đến cuối trong các lĩnh vực năng lượng, bán lẻ, y tế, tài chính/ngân hàng, đua xe thể thao, v.v. Sokratis thích dành thời gian rảnh rỗi cho gia đình và bạn bè hoặc đi xe máy.

Heiko Hotz là Kiến trúc sư giải pháp cao cấp về AI & Machine Learning, tập trung đặc biệt vào xử lý ngôn ngữ tự nhiên, mô hình ngôn ngữ lớn và AI tổng hợp. Trước vai trò này, ông là Giám đốc Khoa học Dữ liệu cho Dịch vụ Khách hàng EU của Amazon. Heiko giúp khách hàng của chúng tôi thành công trong hành trình AI/ML trên AWS và đã làm việc với các tổ chức trong nhiều ngành, bao gồm bảo hiểm, dịch vụ tài chính, truyền thông và giải trí, chăm sóc sức khỏe, tiện ích và sản xuất. Trong thời gian rảnh rỗi, Heiko đi du lịch nhiều nhất có thể.

tại chỗ_img

Tin tức mới nhất

tại chỗ_img

Bản quyền @ 2024 Plato Technologies Inc.