Проектаванне потоковага прыемніка RAG: розбій на часткі, фільтрацыя і стрімування.
Паспорт адаптаванага фундаменту RAG: розбій на часткі з урахоўваннем структуры, безпечнае розділення токенамі, трэхэтапная фільтрацыя даных, з’едыненне частак, проектаванне запитоў і стрімування.
Моделі мов загальнага назначэння чырвоце разумуюць, пішуць і адказваюць на запытанні выключна добра, пакуль не задаеце запытання пра систему, якой яны ніколі не бачылі: ваша внутраняя дакументацыя, процесы роботы у вашай сфере, точна працэўная характарыстыка корпоратывнага прыемніка, які ваша команда настраюе ўсё дзень. Гэтыя знанні нямаўця ў данных для трэнавання, і жадны трюк з запытамі не можа яных там стварыць. Што горэ, модель рэдка прызнае гэтыя прасоці; яна даёт плавны, абавязковы ў своіх адказах прыпуск. Ёсць основы системы генеравання з дапамогай адзысквання інформацыі (RAG): як падготавліваюцца дакументы, як ствараюцца часткі інфармацыі, як фільтруюцца кандыдаты, як формуецца запыт і як адказы доходзяць да корыстніка, а таксама разумовыя падставы кожнай рашэнні, ўпрымкненняе да можна прыменіць яе у сваёй роботе.
Чаму наявнасць базы знанняў зменяе задачу моделі
Сутнасць тэхналогіі RAG лёгка адказаць. Уместо таго, каб паклікацца на тое, што модель запамятае адказ, вы даёте ёй сам адказ на чытанне. Ваша справжня дакументацыя разделяецца на часткі, якія можна шукати; калі прыходзіць запит, система знаходзіць абзацы, якія маюць найвялікшы шанс на адказ на яго, і ставіць іх у контекст модэлі. Задача пераходзіць з „прыгадаць гэты факт“ на „ачытаць гэты абзац і добра яго поясніць“, што ў самым дзеле є тым типам работы, якій мовныя модэлі виконваюць надзеямо.
Канцэпцыя простая, але ўсунуць усі працэвыкнення пад час ўжывання яе не так-то проста. Выбір правильных дадзеных, ўтрыманне ўсьго ў цяплыі структуры і швыракае адпаведзенне, каб ніхто не стаяў і не чакаў, — усе гэта вымагае рашэнняў, якія лёгка перастаць ценіць. Система, описаная тут, ўмышлена знаходзіцца на стадії фундаменту: спачатку запрашаюць дадзеныя, а потым даюць адпаведзенне. Болей амбіцыёзныя розшырэння, такія як графы знаёмых або агент, які викорыстоўвае інструменты, будуюцца на самэй гэтай базе, і яны можу працаваць толькі тады, калі фундамент моцны.
Markdown як адказ на пытанне
Усе знаёмства, на якія адпаведзае система, знаходзяцца ў файлах Markdown. Гэты выбор є практычным, а не эстэтычным. Markdown мае достатню структуру, каб зберагчы значэнне, уключаючы загаловкі, іерархію, спісы і табліцы, пры чым застаецца звычайным текстам, які можна фрагментаваць і вбудоўваць без неабходнасці викорыстоўвання болей складных форматаў маркапінгу.
Файлы ствараюцца так, як люди зазвычай пішучы тэхнічную дакументацыю: загалоўкі па кожнай тэме, падзагалоўкі для деталяў пад ямі, таблыцы там, дзе важна структура, і скріншоты там, дзе картіна поясняе быстрей за прозу. Нічога з стылю пісьма не выкручваецца, каб падходзіла процесу обробкі. Гэта важна, таму што дакументацыя, якая павінна быць напісана для системы пошуку, часта вовсе не ствараецца.
Утриманне скріншотаў за межамі шляху імпліментацыі
Скріншоты заслуговуюць на адзін стыль дизайна. У дакументацыі да прыкладнага програмнага забезпечэння яны не ўжо декор: вялікая частка запытанняў пра тое, як караць, на самай справе стосуецца таго, якія кнопкі аб меню выкарыстоўваць, і проза сама па сабе паслужыць з гэтым слабка.
У зямест на вбудоўванні адпраўк у файлах дакументацыі, адпраўкі размешчаюцца окрема, і кожны файл у формате Markdown апісвае іх за дапамою URL. Супакой ёсць проста тэкст, таму ён пераводзіцца праз процесы фрагментацыі, вбудоўвання і запрашэння так жа, як і любы іншы тэкст. Калі фрагмент, які містіць такі супакой, потрапляе ў адпаведзь, фронтэнд чытае URL і завантажае адпраўку пад час адрасавання. Пользователь бачыць дакументацыю такой, якая была напісана, уключаючы адпраўкі, тады як працэсы пракуплена і запрашэння ніколі не обробляюць даных адпраўкаў.
Этот прынцып варта назваць: трэба заставляць кантэнт у варыянце тэкста на кожным этапе, дзе патрэбен толькі тэкст, а багатае медыя запрацоўваць у пасляпэльны момент, калі ўжо збіраюцца паказаць яго чалавеку.
Стрімаванне адпаведзі ў момент яе стварэння
Той самы прынцып „пасляднага крока“ прабывае і пад выдачай адказоў. Калі працэс стварэння адказу пачынаецца, няма прычыны заставляць корыстніка чакаць на вялікі адказ. Токены прыходзяць па стойкай з’ўязку ў момент, калі модель іх стварае, таму адказ формуюцца паштоўку за паштоўкай, прычаму ён нагадвае напісанне пояснення. У поўнай зусиллі з адпрацоўкай зображэнняя, якія завантажаюцца асінхронна, калі ўсе іх URL-адрысы з’являюцца ў потоцы, вось така суперасунка стварае адчуць размовы, хоця на практыцы гэта ўсё-такі запит да базы дадзенаў, пасля чаго выконваецца стварэння адказу.
Хіерархічнае раздзелэнне: адказ на формат дакумента
Перш чым можна быць шукаць які-небудзь матэрыял, дакумент трэба раздзеліць на елементы, кожны з якіх можа быць включаны і выкарыстоўваны незалежна. Самэ на гэтым этапе багатыя системы RAG часта прымаюць спрощэння, а наследкі гэтага легва ўпусціць з увагі.
Чаму фіксаванае раздзелэнне на часткі таямна не дапамагае
Наўманітны падход ёсць механічны: выбираецца колькасць токенав, дакумент раздзеляецца на часткі прыбліжна такога размеру, і ўсё. Ёго легка стварыць, але ён бясправі так, што ніколі не выклікае памылак. Вікно фіксаванага размеру не мае уявлення пра межы рэчэй, а тым болей пра канцэптуальныя межы. Ён без проблем дзеліць нумераваную інструкцыю на две часты, адсаючы табліцу ад заголовка, які надае ёй значэння, або залишаючы вялічыну ў одной частцы, а яе прыклад — у іншай.
Такія часткі маюць правильную дужыну, але неправильную форму, і якасць выкарыстоўвання тексту залежыць ад формы. Якщо выкарыстоўваны текст не мае цэлага мыслення, нават адзяржліва наладка пасляэтапна не можа яго вярнуць. Модель рассуждае на адны фрагмент, і адпаведна ўзьвішчаецца і адпаведны адказ.
Альтэрнатыўна — чытанне дрэва заголовкаў
Хіерархічна сегментацыя выклікаецца з адзначэння таго, што дакументацыя вже мае структуру, і што гэтая структура ўжо являецца асетам. Якісна тэхнічная дакументацыя складаецца з дрэва заголовкаў: галоўныя раздзелы, падраздзелы, якія знаходзяцца ў іхнім падпараграфе, а таксама текст, які прыўязаны да кожнага рэвэлю. Уместо таго, каб ігнораваць гэтае дрэва, пры сегментацыі ён пераследуецца:
- Кожны галоўны раздзел стае самастоятельным сегментам.
- Кожны падраздзел таксама стае самастоятельным сегментам, але ён фіксуе свой галоўны раздзел-параднік.
- Якщо падраздзел настолькі корак, што яго лепей чытаць разам з галоўным раздзелам, то яны аб’еднваюцца ў адны сумарны сегмент уместо таго, каб створыцца маленькі фрагмент без належнага контексту.
- Контэнт, які не належыць ні да якога заголовка, такі як вступы, аддзеленыя параграфы чы прыміткі, таксама фіксуецца як самастоятельны тип сегмента, а не прыбываецца чы прымушваецца некрэатыўна включыцца ў суседні сегмент.
Метаданы, якія дазваляюць выконваць пазнейшыя этапы
Кожны фрагмент несе больш, чым простае тэкста:
- Следы структуры: ланцуг заглаваў-прадку. Фрагмент, які апісвае адзін параметр налаштавання, як і раней, ведае, што ён належыць да шырэйшага процесу, нават калі яго запрашваюць окольна.
- Атрыбут типу: дапамагае розразліцаваць верхніявыражэння, вкладаныя деталі, з’едыненыя фрагменты-родыкі і самастоятельныя прымечанні.
- Стабільны ідэнтыфікатор: спаявае фрагмент з яго точным месцам у аднаго файле-выканніку.
Гэтыя метаданы — гэта не проста декорацыя. Яны ёсць тым, што пазней дазваляе пераранжаваць элементы, знову складваць роздзелы, якія былі раздзелены, і даўаць цэлеспрабавныя, адназначныя адказы. Плоскі список фрагментаў роўнагабаритных за вялічынай тэкстаў не можа падтрымаць нічога з гэтага; фрагмент, які ведае свое месца ў структуре, можа.
Асалідны выбар — гэта следаваць структуре, якая ўжо є у дасведчыку, а не прыменяць якую-небудзь довільную. Гэта дае рэзультаты быстра: фрагменты чытаюцца як цэлыя мысляй, таму што ўсё-такі являюцца цэлымі мыслямі, структураваныя так, як іх структураваў ўпоряднік дасведчыку.
Адаптатываны другі этап для ліміту токенав у вбудоўванні
Хіерархічна структурацыя дапамагае правільна сформаваць фрагменты, але яна не ведае пра жорсткія обмежэння, якія існуюць: модель для вбудоўвання прыменяе толькі адмежаванае колькасць токенав за вхідны даны. Структура дасведчыку не зважае на гэты ліміт. Дзялёная FAQ, вялікая табылка-справака або падраздел, які проста ўздовжняе, можа быць абсалютна цэлеспрямованым фрагментам, пры тым як усё-такі перасягнуць межы, якія можа прыменяць модель.
Гэтыя неудачы выглядаюць апаганебна тыха. Залежна ад кліента, занадта большы фрагмент альбо адхоўваны, альбо тыха скорачаны пры включэнні, і ў обох случаях контент зникае без жадных адчуванняў у момент прыемкі. Скорачэнне є болей небяспечным наследкам, тым што фрагмент все ўсё існуе і продовжае быць запрашаным; яго вектар проста больш не прадстаўляе текст, які вы думалі.
Рашэнне — гэта другі этап пасля іерархічнага. Кожны фрагмент перакантролюецца за дапамогою практычнага порога, які знаходзится значна нижэй за практычны максімум моделі, тады існуе буфер у заместо рэзкага канца. Колькасць токенаў разніцяецца ў разных токенайзерах, і пэўны запас памагае перакантролюваць гэту нявясковасць. Фрагменты, якія знаходзяцца нижэй па порогу, праходзяць без змян. Фрагменты, якія знаходзяцца вышэй, далей дзелююцца, і кожны отрыманы фрагмент:
- ясна пазначаецца як частка большога цэлага, ўсёлякія наступныя этапы можу знайсці яго саўтэйкі
Тое, дзе самэльва перерваць і чаму проста разлічэнне недастаткова нават у такім случае, ўсё гэта є значным самастоятельным пытаннем дизайна. У основе лежыць тое, што іерархічны пас гарантуе правильную форму, а адаптатыўны пас — ўпоркненне, так што хорашая форма ніколі не коштуе вам контэнту.
Зберагчыце вектары разам з іх метаданаямі
Вбудованные фрагменты патрэбуюць структуры, створанай для аднаго пытання: калькі з усіх эўтах вектараў ёсць найбліжэйшыя да гэтага новага, і на яго трэба адпаведзець быстра і у великіх масштабах. Сяроднікавыя базы дадзеных не створаны для такога запиту, таму для гэтай меты выкарыстоўваецца спецыяльны хранальнік вектараў.
База дадзеных працюе ў контэйнеры, а не інсталюецца безпасова на хост. Прычыны гэтага практычныя: інстанцыя ў контэйнеры лёгкая да запуску, адмовы чы ўзьязду на іншую машыну, і яна не прыносіць жадных залежнасцей на систему хоста.
Разам з кожным векторам хранілыш чыніць полную пакет мэтадаў, які включае текст часткі, індыкаторы паводзяў, тип і ідэнтыфікатор вучання. Такім чынам кожны рэзультат схожасці прыходзіць з усім неабходным контекстам, каб яго можна было адразу выкарыстоўваць, а не як ананімны вектор. Спалучэнне шырокага пошуку схожасці з багатымі мэтадаў, прыкрепленымі да кожнага рэзультата, дазволяе выконваць фільтрацыю, пераранжаванне і зборку сяброўскіх элементаў без неабходнасці яшчэ аднаго пошуку ў іншым источніке дадзеных.
Жыцёвы цикл запиту: ад пытання да потокавага адказу
Што стосуецца самай важнай часткі, гэта там, дзе система выкарыстоўвае сваю справжню працэздатнась, таму варта яе апісацыю зробіць настолькі точна, каб логіку можна было перысваяць знову.
Раздзелэнне процеса адправкі і стрімування
API адкрывае два канцэнтры з рознымі заведаменнямі. Першы прымае запитанне і негайна вяртаўшы ідэнтыфікатор размовы. Другі — это канцэнтр стрімування, да якога фронтэнд падключаецца за дапамогою гэтаго ідэнтыфікатора. Прыjęце запитання і выдача адказу — это разныя задачы, і самэе ўсуненне іх адзіна з іншай дазволяе адказ вяртацца паэтапна, замест таго каб адзіны запит заставался відкрытым пакуль не будзе гатовы адказ у виглядзе ўсёўмеснага тэксту. Гэта таксама дае кліенту можлівась чыстага способу для падключэння зноў або супарабаткі лог-даных для конкрэтной размовы.
Между гэтымі двума канцэнтрамі выконваюцца следуючыя крокі па порядку.
Крок 1: уключэнне запитання за дапамогою моделі абрабаткі
Тэкст пользователя адмаскаваецца за дапамою таго ж самога модэлю, які быў выкарыстоўваны пад час прыемкі. Гэта не тая деталь, яку можна зменіць. Порэшанні пра супадзінне маюць значэнне толькі тады, калі вектар запиту і збераганыя вектары знаходзяцца ў той самай вектарной прасторы. Як толькі модэль адмаскавання зменяецца, кожны збераганы фрагмент неабходна перадмаскаваць, таму што вектары з двух разных модэляў не можна пораўняваць, нават калі яны описвуюць ідэнтычны тэкст.
Шаг 2: шырокі пошук
Вектар запиту парабягаецца з вектарамі збераганых фрагментаў, і выявляецца прыблізна дванаццаць найбліжэйшых падабенстваў. Мера — косай супадзімасць, якая па суты меры куточак межы двума вектарамі: чым меншы куточак, тым больша супадзімасць значэння. Гэты этап ўмышлена є ўмерзкі. Яго мета — перакананне, што нічога значэннявага не будзе адханаць прычым да пачатку справжняга выбору.
Шаг 3: скарблік кандыдатаў праз тры фільтры
Па спецыяльным алгорытмам працуюць тры фільтры па спрабе зменшыць колькасць дзесятка кандыдатаў да тых некалькох, якія маюць значэнне:
- Фільтр падобнасці. Кандыдаты, якія маюць меньшы за мінімальны рэйтынг, адключаюцца. Оось тыя фрагменты, якія патрапілі у список толькі таму, што не было нічога кращаго, а ўтриманне іх прынесла бы толькі шум.
- Працэс перыякшання рэйтынга. Тыя, хто перажыў першы фільтр, зноў оцэнююцца за дапамогою моделі, якая працуе інакш за першы пошук. Уместо таго, каб окрема аналізаваць запит і кожны фрагмент, а потым поручваць вектары, модель бере запит і адзін фрагмент як саюзны вхід і выявляе, чы рэальна той фрагмент адпавядае на запит. Цэй спосабом усуваюцца фальшывыя пасположныя рэзультаты: фрагменты, якія знаходзяцца поблізу запита ў вектарнай прасторы, але на практыцы не маюць адпаведнай адпаведзі, калі чытаць іх разам з запитам.
Кожны элемент мае свою функцыю: першы захіщае аналіз вантажу від шуму, другі забезпечвае точнасць, а трэці встановляе строгі ліміт па колькасці контексту, який можа дастыся модэлю. Тое, што застаецца, — це найкращыя наявныя даны, а не проста верхняе месца ў дужа дзялёнай спісе.
Прычына такога прадактару — цэна. Алгорытм переранжавання на адной паре дастакоў є значна точнейшы, чым порэванація вектароў, але таксама значна дорожы, таму што ёму трэба адразу обрабоцаваць кожную пару частак пытання. Його запуск на дзесяці празфільтраваных кандыдатаў у замяну на весь корпус дазволяе атрымаць трэбную точнасць без падпісанняў усіх зусіль.
Шаг 4: вярнуць роздзеленыя часткі
Дзеяныя фрагменты часта яўляюцься толькі часткамі адзела, якій пры адаптатыванні паказалося роздзеліць. Якщо модель отрымае, скажамо, другую з трох паўчастак без жадных натыякіў пра наявнасць іншых, яе адпаведзь будзе базавацца на частковай інфармацыі. Таму, прыяўляючы запит, спачатку пераканальваюцца ўсе дзеяныя фрагменты на наявнасць іх «братоў» — іншых частак таго ж адначасовага адзела. Калі такія часткі існуюць, яны запрашаюцца і размешчаюцца па порядку, кожная з адзначэнням свайго положэння. Пасля чаго модель чытае цэлы адзел, а не толькі яго частку. Самэль гэтаму і служаць адзначэння частак і стабільныя ідентыфікаторы, якія прыймаюцца пад час обробкі даных.
Шаг 5: складанне запита
Усе атрыбуты, якія былі выкараны, разам з ўсімі іншыма атрыбутамі той жа категорыя, ствараюць базовы контекст. Запит корыстніка перавозится разам з ім, а прампт системы, які будзе описаны ў наступным раздзеле, паведамляе модэлю, якую ролю ён должен выпалваць і як викорыстоўваць цей матэрыял.
Шаг 6: адправка адпаведзення па стріму
Створаны текст адправляецца па той самым каналу стріму, да якога спачатку быў падключены кліент, пры чым ён надаецца па маленькіх частках, а не як ўсёе адпаведзенне за раз. Корыстнік можа бачыць, як формуецца адпаведзення, у рэальны час.
У канцы: запит трэба вектарызаваць, выкарыстоўваць шырокі пошук, фільтрацыю праз тры рубікі, дапраўляць нехваткаючыя часткі, даваць модэлю прампт і адправляць яе выходны результат па стріму. Жадна з этапаў не є выключным элементам. Якосьць адпаведзення залежыць ад чыстага перадачы інформаціі межу этапамі і ад таго, каб кожны этап меў толькі адну задачу.
Проектаванне прампта: формат, модэль і тон
Калі ўжо сформавана запитальна фраза, проблемы з выкарыстоўванням дадзеных ўжо рашаныя: былі знайдзены, афармаваны та пераскладзены праві фрагменты. Але тое, што застаёцца, таксама можа прынесці проблемы — трэба так праказаць матэрыял, каб модель даў хорашую адпаведь, а не проста тэхнічна правильную.
Запіс запитальнай фразы ў Markdown
Сама прыгласоўка напісана на Markdown. Працэспадчыны тут такія ж: моделі бачылі вельмі большую колькасць тэкста на Markdown у дасяглічных матэрыялах, файлах README і тэхнічным текстах, таму інструкцыі у знайомым формате аналізуюцца надзейней, чым інструкцыі у спецыяльной структуре, якую модэлі трэба декодаваць. Загаловкі раздзеляюць часті прыгласоўкі, адзначаны контэнт чыста адсеканы ад суседзячых інструкцый, а ўсё кантэнт, пераскладзены з розлучаных частак, мае відразумелы знак, таму модэлі можа адразнаць „адно цэлае панявленне, складзеная з частак“ ад звычайнага адзначанага тексту.
Выбір меньшага, быстрэйшага модэля для сінтэзы
Модель, яка підбирае заканчоўны адказ, ёсць меншаі і шырэй за час вычыслення, а не найбольшая з усіх доступных. Гэта можа здавацца па-іншаму, калі толькі не паглядзець на тое, канкрэтна ўона выконвае. Яе не прасябае нічога стварыць з нуля, запам’ятаць рэдкісныя деталі чыста падкрываць нехватку знанняў; важкая частка роботы вже адбылася раней, падчас пошуку і фільтрацыі. Яе застаённая задача — взяць рэтельна выбраны, апорядкованы контекст і ператварыць яго на чысты, шырэй за час адказ у правім тоне.
Это задача сінтэзу. Калі контекст уже ўжо є, компактны модель дае адпаведныя рэсультаты па якосці, пры чым адпавядае быстрей і коштуе значна меней. Здатнасць большога модэля да логічных выводаў цяжка пераканацца ў тым, калі модель павінна сама ўсё вырашыць. Яе цэннасць значна зменшаецца, калі адпаведныя рэсультаты вже є, і задача заключаецца у ўсёбічным ўз’яшчэнні іх. Баланс залежыць ад якосці запрашэння: чым слабейшы контекст, тым важлівейшая становіця мае здатнасць большога модэля да рашынавання неяснасцей, што ўжо адной з прычын для інвестыцый у стадіі фільтрацыі.
Структура запрашэння
Системнае запрашэнне выконваецца за фіксаванай структурой, а не імпровізавана:
- Роля. Спачатку паведамляецца модэлю, які ён асистент і у якой галузі працюе, тады тон і прыяпущэння ўжо з першай лініі є налаштаваныя.
Нічога не залишаецца на розсуд стандартнага падходу модэлі да таго, як должны выглядаць адпаведныя асистэнты. Кожна дзеянне прызначана, падобна да нараджэння новага члена каманды, калі спачатку поясняюць нормы каманднай комунікацыі, перш чым парадзіць якую-небудзь роботу.
Рэзультатам являецца асистант, які адказвае з упэўненасцю, калі ёсць падставы, чыста прызнае, калі іх няма, і падтрымлівае аднаковы тон у кожной беседзе. Гэтая аднаковасць не выходзіць з самага модэлю; яна выходзіць з запиту, які ўжоўся да яго.
Распрацоўка за намерам: звычайныя фрагменты і фрагменты экрана
Запытанні, які выглядаюць адна як другое, можу прасіць пра вельмі разныя рэшчы. Запытанне на кшталт «Як вылічаецца цэна ў гэтым процесе?» ёсць концэптуальным і выкарыстоўваецца для атлагоджання розумяння. Такое запытанне, як «Які поле на гэтым экране выкарыстоўваецца для введення цены?», мае навігацыйны характер і прасіта паведамлення пра конкрэтнае поле, кантактную пунктую чы адзін з рэгіонаў інтерфейса. Хоця для адпаведзення на оба запытанні можна выкарыстоўваць часткі з аднаго і тога ж роздзела дасведчэння, ідеальныя адпаведзенні практычна не маюць нічыя спольнага. Адночаснае атрыманне адпаведзенняў для яных прыводзіць да таго, што людзіне, якой была патрэбна толькі інформацыя пра месца, даваецца концэптуальны выклад, але ў горшым случае — прыводзіць да абстрактнага опису элемента інтерфейса, калі корыстувальніку была патрэбна яго точная локацыя.
Раздзелэнне дасведчэння пад час ўваходжання
Разлік вводзіцца на рэвэне чакаў, а не толькі пад час адпаведзення. Паралельна з звычайнымі чакамі дакументацыі у прозе, існуе другая катэгорыя, якая мае ў сабе контент, які описвае экраны і их поля: як называецца кожна поль, што ёна робіць і дзе яна знаходзіцца адносна іншых поль на там самым экране. Ооні не пазначаюцца пасля таго, як контент быў прыjęты. Класыфікацыя выконвалася падчас прыjęцья контэнту, таму калі прыходзіць запит, існуе два чыста разлучаныя аб’екты знання, а не адна неразлічованая купка.
Выбір спосабу адпаведзення пад час запиту
Калі прыходзіць запит, яго адначасова ацэнююць, каго роду чак ён на самай працэ запитвае: концэптуальную дакументацыю чы конкретныя деталі экрана і поль. Гэта класыфікацыя вплывае на тое, якія чакі будуць прыоритэтныя падчас пошуку і якое адпаведзенне отрымвае модэль:
- Для запита, спрямованага на экран, даёцца падказка, прызначаная для точнага адпрацоўвання элементаў інтэрфейсу: буквальная, конкрэтная і сфокусаваная на тым, дзе самэ і што самэ.
- Для концэптуальнага запита даёцца падказка, прызначаная для адчыненняя: шырэйшая і болей склонная да з’ўязку ідэй.
У обох случаях трыбуты адзысквання і модэль генеравання застаюцца тымі ж; зменшваецца толькі падход да адпаведзення, які выбіраецца ў залежнасці ад таго, калі запитаўка патрабуе, а не шляхом прыменення аднаго універсальнага шаблона да кожнай адпаведзі.
Гэта мае большое значэнне, чым можа здавацца. Асистант, які выкарыстоўвае аднаковы стыль адказаў, будзе звучаць універсальна, незалежна ад якосці яго пошуку. Розпазнаванне намеру, а не толькі тэмы, яго робіць такім, што асистант выглядае так, нібы ён зважае на тое, што на самай працы было запитана. Якщо вы застосуеце такі падход, трэба маты альтернатыўу для неясных запитоў – напрыклад, пераходзіць да канцэптуальнага падходу і включаць усі сэкцыі экрана, якія добра падходзяць, так ў разе неправильнай класыфікацыі рэзультат будзе прыемны, а не будзе даўся неправільны стыл адказа.
Контроль памяці
Акрытая выявленне і стварэнне маюць значэння толькі тады, калі сервіс паступова не выкараняе свою память. Процес, який вбудоввае текст, заставляе фрагменты застацца ў памяці, складае запиты і передае рэзультаты, павтараючы гэты процес інодзе адночасна, тыхо накаплівае напругу на памяці, якщо толькі хтось актываўна яе не карыстаецца. Об’екты, якія патрэбны толькі для аднаго запиту, часта застаюцца ў памяці дыльнейш, чым трэба, калі ніхто іх не ачышчае.
Таму ачышчэнне памяці не залічваецца на вялікай валі збытку. У природных межах, такіх як заканчэнне запиту або завершэння пакета даных, память явна адзysкаецца занова, уместо таго каб пакладацца на тое, што яна зрэшты сама ачысніцца. На практыцы гэта значыць абрыранне звязкаў з вялікімі проміжнымі об’ектамі, ачышчэнне кеша па кожным запиту і, для локальна размешчаных модэляў, вызваленне всія памяці, яку заставляе сабе рантайм.
Это неяскравая робота, якая ніколи не практыкуецца ў дэма-версіях і прыкладзецца толькі тады, калі яе не хапяць: адносна сэрвіса, якога карыстоцкая спроможнасць падупала ў меры дзейнаг часу, а не тады, калі ён адпавядае на тысячны запит так жа быстро, як і на першы. Ёў правільны рэалізаванні залежыць меньш ад кмітлівага інжынеравання, чым ад дисцыпліны – трэба ставіцца да памяці як да чагось, што кожны этап контролюець, а не як да чагось, што павінен без проблем адмаўляць рантайм. Спостерагачы за памяцю працэсе дзейнаг часу, а не толькі падчас короткага тэста, – гэта простыш спосаб убедзіцца, што дисцыпліна дэйствуе.
Ключовыя выводы
Опісаная тут база – это цэлысны, аднолікі RAG-пайплайн: частковае раздзеленне з урахоўваннем структуры, вбудовыванне токенав без рызыка, багатоэтапнае фільтраўанне, перыяднаванне роздзеленаых частак, дисцыплінованы запрос, які прыводзіць модель да адказу ўсупершыню, і доставка рэзультатаў у рэальны час. Найважлівейшыя рашэння – гэтыя:
- Зберагаюце дакументы у структураванам формате простага тэксту, а з’явы і іншы медыя адгружаюце толькі пад час адрасавання.
- Дзельніцявайце тэкст па дрэвах заглавых і да кожнай дзельніцы прыкладвайце пазнакі шляху, абяронныя табліцы і стабільныя ідэнтыфікаторы.
- Адрабатайце другі этап, які дазволяе сягнуць ліміту токэнаў моделі з павышаннем безпекі, адзначаючы часткі тэксту і маленькія перакрыцця.
- Заўжды адрабатайце запиты за дапамогою той самой моделі, якая викорыстоўвалася пад час прыемкі дакументаў, і перадрабатайце всё, калі гэтая модель змінюецца.
- Спачатку адзначайце множыцтво рэзультатаў, а пасля скарочайце іх за дапамогою прагаў сэмабільнасці, переранкера на адлічэнне парагоў і строгага заканчальнага ліміту.
- Перад тым, як даваць заданне моделі, знову склейвайце роздзяленыя часткі, каб модель ніколі не працавала з незазначаным фрагментам.
- Дазвольце меншай, быстрей модэлі выконваць синтэзу пасля таго, як процес адзначэння рэзультатаў восьбіць усю важку работу, і чытка прызначайце яе ролю, задачу, спосаб развязвання прызначоў і тон.
Кожны з гэтых выбораў сам по сабе є скромным. Разам яны ствараюць систему, чыя адказы є падставленымі, супараднымі і шырокамаротнымі, а таксама даюць вам стабільную базу для болей амбіцыёзных методаў выкарыстоўвання інформацыі пазней.
Спаднёе чытанне
- Beyond Top-K: Relevance Thresholds, Hybrid Search and Reranking in RAG — Дакладзіце, чаму база дадзеных у вектарнай форме плюс LLM не ёст канцэптуальная система RAG, і як чакунаванне, прагрызы сэмабільнасці, гібрыдны пошук, переранкаванне і ацэнка запытанняў закрываюцы гэтыя прасоці.
- Чаму RAG у прыметнай эксплуатацыі выходзіць за межы спецыяльных баз дадзеных вектараў — Аналізуецца, чаму самастоятельныя базы дадзеных вектараў трапляюцца ў занепадзе ў системах RAG у прыметнай эксплуатацыі, а таксама як гібрыдныя методы пошуку, фільтрацыі і аб’еднаныя шары дадзеных перацвараюць структуру такіх систем.
- Карта RAG: стадіі практычнага апрыёму, ключовыя складовы і варіанты реалізацыі — Паследовна раз’яснюецца, як працюе тэхнологія генеравання з падкрэпленнем дадзенымі, якія складовы неабходны для системы RAG і як розныя варіанты такіх систем упорядковуюцца ў адну структуру.