Nghiên cứu điển hình về fine-tuning Llama-2 để tùy biến mô hình theo nhu cầu

 (anyscale.com)
1 điểm bởi GN⁺ 2023-08-13 | 1 bình luận | Chia sẻ qua WhatsApp
  • Với các tác vụ chuyên biệt mà LLM đa dụng là quá mức cần thiết, có thể fine-tuning trực tiếp Llama-2 để đồng thời cải thiện chất lượng, chi phí và độ trễ bằng một mô hình nhỏ hơn, rẻ hơn
  • Sau khi fine-tuning, Llama-2 13B tăng độ chính xác biểu diễn hàm ViGGO từ 58%→98%, sinh SQL từ 42%→89%, và GSM8k từ 28%→47%
  • Ở các tác vụ mà định dạng đầu ra quan trọng như ViGGO và sinh SQL, các mô hình Llama-2 nhỏ cho kết quả tốt hơn GPT-4, nhưng trong suy luận toán học thì vẫn chưa đạt mức của GPT-4
  • Thí nghiệm được thực hiện bằng script dựa trên Ray Train, Ray Data, DeepSpeed và Accelerate; 7B·13B được huấn luyện trên 16xA10G, còn 70B trên 32xA10G
  • Yếu tố cốt lõi để cải thiện hiệu năng không phải kích thước mô hình mà là chất lượng dữ liệu và pipeline đánh giá; cần so sánh trade-off chi phí·chất lượng giữa prompt engineering và fine-tuning theo từng tác vụ

Hiệu quả của fine-tuning qua ba tác vụ

  • Các mô hình đa dụng lớn như GPT-4, Claude-2 hữu ích cho việc tạo prototype nhanh, nhưng với những nhu cầu phạm vi hẹp như tóm tắt hoặc phân loại ticket hỗ trợ, chúng có thể là quá mức cần thiết về cả chi phí lẫn hiệu năng
  • Thí nghiệm so sánh mức cải thiện khi fine-tuning toàn bộ tham số mô hình Llama-2 cho ba tác vụ gần với tình huống thực tế
    • ViGGO: trích xuất biểu diễn hàm từ văn bản phi cấu trúc
    • SQL-create-context: sinh SQL từ ngôn ngữ tự nhiên và ngữ cảnh CREATE TABLE
    • GSM8k: giải toán trình độ tiểu học
  • Mức thay đổi độ chính xác với Llama-2 13B như sau
    • Biểu diễn hàm ViGGO: 58% → 98%
    • Sinh SQL: 42% → 89%
    • GSM8k: 28% → 47%
  • Ở ViGGO và sinh SQL, các mô hình Llama-2 nhỏ cho kết quả tốt hơn GPT-4; còn với các tác vụ suy luận toán học như GSM8k, ngay cả sau fine-tuning vẫn không đạt được hiệu năng của GPT-4

Phương pháp fine-tuning và hạ tầng huấn luyện

  • Cả ba tác vụ đều dùng fine-tuning toàn bộ tham số theo chuẩn
    • Huấn luyện theo cách dự đoán token tiếp theo
    • Tất cả tham số của mô hình đều được cập nhật gradient
    • LoRA hay cách cố định một phần transformer block không nằm trong phạm vi thí nghiệm
  • Script thí nghiệm được xây dựng trên Ray Train, Ray Data, DeepSpeed, Accelerate
    • Hỗ trợ chạy Llama-2 7B, 13B, 70B
    • TorchTrainer của Ray Train phân tán vòng lặp huấn luyện qua nhiều worker process và tài nguyên GPU
    • Ray Train xử lý sharding dữ liệu, và mỗi worker truy cập phần dữ liệu được gán bằng session.get_dataset_shard("train"), session.get_dataset_shard("valid")
  • Sharding mô hình được xử lý bằng DeepSpeed ZeRO stage 3 cùng với optimizer state offloading
    • Do mô hình được chia thành nhiều mảnh trên các worker, khi cần truy cập toàn bộ mô hình như lúc lưu checkpoint thì phải unwrap bằng accelerator.unwrap_model(model)
  • Tài nguyên tính toán như sau
    • 7B·13B: 16xA10G
    • 70B: 32xA10G, 4 instance g5.48xlarge
    • Khi dùng Ray, fine-tuning toàn bộ tham số không nhất thiết phải cần A100
  • Huấn luyện được chạy tối đa 10 epoch, và chọn checkpoint có perplexity thấp nhất trên tập validation

