Chủ đề thịnh hành
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
Được rồi, hãy nói về các framework, thư viện, RL, và tại sao tôi có lẽ không thích codebase RL yêu thích của bạn. Đúng, bao gồm cả cái đó.
Điều không bình thường về RL là thuật toán là phần dễ dàng. GRPO là một phương trình một dòng trên một số logprobs. Nếu bạn có dữ liệu, việc tính toán tổn thất là điều đơn giản, và sau đó có lẽ bạn đang sử dụng nó với một thư viện backprop mà bạn chọn.
Nhưng đó là vấn đề - có được dữ liệu. Thật là một cơn ác mộng. Trong RL thông thường, bạn phải thực hiện các rollouts, có thể cắt ngắn một số tập, và xử lý các kết thúc cho phù hợp. Nếu bạn không muốn trở thành một con ốc sên, bạn sẽ muốn vector hóa môi trường và điều chỉnh thuật toán cho điều đó. Nếu bạn muốn làm một LLM, bạn cần phải làm tất cả những điều vô lý khiến LLM vừa vặn trong bộ nhớ. Bạn cần phải cẩn thận về các prompt của mình, che đi những phần đúng cho tổn thất. Bạn cần một động cơ sinh ra hợp lý (vLLM), điều này khiến việc cập nhật trọng số trở nên khó khăn. Nếu bạn muốn làm RL LLM đa tác nhân đa lượt, có lẽ bạn nên chơi sudoku cam kết.
Trong khi chúng ta có nhiều bất đồng về hầu hết mọi thứ liên quan đến RL, tôi nghĩ Pufferlib của @jsuarez5341 thể hiện điểm này một cách tuyệt vời. Nó không nghi ngờ gì là tuyệt vời trong những gì nó làm - đào tạo các thuật toán RL trên các môi trường mô phỏng rất rất nhanh.
Nhưng hầu hết sự mới mẻ của nó là hạ tầng thuần túy. Các thuật toán cốt lõi phần lớn vẫn giống như chúng đã có trong nhiều năm, và tôi sẵn sàng cá rằng chúng đại diện cho ít hơn 10% nỗ lực kỹ thuật tổng thể.
Tự nhiên, điều này có những tác động đến mã mà bạn cần viết để làm bất cứ điều gì ngoài việc chạy các ví dụ tích hợp sẵn. Điều tôi thấy lặp đi lặp lại là đối với nhiều vấn đề nghiên cứu đủ không tầm thường (đọc: thú vị), mất một khoảng thời gian tương tự để (a) viết thứ đó từ đầu/từ các nguyên tắc đơn giản, hoặc (b) điều chỉnh một framework hiện có để phù hợp với những ý tưởng điên rồ.
Trong trường hợp trước, bạn tập trung vào việc viết logic thực tế. Trong trường hợp sau, bạn phải vật lộn với framework để cho phép bạn thêm logic. Tôi biết tôi thích cái nào hơn.
Tất cả những điều này là vì thuật toán là phần dễ dàng.
Hạ tầng là cơn ác mộng. Vì vậy, bất cứ khi nào bạn ở trong vị trí để chọn - hãy sử dụng các công cụ đơn giản hóa hạ tầng, và tự viết vòng lặp đào tạo. Đừng xây dựng các framework, hãy xây dựng các thư viện. Bạn sẽ cảm ơn bản thân sau này.
Một lời cảm ơn lớn đến người hướng dẫn Thạc sĩ của tôi từ ngày xưa, người đã là người đầu tiên nói với tôi hãy bỏ rllib và chỉ cần viết PPO cho chính mình trong PyTorch. Và đến @hallerite vì đã truyền cảm hứng cho tôi để cuối cùng viết lên bài rant này. Tôi có thể viết một bài effortpost đúng nghĩa với các ví dụ vào một thời điểm nào đó trong tương lai nếu mọi người yêu cầu.
Hàng đầu
Thứ hạng
Yêu thích

