Reddit Vietnam

AI

Tôi nhận thấy chất lượng thảo luận về học máy và các sản phẩm liên quan đã giảm đáng kể từ khi API của mô hình ngôn ngữ lớn (LLM) trở nên phổ biến.

/MachineLearning, API, LLM

r/MachineLearning – Sep 20, 2024

u/Seankala (Kỹ sư học máy – MLE) (408 upvoted)

Tôi đã làm việc như một MLE trong vài năm sau khi hoàn thành thạc sĩ và hiện tại đang làm việc tại một công ty với những đồng nghiệp rất thông minh. Vấn đề là, công ty tôi không có đủ nguồn lực để tự huấn luyện mô hình LLM, nên phải sử dụng các API khác nhau cho các mô hình. Các cuộc thảo luận về cách cải tiến sản phẩm của chúng tôi thường cảm thấy không hiệu quả và vô nghĩa. Thường thì chúng tôi chỉ nói về cách khiến LLM (mà chúng tôi không kiểm soát được) làm việc theo yêu cầu thông qua “prompt engineering.”

Cá nhân tôi không nghĩ rằng “prompt engineering” là một phương pháp đáng tin cậy hoặc thực sự, và tôi cảm thấy rằng khi các cuộc thảo luận thường rơi vào điều đó, chúng tôi không thể thực sự cải thiện sản phẩm của mình. Không biết có ai cũng cảm thấy giống tôi không?


u/ResidentPositive4122
Vấn đề là công ty tôi không có nguồn lực để huấn luyện mô hình LLM của riêng mình.
Tại sao bạn lại cần huấn luyện trước một LLM trong khi các kỹ thuật khác hoạt động tốt với các tác vụ hạ lưu với ngân sách hợp lý hơn nhiều?
Huấn luyện tinh chỉnh (fine-tuning) hiệu quả, với điều kiện bạn có dữ liệu tốt và một nhiệm vụ rõ ràng. Hơn nữa, chi phí của việc tinh chỉnh bây giờ thấp đến mức ngay cả những người đam mê cũng có thể thực hiện. Ví dụ, Alpaca đã làm điều đó với mô hình LLama đầu tiên chỉ với khoảng 300$, và ngày nay bạn có thể tái tạo kết quả với chỉ khoảng 20$.

Đó là cho LLM. Nếu bạn chỉ cần SLM, chi phí cho các mô hình nhỏ hơn cũng hợp lý ngay cả đối với các startup nhỏ. Gần đây có một nhóm đã huấn luyện một mô hình tầm cỡ Phi1 với ngân sách 3-6k$, và đó cũng là một con số hợp lý.


u/HattRyan
Cảm thấy giống như vậy. Bạn nhận xét đúng. Tôi thực sự nghĩ rằng việc tự huấn luyện các mô hình của riêng mình là vô nghĩa, thời kỳ cho điều đó đã qua từ khi Stanford tạo ra cơn sốt với BERT. Hãy chọn một mô hình nổi bật dựa trên nhu cầu của bạn và áp dụng học chuyển giao. Prompt engineering rất quan trọng khi tạo các tập dữ liệu hoặc tinh chỉnh các phản hồi. Tôi tò mò xem bạn có cảm thấy như vậy không.

u/and_sama
Bạn có thể cung cấp tài liệu về cách học tinh chỉnh (fine tunning) không?

u/ResidentPositive4122
r/locallama là nơi tốt để bắt đầu.
Dưới đây là danh sách các thư viện tôi đã lưu lại để tinh chỉnh, đọc tài liệu hoặc ví dụ của chúng có thể sẽ hữu ích.

  • Peft – Các phương pháp tinh chỉnh hiệu quả (PEFT) hiện đại nhất. PEFT tích hợp với Transformers để dễ dàng huấn luyện và suy luận mô hình, Diffusers để quản lý tiện lợi các bộ chuyển đổi, và Accelerate cho huấn luyện phân tán và suy luận các mô hình lớn.
  • LLama-Factory – Tinh chỉnh hơn 100 LLM hiệu quả trong WebUI (ACL 2024).
  • Axolotl – Công cụ tinh chỉnh hỗ trợ nhiều cấu hình và kiến trúc AI.
  • Unsloth – Tinh chỉnh Llama 3.1, Mistral, Phi & Gemma LLM nhanh hơn 2-5 lần với 80% ít bộ nhớ hơn.