Cố định cấu trúc input·output bằng token đặc biệt

  • Dữ liệu fine-tuning biểu diễn cấu trúc tác vụ bằng token đặc biệt thay vì prompt dạng chỉ thị
    • Ví dụ: <START_Q>{question}<END_Q><START_A>{answer}<END_A>
  • Token đặc biệt giúp mô hình phân biệt vùng input và output, đồng thời học rõ điểm dừng sinh đầu ra
    • Trong ví dụ, <END_A> được định nghĩa là stopping token để dừng sinh khi tác vụ hoàn tất
  • Mặc định tokenizer của Llama xuất ra 32.000 token ID
    • Nếu thêm bốn token đặc biệt thì sẽ xuất ra 32.004 ID
    • <START_Q> sẽ được gán ID mới như 32000, <END_Q> là 32001
  • Script thêm token đặc biệt bằng tokenizer.add_tokens(special_tokens, special_tokens=True) và tạo tham số huấn luyện mới bằng model.resize_token_embeddings(len(tokenizer))

ViGGO: chuyển văn bản phi cấu trúc thành biểu diễn hàm

  • ViGGO vốn là bộ dữ liệu tiếng Anh dùng để chuyển biểu diễn hàm dựa trên cặp thuộc tính-giá trị thành văn bản tự nhiên; trong thí nghiệm, hướng này được đảo ngược để biến văn bản phi cấu trúc thành biểu diễn hàm có cấu trúc
    • Miền dữ liệu là ý kiến về trò chơi điện tử
    • Biểu diễn kết quả có thể dùng cho indexing và các ứng dụng tiếp theo
  • Mô hình phải sinh ra hàm và giá trị thuộc tính phù hợp với câu đầu vào
    • Các hàm ứng viên gồm inform, request, give_opinion, confirm, verify_attribute, suggest, request_explanation, recommend, request_attribute
    • Các thuộc tính ứng viên gồm name, release_year, esrb, genres, platforms, available_on_steam, has_linux_release, has_mac_release, specifier, rating, player_perspective, has_multiplayer, developer, exp_release_date v.v.
  • Với input ví dụ What's a really fast-paced game with multiplayer that you like to play?, output kỳ vọng là request(has_multiplayer[yes], specifier[fast-paced])
  • Các mô hình đa dụng không tuân thủ tốt định dạng đầu ra mong muốn, và do ngữ cảnh đầu vào dài nên thời gian xử lý input còn lớn hơn thời gian sinh output
  • Tác vụ này thiên về nhận diện mẫu và hiểu ngôn ngữ cơ bản hơn là suy luận logic phức tạp
    • Đây là grounded task vì mọi dữ kiện cần thiết đều có trong input
    • Việc few-shot prompt có ích là tín hiệu cho thấy các mô hình Llama-2 nhỏ cũng có thể được cải thiện bằng fine-tuning

