ჩვენი მიზანია: ეს ნაშრომი განკუთვნილია მხოლოდ საგანმანათლებლო/სასწავლო მიზნებისთვის. მოწინავე მომხმარებლებისთვის, რომლებსაც ესაჭიროებათ მეტი ფუნქცია, მაგალითად, უფრო დიდი მოდელების გაშვება PEFT-ით, huggingface/trl შესანიშნავი არჩევანი იქნება. აქ მოცემულია მნიშვნელოვანი ბმულები: ჩვენი მთავარი წვლილია OpenAI-ის (OAI) შედეგების რეპროდუცირება სტილისტურ ამოცანებში, როგორიცაა სენტიმენტი და აღწერილობითობა. როგორც ქვემოთ მოცემულ ფიგურაზეა ნაჩვენები, ჩვენს კოდების ბაზას (ნარინჯისფერი მრუდები) შეუძლია თითქმის იდენტური სწავლის მრუდების წარმოება, როგორიც OAI-ის კოდების ბაზას (ლურჯი მრუდები). პირდაპირი შედარებისთვის, ჩვენ გავუშვით ორიგინალური RLHF კოდი openai/lm-human-preferences-ზე, რაც მოგვცემს ღირებულ მეტრიკას ჩვენი რეპროდუქციის ვალიდურობის შესამოწმებლად და დიაგნოსტიკისთვის. ჩვენ შევძელით ორიგინალური TensorFlow 1.x კოდის დაყენება, მაგრამ ის მოითხოვს ჰიპერ-სპეციფიკურ კონფიგურაციას: ახლა ჩვენ გადავდივართ ტექნიკურ სიღრმისეულ ანალიზზე იმპლემენტაციის დეტალებზე, რომლებიც აქტუალურია OAI-ის ნაშრომის რეპროდუცირებისთვის. ამ განყოფილებაში განვიხილავთ ძირითად დეტალებს, მაგალითად, როგორ გენერირდება ჯილდოები/მნიშვნელობები და როგორ გენერირდება პასუხები. ეს დეტალები მოცემულია შემთხვევითი თანმიმდევრობით: ჯილდოს მოდელი და პოლიტიკის ღირებულების თავი იღებენ შეყვანას, როგორც მოთხოვნის (query) და პასუხის (response) კონკატენაციას. შევსება ხდება სპეციალური შევსების ტოკენით (padding token) და შეყვანები იკვეცება. OAI აყენებს ფიქსირებულ შეყვანის სიგრძეს მოთხოვნისთვის `query_length`; ის ავსებს (pads) ძალიან მოკლე თანმიმდევრობებს `pad_token`-ით (lm_human_preferences/language/datasets.py#L66-L67) და კვეცავს (truncates) ძალიან გრძელ თანმიმდევრობებს (lm_human_preferences/language/datasets.py#L57). (კონცეფციის ზოგადი მიმოხილვისთვის იხილეთ აქ). შეყვანების შევსებისას (padding) OAI იყენებს ტოკენს, რომელიც ლექსიკონის მიღმაა (lm_human_preferences/language/encodings.py#L56). გაითვალისწინეთ, რომ შევსების ტოკენის არარსებობა დეკოდერის მოდელებისთვის ნაგულისხმევი პარამეტრია, რადგან ისინი წინასწარი ვარჯიშის დროს ვარჯიშობენ „შეფუთვით“ (packing), რაც ნიშნავს, რომ მრავალი თანმიმდევრობა კონკატენირებულია და გამოყოფილია EOS ტოკენით, ხოლო ამ თანმიმდევრობის ნაწილები, რომლებსაც ყოველთვის აქვთ მაქსიმალური სიგრძე, მიეწოდება მოდელს წინასწარი ვარჯიშის დროს. ყველაფრის გაერთიანებისას, აქ მოცემულია მაგალითი: შევსების ტოკენებისთვის შესაბამისად დაარეგულირეთ პოზიციის ინდექსები. ლოგიტების გამოთვლისას, OAI-ის კოდი მუშაობს შევსების ტოკენების სწორად დაფარვით (masking out). ეს მიიღწევა შევსების ტოკენების შესაბამისი ტოკენის ინდექსების მოძიებით (lm_human_preferences/language/model.py#L296-L297), რასაც მოჰყვება მათი პოზიციის ინდექსების შესაბამისი კორექტირება (lm_human_preferences/language/model.py#L320). მაგალითად, თუ `query=[23073, 50259, 50259]` და `response=[11, 339, 561]`, სადაც `50259` არის OAI-ის შევსების ტოკენი, მაშინ ის ქმნის პოზიციის ინდექსებს, როგორც `[[0 1 1 1 2 3]]` და ლოგიტებს შემდეგნაირად. გაითვალისწინეთ, თუ როგორ რჩება შევსების ტოკენების შესაბამისი ლოგიტები უცვლელი! ეს არის ეფექტი, რისკენაც უნდა ვისწრაფოდეთ ჩვენს რეპროდუქციაში. შენიშვნა HF-ის ტრანსფორმატორების შესახებ — `position_ids` და `padding_side`. ჩვენ შეგვიძლია ზუსტი ლოგიტების რეპლიკაცია Hugging Face-ის ტრანსფორმატორის გამოყენებით: 1) მარცხენა შევსებით (left padding) და 2) შესაბამისი `position_ids`-ის გადაცემით: შენიშვნა HF-ის ტრანსფორმატორების შესახებ — `position_ids` გენერაციის დროს: გენერაციის დროს ჩვენ არ უნდა გადავცეთ `position_ids`, რადგან `position_ids` უკვე მორგებულია ტრანსფორმატორებში (იხილეთ huggingface/transformers#/7552. როგორც წესი, ჩვენ თითქმის არასდროს არ გადავცემთ `position_ids`-ს ტრანსფორმატორებში. დაფარვის (masking) და გადაადგილების (shifting) მთელი ლოგიკა უკვე იმპლემენტირებულია, მაგალითად, `generate` ფუნქციაში (საჭიროა კოდის მუდმივი ბმული). პასუხის გენერაცია იღებს ფიქსირებული სიგრძის პასუხს შევსების გარეშე. პასუხის გენერაციის დროს, OAI იყენებს `top_k=0`, `top_p=1.0` და ახორციელებს კატეგორიულ შერჩევას მთელ ლექსიკონზე (lm_human_preferences/language/sample.py#L43) და კოდი აგრძელებს შერჩევას, სანამ ფიქსირებული სიგრძის პასუხი არ გენერირდება (lm_human_preferences/policy.py#L103). აღსანიშნავია, რომ EOS (თანმიმდევრობის დასასრულის) ტოკენებთან შეხვედრის შემთხვევაშიც კი, ის აგრძელებს შერჩევას. შენიშვნა HF-ის ტრანსფორმატორების შესახებ — შერჩევა შეიძლება შეწყდეს `eos_token`-თან: ტრანსფორმატორებში, გენერაცია შეიძლება შეწყდეს `eos_token`-თან (src/transformers/generation/utils.py#L2248-L2256), რაც არ არის OAI-ის პარამეტრის იდენტური. პარამეტრის შესათავსებლად, ჩვენ უნდა დავაყენოთ `pretrained_model.generation_config.eos_token_id = None`, `pretrained_model.generation_config.pad_token_id = None`. გაითვალისწინეთ, რომ `transformers.GenerationConfig(eos_token_id=None, pad_token_id=None, ...)` არ მუშაობს, რადგან `pretrained_model.generation_config` გადაწერს და დააყენებს `eos_token`-ს. გაითვალისწინეთ, რომ უფრო ახალ კოდების ბაზაში (https://github.com/openai/summarize-from-feedback) OAI აჩერებს შერჩევას EOS ტოკენთან შეხვედრისას (summarize_from_feedback/utils/experiment_helpers.py#L19). თუმცა, ამ ნაშრომში ჩვენ მიზნად ვისახავთ 1:1 რეპლიკაციას, ამიტომ ვათავსებთ იმ პარამეტრს, რომელიც აგრძელებს შერჩევას EOS ტოკენთან შეხვედრის შემთხვევაშიც კი. სწავლის სიჩქარის შემცირება ჯილდოს მოდელის და პოლიტიკის ვარჯიშისთვის. გამოიყენეთ განსხვავებული seed-ები სხვადასხვა პროცესებისთვის. ამ განყოფილებაში განვიხილავთ ჯილდოს მოდელისთვის სპეციფიკურ იმპლემენტაციის დეტალებს. ჩვენ ვისაუბრებთ ისეთ დეტალებზე, როგორიცაა ჯილდოს ნორმალიზაცია და ფენის ინიციალიზაცია. ეს დეტალები მოცემულია შემთხვევითი თანმიმდევრობით: ამ განყოფილებაში ჩვენ ჩავუღრმავდებით ისეთ დეტალებს, როგორიცაა ფენის ინიციალიზაცია, მონაცემთა შემდგომი დამუშავება და dropout პარამეტრები. ასევე გამოვიკვლევთ ტექნიკებს,