u/Amgadoz
Các API của LLM đã biến ML thành hàng hóa. Cách đây vài năm, nếu bạn muốn làm phân loại ý định cho văn bản, cần phải có nhiều công việc không nhỏ từ việc chọn backbone đến tinh chỉnh một đầu phân loại đa lớp và giám sát quá trình huấn luyện đến khi triển khai. Điều này yêu cầu người có nền tảng về ML biết cách thêm đầu phân loại. Nhưng ngày nay, bạn có thể chỉ cần prompt engineer một LLM và đạt kết quả rất tốt chỉ sau 30 phút làm việc.

Và nó có thể mở rộng đến hàng triệu người dùng mà không cần thêm công việc nào từ nhà phát triển (giả sử bạn không gặp giới hạn tốc độ yêu cầu).

Là các kỹ sư học máy (ML Engineers), chúng ta cần phải chấp nhận thực tế này. Dù vậy, vẫn còn nhiều việc để chúng ta làm. Thứ nhất, nhiệm vụ phân loại ý định này có thể được thực hiện với chi phí thấp hơn nhiều bằng một mô hình nhỏ hơn như daberta; những khoản tiết kiệm sẽ không hợp lý trừ khi bạn phải xử lý hàng trăm hoặc hàng ngàn yêu cầu đồng thời. Thứ hai, bộ phân loại của chúng ta cần được đánh giá để hiểu điểm mạnh, điểm yếu và cách cải thiện độ chính xác của nó. Đánh giá (evaluation) nói dễ hơn làm và có nhiều sắc thái. Khi đã xác định được điểm yếu, chúng ta có thể bắt đầu vòng quay dữ liệu (data flywheel) và tiếp tục từ đó.

Đây chỉ là cái nhìn tổng quan về vai trò của kỹ sư học máy trong kỷ nguyên của các API LLM. Lưu ý rằng những điểm này chỉ hợp lý khi tổ chức đủ trưởng thành và có đủ nhu cầu cho các ứng dụng của nó. Trước đó, không cần thiết phải có một kỹ sư học máy.

u/Familiar_Text_6913

Tôi nghĩ đó là hiệu ứng của việc “thương mại hóa quy mô lớn” trong học máy. Vâng, nó đã được sử dụng, nhưng giờ đây nó mới thực sự được áp dụng đúng nghĩa. API thống trị vì chúng dễ dàng? Không cần thiết lập gì nhiều, chỉ cần gọi vài API để truy cập học máy… Các nền tảng thương mại hóa khác sẽ trỗi dậy, nhưng tại thời điểm này, việc sử dụng API so với việc thiết lập toàn bộ quy trình chỉ là lựa chọn hiển nhiên. Tôi không làm việc trong MLops nên có thể tôi sai, chỉ là suy nghĩ của tôi thôi.

u/jojoabing

API dễ sử dụng hơn, nhưng không phải lúc nào cũng phù hợp với mọi ứng dụng. Các ứng dụng RAG với dữ liệu nhạy cảm của công ty thường yêu cầu các mô hình được lưu trữ cục bộ để đảm bảo tuân thủ.

u/unplannedmaintenance

Bạn phải chọn hoặc làm việc ở nơi mà bạn có cơ hội làm những công việc chuyên sâu hơn (ở nơi có nhu cầu về độ chính xác cao hơn…), hoặc là thích nghi với thời đại mà bạn đang sống. Nghe có thể khó chịu, nhưng các LLM này đạt hiệu suất “đủ tốt” cho nhiều công ty, nhất là với mức giá và lợi ích tiếp thị (“Chúng tôi sử dụng AI”) mà chúng mang lại.