Đánh giá và kết quả của ViGGO

  • Việc đánh giá không chỉ dùng so khớp ký tự tuyệt đối
    • Kiểm tra xem hàm đầu ra có đúng không
    • Kiểm tra xem kiểu thuộc tính có đúng không
    • Kiểm tra xem các thuộc tính trong hàm có theo đúng thứ tự ưu tiên đã định hay không
  • Với các mô hình instruction-following như GPT hay Llama-2-chat, vì quy tắc thứ tự thuộc tính đã được nêu trong prompt nên chúng cũng bị đánh giá theo điều kiện phải tuân theo quy tắc đó
  • Để tăng tốc đánh giá, bài thử nghiệm dùng batch inference API của Ray cùng với Aviary của Anyscale
    • Kết nối quá trình sinh của LLM với hậu xử lý và phân tán lên nhiều máy
  • Sau fine-tuning, mô hình 7B và 13B cải thiện mạnh về độ chính xác
    • GPT-4 giảm mạnh độ chính xác khi phần đánh giá tính cả thứ tự ưu tiên thuộc tính
    • Các mô hình fine-tuned luôn tuân theo thứ tự ưu tiên, nên việc thêm ràng buộc này không làm thay đổi độ chính xác
  • Kết quả ViGGO cho thấy fine-tuning có thể là cách ổn định và hiệu quả cho các tác vụ đòi hỏi định dạng có cấu trúc
    • Đây không chỉ là việc khớp regex hay đúng định dạng JSON, mà còn phải quyết định đối số nào cần đưa vào và giữ đúng cả thứ tự của chúng
    • Vì kết quả đạt được với mô hình 7B·13B, chi phí serving có thể thấp hơn so với gọi endpoint GPT-4

Sinh SQL: tạo truy vấn từ ngôn ngữ tự nhiên và ngữ cảnh bảng

  • Tác vụ sinh SQL nhận đầu vào là truy vấn ngôn ngữ tự nhiên và câu lệnh SQL CREATE TABLE, rồi sinh ra câu truy vấn SQL có thể thực thi
  • Bộ dữ liệu b-mc2/sql-create-context là bộ dữ liệu Hugging Face kết hợp WikiSQL và Spider
    • Mỗi điểm dữ liệu gồm truy vấn ngôn ngữ tự nhiên, câu lệnh SQL CREATE TABLE, và truy vấn SQL tương ứng
    • Tổng cộng có 78.577 điểm dữ liệu
  • Bộ dữ liệu có vấn đề ở phần SQL đáp án
    • Trong CREATE TABLE, các thuộc tính số nguyên lại được ghi là VARCHAR, nhưng trong truy vấn SQL thường vẫn bị xử lý như số nguyên
    • Tất cả truy vấn SQL giả định thuộc tính là số nguyên đã bị loại bỏ, làm bộ dữ liệu giảm từ khoảng 70k xuống còn 45k
  • Tác vụ này cũng là bài toán chuyển ngôn ngữ tự nhiên sang biểu diễn có cấu trúc là SQL, nên phù hợp với fine-tuning
    • Khác với ViGGO, có thể tồn tại nhiều câu SQL khác nhau nhưng vẫn cho ra kết quả thực thi đúng, nên mơ hồ hơn

Đánh giá và kết quả của sinh SQL

  • Đánh giá sinh SQL không phù hợp với cách so khớp chuỗi đơn thuần
    • So khớp theo ký tự có thể tạo nhiều false negative
    • So sánh AST cũng có thể nhạy cảm với các yếu tố như thứ tự tên biến
    • Cách đáng tin cậy nhất là chạy code trên bộ dữ liệu giả và so sánh xem đầu ra có giống nhau không
  • Trong thí nghiệm, endpoint GPT-3.5 của OpenAI được dùng để tạo bảng giả phục vụ unit test cho hàng trăm ví dụ
    • GPT-3.5 xem câu hỏi, schema bảng và đáp án rồi tạo bảng giả gồm 10 điểm dữ liệu
    • Sau đó dùng sqlglot.executor.execute để chạy SQL đáp án và SQL do mô hình sinh ra rồi so sánh kết quả
  • Để kiểm tra chất lượng bảng dữ liệu do GPT-3.5 sinh ra, trước tiên người ta chạy SQL đáp án
    • Nếu bảng kết quả rỗng hoặc có cùng độ dài với bảng gốc thì loại bỏ ví dụ đó
    • Quá trình này lọc bỏ khoảng 50% số bảng dữ liệu do GPT tạo ra
  • Llama-2 7B và 13B sau fine-tuning cho hiệu năng cao hơn 70B-chat và GPT-4
    • Lỗi phổ biến của các mô hình Llama chat là không nhất quán đặt SQL vào trong thẻ <SQL> như prompt yêu cầu
    • Vấn đề này xuất hiện ở chat model 7B·13B nhiều hơn 70B
  • Một phần truy vấn ngôn ngữ tự nhiên trong bộ dữ liệu SQL không phải tiếng Anh hoàn hảo, và loại nhiễu này có thể đã ảnh hưởng đến kết quả của GPT-4
    • Các mô hình fine-tuned thích nghi nhanh với cả những thói quen kỳ lạ của bộ dữ liệu

