RAG или fine-tuning: знание срещу поведение в AI проект

Изберете RAG, когато отговорът зависи от частни документи, актуални сведения или конкретен източник, който потребителят трябва да отвори. Изберете fine-tuning, когато нужната информация вече е подадена, но моделът системно нарушава изискванията за задача, стил или формат. Ако грешката изчезва с по-ясна инструкция и подходящи примери, започнете от тях.

Насоките на Microsoft Foundry разграничават двата подхода по същия начин: RAG добавя частни или често променящи се данни към заявката, а fine-tuning променя поведението, стила или изпълнението на задача. Изборът става по-точен, когато екипът установи дали грешният резултат идва от липсваща информация, от неподходящо извлечен откъс или от начина, по който моделът използва вече наличния контекст.

Първо установете къде възниква грешката

Съберете реалистични заявки, очакваните отговори и неуспешните резултати. За всеки случай проверете дали правилният факт е присъствал в подадения на модела контекст. Ако не е бил там, причината може да е липсващ източник, остарял индекс или неподходящо търсене. Ако е бил там, проверете дали инструкцията е достатъчно ясна и дали моделът следва изискванията за отговор.

Разликата между пропуск при извличането и грешка при генерирането е решаваща. При RAG търсенето може да върне документ по близка тема, но без нужния пасаж, или да подаде толкова страничен текст, че важният факт да се изгуби. Fine-tuning няма да поправи индекс, който не намира действащото правило. По-добрият индекс пък няма да реши сам по себе си повтарящо се нарушение на изходния формат, когато правилният откъс вече е пред модела.

RAG за знания, които се променят и трябва да се цитират

При RAG приложението извлича съдържание при всяка заявка и го подава на модела като контекст. Това е подходяща отправна точка за въпроси по вътрешни правила, продуктова документация или други редактирани материали. Сравнението на AWS препоръчва RAG за отговори по собствени документи с позоваване на източника и посочва fine-tuning за допълнителни задачи като обобщаване.

Когато документ се промени, екипът може да обнови съдържанието за извличане и индекса, вместо да разчита моделът да е запомнил предишна версия. Запазената връзка към документа и откъса позволява човек да провери основанието за отговора. Тази възможност изисква правилно настроено търсене и цитиране: връзка към документ не прави отговора верен, ако извлеченият пасаж не съдържа твърдения факт.

Да допуснем вътрешен помощник, който отговаря за действаща фирмена процедура. Ако правилото се редактира и служителите имат различни права за достъп, решението трябва да намира актуалната разрешена версия при заявката. Ако задачата е еднократно обобщение на кратък текст, който вече е подаден изцяло, директна заявка към модела може да е достатъчна; отделен индекс би добавил поддръжка без ясна полза за този случай.

Fine-tuning за устойчив начин на изпълнение

Fine-tuning има по-ясна цел, когато моделът разполага с нужните сведения, но допуска сходни грешки в много представителни заявки. Такива случаи са последователно спазване на сложен формат, специфичен стил на обобщаване или еднообразно класифициране на входящи заявки. Обучението използва примери за желаните входове и изходи; те трябва да приличат на действителната работа на приложението, включително по трудност и структура.

Преди обучение уточнете инструкцията, добавете кратък пример за желания резултат и проверете дали приложението може да валидира формата. За някои задачи това решава проблема с по-малко работа. Ако отклонението остава в повтарящи се случаи, дообучаването вече има измерима цел: намаляване на точно определен вид грешка. Оценката трябва да включва и нови заявки извън обучаващите примери, иначе добрият резултат може да отразява само познати случаи.

Дообученият модел не получава автоматично последните редакции на фирмен документ и сам по себе си не посочва кой запис подкрепя конкретен отговор. Когато промените засягат самото желано поведение, са нужни нови примери, повторно обучение и проверка за регресии. Това е различен цикъл на поддръжка от обновяването на документите и индекса при RAG.

Матрица за свежест, достъп и разход

След като видът грешка е ясен, оперативните изисквания могат да наклонят избора. Те се отнасят до цялото приложение, а не само до модела:

• Свежест. За отговор по последната редакция на документ RAG позволява обновяване на съдържанието за търсене. При fine-tuning промяната в усвоеното поведение изисква нови примери и обучение.
• Цитиране. Ако потребителят трябва да провери основанието за отговора, пазете препратка към конкретния документ и пасаж. Обучаващ пример не е препратка към действащ източник.
• Права за достъп. При частни материали извличането трябва да отчита правата на заявителя, преди откъсът да стигне до модела. Точен отговор от чужд документ пак е неправомерно разкриване.
• Цена. За RAG включете индексирането, търсенето и допълнителните входни токени. За fine-tuning включете подготовката и оценката на примерите, обучението и бъдещите повторения.
• Латентност. Търсенето добавя работа към заявката и увеличава подавания контекст. Дообучаването може да намали нуждата от дълги инструкции, но времето за отговор зависи и от конкретния модел.
• Поддръжка. При RAG следете качеството на извлечените пасажи и актуалността на индекса. При fine-tuning поддържайте набор от примери и проверявайте дали новото обучение не разваля вече работещи случаи.

При частни документи правата са условие за допустим отговор, а не допълнителна настройка за качество. Практиките за Azure AI Search описват контрол на ниво документ, при който данните за разрешенията се записват при индексиране и се прилагат при заявка; описаните интеграции имат различен статус и условия за обновяване на разрешенията. Затова оценявайте и случаи с променен достъп или без разрешен документ, а не само въпроси, за които търсенето намира правилния пасаж.

Нито един подход не е универсално по-евтин или по-бърз. Сравнението има смисъл при характерния за приложението обем заявки и размер на документите, като отчита времето за поддръжка наред с цената и латентността на отделния отговор.

Комбинацията има смисъл при два доказани проблема

RAG и fine-tuning могат да се допълват, когато тестовете показват едновременно липсващ актуален контекст и непостоянно поведение при правилно подаден контекст. Тогава извличането доставя сведенията, а дообучаването цели по-последователното им използване. Добавянето на втори компонент обаче трябва да се оценява като промяна в цялата конфигурация: извлечените откъси могат да внесат и шум.

В примера на OpenAI за поправка на исландски изречения добавянето на RAG към вече дообучен GPT-4 понижава резултата BLEU от 87 на 83. Извлечените допълнителни примери пречат при тази конкретна задача, в която моделът вече е усвоил желаното поведение. Резултатът се отнася до изпитаната комбинация, а не до всеки RAG проект.

За архитектурното решение е полезен един и същ набор от представителни заявки: сравнете ясна инструкция с примери, после подхода, който съответства на установената грешка, и комбинацията само ако остава отделен проблем. Отчитайте верността на отговора, коректността на цитата, спазването на правата, формата, разхода и времето за реакция. Така измерването показва дали допълнителната сложност действително подобрява приложението.