Nói cách khác, các LLM này mang lại nhiều giá trị (dù là thực tế hay chỉ là cảm nhận) hơn so với kỹ sư học máy cho nhiều công ty. Thật dễ hiểu khi các MLE cảm thấy thất vọng về điều này. Giống như những thợ xây có thể buồn bã vì giờ đây có máy móc xây gạch trên đường phố. Họ phải học cách vận hành những cỗ máy đó hoặc chuyên môn hóa vào một lĩnh vực mà máy móc không thể làm được.

u/met0xff

Các tầng trừu tượng cứ chất đống như chúng luôn làm. Cách đây không lâu tôi còn loay hoay với sự kết hợp giữa C, Matlab, Perl với mã ML và xử lý tín hiệu cùng rất nhiều mã kỹ thuật tính năng. Sau đó, với deep learning, việc kỹ thuật tính năng trở nên đơn giản hơn, mô hình lớn hơn (nhưng không nhất thiết phức tạp hơn).

Khi đó, tôi còn phải tự triển khai LSTM, nhưng sớm thôi mọi thứ đều là Python và Theano, TensorFlow, PyTorch, và đến một lúc nào đó, bạn chỉ cần ghép các tầng tuyến tính, hồi quy, hoặc tích chập lại với nhau. Rồi sau đó, xuất hiện các thư viện như Hugging Face Transformers, và bạn bắt đầu ghép những khối còn lớn hơn như các mô hình BERT, BEATS hoặc CLIP đã được huấn luyện trước (dù có rất nhiều mô hình VAEs, GANs, Flow và diffusion xen kẽ).

Hiện tại, dường như mọi lĩnh vực đều cố gắng mã hóa tất cả mọi thứ và đưa nó vào transformer. Và rồi những mô hình đó trở nên khổng lồ, và bạn không còn làm việc với chiếc RTX3090 nhỏ bé ở nhà nữa, mà thay vào đó bạn làm việc với các embedding và sử dụng những “phương pháp” lạ lùng để vượt qua các hạn chế của LLM.

Tất nhiên, vẫn có những người làm việc toàn bộ trên stack, nhưng phần lớn mọi người chỉ làm việc trên tầng trừu tượng cao nhất. Điều này không nhất thiết là điều xấu, vì sau khi đã huấn luyện hàng ngàn mô hình nhỏ, nó cũng trở nên khá phiền phức. Và miễn là khả thi, việc bảo một mô hình đa phương thức thực hiện tất cả những công việc mà trước đây bạn cần 6 dự án nghiên cứu riêng biệt để làm… tại sao không? Cũng như với Sonnet 3.5 và GPT-4o, khả năng gọi công cụ đã trở nên đáng tin cậy đáng kinh ngạc. Và “prompt engineering” cũng đã trở thành điều ít quan trọng hơn nhiều.

Chắc chắn là, tôi cũng có những lúc ước mình quay lại những năm 2000, ngồi viết mã C cả ngày mà không cần đến thư viện, framework, hay khái niệm mới nào cả, chỉ có bạn, trình biên dịch của bạn và tài liệu kỹ thuật. Nhưng thật lòng mà nói, đến một lúc nào đó nó cũng trở nên nhàm chán. 😉

u/Amazing_Life_221

Hoàn toàn đồng ý!!

Xin lỗi vì bài viết mang tính phàn nàn này:

Hồi còn học đại học: “Này, mô hình của tôi không cho kết quả tốt, đọc lý thuyết, đọc sách, đọc bài báo, debug code…” và trong quá trình đó, tôi học được rất nhiều thứ và quan trọng hơn là học cách tôn trọng lĩnh vực “học máy.”

Ngày nay: “Tôi muốn xây dựng một ứng dụng, này gọi API này, mô hình không hiệu quả à? Áp dụng các kỹ thuật này, vẫn không hiệu quả? Thay API khác!… ‘học máy’ chỉ là gọi API, một công ty trị giá nghìn tỷ đô sẽ lo chuyện huấn luyện và xây dựng mô hình!”