GSM8k: suy luận toán học khó hơn học cấu trúc

  • GSM8k là benchmark học thuật tiêu chuẩn để đánh giá khả năng hiểu và suy luận toán học
  • Nếu hai tác vụ trước chủ yếu là học cấu trúc, thì GSM8k kiểm tra xem mô hình có thể cải thiện đến đâu về quá trình suy luận để giải toán
  • Một bài toán ví dụ hỏi tổng số lượng bán được khi tháng 4 bán 48 món và tháng 5 bán một nửa số đó; đáp án kết thúc theo dạng #### 72 cùng với các bước tính trung gian
  • LLM hiện nay thay vì chỉ tính nội bộ rồi đưa ngay đáp án cuối, thường cần sinh ra một phần quá trình suy nghĩ dưới dạng đầu ra để việc sinh token tiếp theo bám theo tiến trình logic
  • Tác vụ này không chỉ cần tính toán đơn giản mà còn cần chain of thought logic đi từ giả thiết qua kết luận trung gian đến đáp án cuối cùng

Cách đánh giá GSM8k và các baseline

  • Đánh giá cần một cách ổn định để trích xuất đáp án cuối từ đầu ra mô hình
  • Các mô hình ngôn ngữ thông thường có thể không tuân thủ nhất quán định dạng đầu ra mong muốn, khiến việc đánh giá tự động trở nên khó khăn
    • Vì vậy người ta dùng OpenAI function calling API
    • gpt-3.5-turbo-0613 được dùng để gọi hàm report_answer nhằm trích xuất đáp án số nguyên cuối cùng từ kết quả sinh của mô hình khác
    • Ví dụ, ngay cả khi mô hình trả lời “The answer is four” thì vẫn có thể parse thành 4
  • Cách này đã được kiểm chứng trên đáp án của bộ dữ liệu, nhưng có nhược điểm là phát sinh chi phí token của OpenAI cho việc đánh giá
  • Các mô hình fine-tuned học rất nhanh mẫu trả lời mục tiêu, nên ngay cả khi sai thì cấu trúc output vẫn dễ dự đoán
    • Việc đánh giá mô hình fine-tuned được xử lý bằng regex #### {answer} để tránh hậu xử lý qua endpoint OpenAI
  • Các baseline gồm
    • Kết quả 8-shot prompting của các mô hình base pre-trained được công bố trong bài báo
    • Nhiều mẫu prompt-engineered áp dụng cho các biến thể Llama-2 chat-tuned mà Meta đã huấn luyện bằng RLHF để trở thành assistant đa dụng

Kết quả GSM8k và fine-tuning hai giai đoạn

  • Fine-tuning mô hình base giúp tăng hiệu năng GSM8k một cách nhất quán, nhưng không phải lúc nào cũng tạo kết quả vượt trội rõ rệt so với chat-tuned model
    • Các chat model có thể đã được học từ ví dụ toán trong giai đoạn chat-tuning nên có độ chính xác cao hơn model base
  • Cách thêm prompt vào mô hình fine-tuned không phải lúc nào cũng cho kết quả tốt hơn model base
    • Ví dụ, Llama-2-70B-chat có thể thấp hơn model base được prompt với ví dụ 8-shot
    • Nhưng mô hình fine-tuned vẫn tốt hơn một cách nhất quán so với model base dùng prompt 8-shot
  • Xét về chi phí serving, mô hình fine-tuned có thể có lợi hơn
    • Cách dựa vào prompt phải trả chi phí token prompt ở mỗi request
    • Với mô hình fine-tuned, gần như chỉ số token của câu hỏi được tính vào chi phí
  • Dữ liệu huấn luyện GSM8k tương đối nhỏ, chỉ khoảng 8k mẫu, nên được cho là chưa đủ để khai thác hết tiềm năng của Llama-13B
  • Cách hai giai đoạn, fine-tuning Llama-13B base trước trên MathQA rồi fine-tuning lại trên GSM8k, mang lại cải thiện thêm
    • Fine-tuning chỉ với GSM8k giúp tăng 10 điểm phần trăm so với base
    • Fine-tuning hai giai đoạn với MathQA rồi GSM8k giúp tăng thêm 10 điểm phần trăm so với kết quả fine-tuning ban đầu, tức tổng cộng tăng 20 điểm phần trăm so với base
  • MathQA gồm 30.000 cặp câu hỏi/trả lời, nhưng nhiều nhiễu hơn và cấu trúc khác với GSM8k
    • Chất lượng câu trả lời thấp hơn, và đáp án cuối ở dạng multiple choice
    • Dù vậy, fine-tuning hai giai đoạn vẫn hiệu quả trong việc tận dụng MathQA để cải thiện kết quả cuối trên GSM8k