u/Milesware

Tôi muốn nói rằng đây cũng là lời phàn nàn tương tự như những người nhìn xuống những người sử dụng Unity/Unreal và tự hào khoe khoang về việc họ đã tạo ra các trò chơi thực sự từ ngày xưa với 10 MB RAM và hai sprite trên một cái máy tính “cùi bắp”.

u/FinancialElephant

So sánh như vậy là không đúng, vì bạn cần hiểu về đồ họa máy tính, phát hiện va chạm, vật lý, v.v. để tận dụng một engine trò chơi có sẵn. Bạn không cần phải biết cách các LLM hoạt động để sử dụng chúng.

u/photosandphotons

Thật sao? Tôi nghĩ bạn có thể bắt đầu sử dụng LLM mà không cần hiểu bất cứ điều gì, và bạn cũng không cần đi quá sâu ngay cả với những trường hợp sử dụng phức tạp hơn. Tuy nhiên, để tận dụng hiệu quả hơn, hiểu cấu trúc kiến trúc của mô hình và các chiến lược phổ biến gần như là điều cần thiết, đặc biệt là các chiến lược liên quan như RAG, điều mà bạn thực sự cần hiểu để sử dụng đúng cách.

Khi thực hiện các nhiệm vụ như điều phối quy trình làm việc với nhiều agent, hoặc tạo mã động khi đang thực thi – tôi thấy “prompt engineering” thực sự là một thứ có liên quan đến hiểu biết của tôi về cách các mô hình được huấn luyện và tinh chỉnh, và điều này đòi hỏi sự hiểu biết về nhiều khái niệm như tokenization (ví dụ, tôi có những chiến lược khác nhau khi sử dụng Gemini 1.5 với ngữ cảnh lớn hơn và độ nhất quán cao hơn, so với Claude 3.5 với khả năng tập trung tốt hơn và dễ dàng để tạo prompt hơn).

u/secretwoif

Cuối cùng thì mục tiêu của lĩnh vực chúng ta là có thể giải quyết mọi vấn đề chỉ bằng một lệnh API đơn giản. Một thuật toán có thể khái quát hóa đủ tốt để ‘giải quyết’ mọi vấn đề. Nó sẽ giống như cách xây dựng website bây giờ. Vào những năm 90, cần cả một đội ngũ phát triển để thiết lập một trang web nhỏ (theo tiêu chuẩn hiện tại). Bây giờ bất kỳ ai cũng có thể làm được. Vấn đề là vẫn còn những quyết định cần được đưa ra khi xây dựng website.

Không có gì là phi lý khi nghĩ rằng trong tương lai, bạn chỉ cần mô tả vấn đề của mình và công cụ xây dựng ML sẽ nói: đây là giải pháp đủ tốt cho vấn đề của bạn. Không cần chuyên môn, thậm chí không cần phải nói “Tôi thích giao diện của mẫu này,” chỉ cần có văn bản và hình ảnh.

Luôn có chút mỉa mai rằng với tư cách là những người làm việc trong ngành học máy, chúng ta là những người có nguy cơ cao nhất bị mất đi sự quan trọng do sự tiến bộ của chính lĩnh vực này. Nói cách khác, với tư cách là con người, chúng ta tạo ra công cụ và chế tạo ra các công cụ để khiến công việc của chúng ta trở nên dễ dàng hơn. Và học máy là lĩnh vực tạo ra công cụ có thể tự động hóa hoàn toàn công việc của người làm công cụ.

Vì vậy, hãy quen với những câu hỏi như “API nào là tốt nhất” vì với những tiến bộ trong lĩnh vực này, chúng ta sẽ chỉ thấy nhiều câu hỏi như vậy hơn thôi, tôi đoán vậy.

Bài gốc: https://www.reddit.com/r/MachineLearning/comments/1fl5be0/d_i_feel_like_ever_since_llm_apis_have_become_a/

Leave a Comment