Tiêu chí cần nhìn trong ứng dụng thực tế

  • Các mô hình đóng như GPT-4, Claude-2 mạnh trong giai đoạn tạo prototype và kiểm chứng giá trị ban đầu, nhưng không phải lúc nào cũng đủ cho việc vận hành ứng dụng LLM trong production
  • Fine-tuning LLM cho các niche task có thể mang lại giá trị không chỉ về quyền riêng tư mà còn ở độ trễ, chi phí và chất lượng
    • Ở các ví dụ ViGGO và SQL, chất lượng thậm chí còn tốt hơn GPT-4
  • Trọng tâm quan trọng trong fine-tuning không nằm ở chi tiết triển khai hạ tầng mà ở việc thu thập dữ liệu và xây dựng pipeline đánh giá
    • Pipeline đánh giá là nền tảng để so sánh trade-off giữa nhiều cách giải khác nhau theo yêu cầu kinh doanh
  • Thí nghiệm được thực hiện bằng nền tảng fine-tuning và serving của Anyscale cùng với Anyscale Endpoints
  • Cùng quy trình này có thể lặp lại trên dữ liệu và cloud riêng bằng giải pháp fine-tuning và serving của Anyscale trên nền Ray

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-08-13
Ý kiến trên Hacker News

  • Vài tuần trước, trong một buổi livestream lập trình, tôi đã nói khá nhiều về việc fine-tune Llama 2 bằng dataset của riêng mình, và làm trên một GPU duy nhất của Colab.
    Trong trường hợp của tôi, dataset là mã nguồn của tôi.
    Fine-tuning Llama stream: https://www.youtube.com/watch?v=TYgtG2Th6fI&t=2282s
    Tôi cũng có thêm vài session fine-tune QLoRA, giải thích các khái niệm từ góc nhìn của một kỹ sư phần mềm 8 năm kinh nghiệm mới chuyển sang machine learning gần đây và tự học.
    QloRa fine-tuning stream: https://www.youtube.com/watch?v=LitybCiLhSc&t=4584s
    Tôi đang cố gắng diễn giải thật dễ hiểu cách mình tiếp cận trong các dự án cá nhân và trong startup dựa trên AI hiện đang làm. Series fine-tune LLM nhỏ nhất cho phát triển web cũng có vẻ được đón nhận khá tốt; tôi mới stream khoảng một tháng và dự định sẽ đăng nhiều hơn nữa.

    • Tôi tò mò về tiêu chí chung để quyết định khi nào nên dùng RAG và fine-tuning.
      Tôi cũng chưa hiểu rõ cách chia nhỏ các mô hình đã fine-tune. Liệu có cần riêng một Terraform LLM, SQL LLM, Python LLM, hay chỉ cần một LLM “code” là đủ?
    • Thực sự cần một ứng dụng/module/thư viện đơn giản ở mức “đặt tài liệu nguồn vào thư mục này, bấm nút, rồi chat với nội dung đó”.
      Hiện cần quá nhiều chi tiết triển khai nên khó tiếp cận, trừ khi đó là một use case thật sự đáng công. Có vẻ privateGPT đang từ từ tiến tới điểm đó.
    • Rất hay; mong có thêm một series về chuẩn bị dataset tùy chỉnh để fine-tune.
      Đây là phần mà nhiều tutorial khác thường lướt qua. Đặc biệt tôi muốn biết cách chuẩn bị khác nhau tùy theo các mục tiêu như độ an toàn, độ chính xác.
    • Có thể làm bằng một GPU không? Tôi thắc mắc liệu một chiếc 3060 có thực tế không.

  • Tôi cũng gặp vấn đề tương tự với Llama 2. Gần như không thể khiến nó chỉ xuất đúng đoạn văn bản mong muốn; nó luôn thêm thứ gì đó vào trước hoặc sau câu trả lời.
    Không biết có kỹ thuật prompt nào để sửa vấn đề này không?

    • Nên dùng một mô hình tốt hơn.
      airoboros hỗ trợ token PLAINFORMAT để tránh backtick, phần giải thích, v.v. và chỉ xuất mã.
      https://huggingface.co/TheBloke/airoboros-l2-70B-GPT4-2.0-GG...
    • Các mô hình Llama-2-chat đã bị fine-tune quá mức theo kiểu này. Có thể thử few-shot prompting, nhưng không thể đảm bảo đầu ra như ý.
      Nếu muốn đảm bảo, tốt nhất là fine-tune với một dataset nhỏ, khoảng 1.000 mẫu, rồi cải thiện dần từ đó.
    • Tùy mục tiêu, nhưng tôi đã thành công trong việc tái tạo một định dạng đầu ra cụ thể bằng cách fine-tune mô hình LLaMA2 nền tảng thay vì mô hình đã RLHF.
      Use case của tôi là một tác vụ đơn giản về trích xuất/tổng hợp thông tin từ văn bản, hơn là viết sáng tạo. Mô hình nền tảng có thể không phù hợp với mọi tác vụ.
    • Chỉ cần prompt để mô hình luôn xuất câu trả lời hoặc mã bên trong chuỗi content hoặc JSON.
      Nếu là JSON thì có thể nhận diện phần bắt đầu và kết thúc, rồi loại bỏ nội dung nằm ngoài JSON.

  • Thật vui khi thấy bài viết như thế này xuất hiện. Trên mạng đã có quá nhiều thảo luận về tùy biến mô hình, và bài này loại bỏ được khá nhiều nhiễu.
    Tôi cũng thích phương pháp đánh giá, và bài viết có vẻ được viết tốt.

  • Thật lạ là LoRA và huấn luyện lượng tử hóa không được xem xét nghiêm túc hơn. Chúng rẻ hơn nhiều, tốn ít thời gian hơn, và cũng có nhiều bằng chứng cho thấy kết quả khá tốt.
    Tôi không nghĩ nên đẩy chúng sang một lựa chọn phụ để thử sau.

  • Rất vui khi thấy tác vụ tương tự NER cho hiệu năng tốt nhất. Tôi vừa định làm một bài test tương tự để so sánh với mô hình BERT đã fine-tune.
    Tôi tò mò chi phí huấn luyện cho tác vụ này là bao nhiêu.

    • Tôi là đồng tác giả của bài viết. Dữ liệu huấn luyện ViGGO có khoảng 5,1 nghìn dòng, và chúng tôi huấn luyện với block size 512.
      Có thể giảm block size, nhưng để nguyên code thì dễ hơn nên chúng tôi giữ vậy. 7B mất khoảng 15 phút mỗi epoch trên 16xA10G, còn 13B mất khoảng 25 phút. Vì vậy, chi phí on-demand mỗi epoch là khoảng $7.2 cho 7B và khoảng $12 cho 13B. Con số này chỉ tính thời gian dùng để huấn luyện, không bao gồm thời gian khởi động/tắt cluster.
    • Câu hỏi hay. Tiếc là nếu bài viết ghi 10 epoch mất bao lâu thì đã có thể tính chi phí. Tốt hơn nữa là đăng kèm cả thời gian và chi phí.
      Bài viết nói rằng họ dùng 16xA10G cho 7B và 13B, còn 70B dùng 32xA10G, chia trên 4 instance g5.48xlarge. Với Ray, không cần phải có A100 để fine-tune toàn bộ tham số của các mô hình này, và họ lặp lại cùng quy trình cho từng tác vụ. Với dataset GSM8k, bài viết đưa ra một lần chạy mẫu với độ dài ngữ cảnh 512 và 3,7 triệu token hiệu dụng mỗi epoch.
      Họ nói đã huấn luyện tối đa 10 epoch và chọn checkpoint có perplexity thấp nhất trên tập validation.

  • Một khó khăn là để tạo một custom dataset đủ lớn thì cần một đội nhỏ như một tiểu đoàn, hoặc một mô hình hiện có rất mạnh.
    Cuối cùng nhiều khả năng vẫn phải dùng OpenAI, nhưng dùng OpenAI để tạo dữ liệu huấn luyện cho mô hình khác là vi phạm điều khoản. Tôi tự hỏi đã có vụ kiện nào về chuyện này chưa. Hay mọi người chỉ coi là bất công rồi phớt lờ?

    • Không phải tác vụ nào cũng vậy. Với nhiều tác vụ xử lý ngôn ngữ tự nhiên, chỉ cần định dạng lại dữ liệu hiện có cho phù hợp với định dạng LLM.
    • Có lý do gì để không phớt lờ điều khoản không? Trường hợp xấu nhất chỉ là mất quyền truy cập.

  • Gần đây tôi thấy ví dụ NER xuất hiện thường xuyên hơn, và tự hỏi tại sao những tác vụ như vậy lại không dùng spaCy.

    • spaCy không hoạt động tốt với dữ liệu huấn luyện đa ngôn ngữ, và tôi cũng đã thấy nó lỗi theo nhiều cách hơn và kỳ lạ hơn so với họ transformers.
    • Tôi đang nghĩ theo hướng dùng mô hình đắt tiền để gán nhãn dữ liệu, rồi huấn luyện một mô hình nhỏ hơn như SpaCy hoặc BERT theo cách giáo viên/học sinh để tối ưu chi phí và tốc độ.
    • Tôi đang dùng các mô hình họ BERT đã fine-tune cho NER, nhưng cũng muốn so sánh hiệu năng.

  • Tôi làm việc tại Anyscale.
    Có vẻ blog này nhận được sự quan tâm tốt, nên chúng tôi định đưa vào Ray Summit: https://raysummit.anyscale.com/agenda
    Nếu có ý tưởng về loại nội dung nào bạn muốn thấy thêm tại Ray Summit, rất mong được nghe.

  • Bài viết nói rằng với 3,5 triệu token, 7B mất khoảng 14 phút cho 1 epoch, còn 13B mất khoảng 26 phút cho 1 epoch.
    Cả 7B và 13B đều cần tối thiểu 1xg5.16xlarge làm head node và 15xg5.4xlarge làm worker node; tôi tò mò chi phí trên AWS là bao nhiêu.

  • Tôi tò mò liệu có thể fine-tune Llama-2 cục bộ trên M1 Ultra 64GB không. Hầu hết tài liệu tham khảo đều là cloud hoặc dùng Nvidia CUDA trên Linux, nên nếu có nguồn nào đáng tham khảo thì rất tốt.

    • Có lẽ là không. Tôi dùng M1 Max 64GB và một số tác vụ inference chạy khá ổn.
      Còn huấn luyện thì tôi định mua ít credit RunPod để làm; có vẻ chỉ vài chục đô là được.