Стварэнне агента-памяці знанняў у Databricks з выкарыстоўваннем LangGraph

Базавы агент на Databricks можа перайсці з простага вызову LLM у асістэнта з ведчымі можамі, які шукае ў дакументах і памятае аб корыстніках, прычым кожны крок ёсць просты. Готовы агент ствараецца за дапамою фрэймворку langgraph. У яго ёсць компонент вектарнага пошуку для аднаходжэння тэксту і модуль памяці, таму ён можа прыгадаць тое, што сказаў канечны корыстнік, як у межах адной розмовы, так і ў разныя розмовы. Калі ён запускаецца, наступае ацэнка: вымеры карыстоўнасці падчас разработкі і знову ў працэсе эксплуатацыі.

Інструкцыя складаецца з набору нотбуків, апранутых у папкі па тэмам: фундаменты, канвейер RAG і памяць.

Падготовка рабочага прастору

Полны агент мае вектарныя індэксы, інструменты і логі, і спачатку ўсё гэта патрэбуе адпаведнага месца для зберагчэння. У Databricks слой каральнага управління — цэх Unity Catalog (UC), які керуе кожным актываў пад трывярным іменам прастору. Выкананне нотабукіў у папцы 00_foundations у парадку стварае всі актываў, на якіх базуюцца наступныя крокі, укладаючы ў сябе як структураваныя, так і неструктураваныя даны, да якіх будзе падключацца агент.

Памяць будзе зберагвана ў Lakebase — базе дадзеных, якая падтрымляе Postgres і можа сама налаштавляць розмер. Ёжы, каб пазней можна было без проблем стварыць табелі, нотабук налаштавання таксама стварае праект Lakebase і галузь для ўтрымання іх.

Першы, мінімальны агент

Далей ідуць нотабукі ў папцы 01_rag_pipeline, пачынаючы з 0_your_first_agent_on_databricks.

Każы праматчык ствараецца на аснове модэлі-фундаменту. У Databricks Model Serving перыядаюцца доступныя модэлі, і гэты спіс можа разніцявацца залежна ад таго, як налаштаваны вашы рабочыя просторы. Канцэнтры сумесны з фарматам API OpenAI, але для ўжоўтварэння жорсткай інтэграцыі лепш выбраць офіцыйную бібліятэку databricks-langchain.

Короткае поясненне пра langgraph. Продакшны праматчык рэдка калі ёсць проста адзін прамт. Ён зазвычай містыць логіку розгалужэння, якая залежыць ад запітання і ад таго, як паўтарае ёго корыстувач, а таксама цыклы для запытанняў да зовнішніх сістэм і перафразавання запытанняў на адповідзь. Langgraph організуе гэта, мадэлюючы праматчыка як граф. Вузлы маюць функціі і вызывы LLM, а рэшткі вярнуць кантэкст межы ўзламі. Пачатковы граф вельмі просты.

Выклікаецца агент, і паказуецца лог, у яком перыяквістуюць запіт корыстніка, рэзультат мадэлі і кожны логічны крок у межах гэтага працэсу. Гэта функцыянал даступны за дапамою MLflow, які натычна інтэгруецца з langgraph. Адно выкліканне mlflow.langchain.autolog() у пачатку нотбука увімкнэ гэтыя логі і дыягностыку. Болей шырока інформацыя пра MLflow будзе дана пазней.

У гэтай першай версіі запіт корыстніка проста перэдаецца мадэлі. Справжній агент дадзе сістэмны прыказ, які задае тон, формуе рэзультат і падаёць фонавы кантэкст — напрыклад, для чаго служыць асістэнт і што ён павінен адмовіцца адпавядаць. Таму ў другай версіі у граф стыкаецца сістэмны прыказ.

Дадаванне функцыяналу пошуку

Адзін з найпаўзначыцэйных тыпоў агента — гэта агент для выкарыстоўвання ведамаў, які таксама называецца агентам RAG. Ён дапамагае людзям шукаць сярод велікай колькасці дакументаў і адпавядаць на запытанні пра яе. Ёжчы даўць агенту такую можлівасць, яму патрэбны індэкс вектарнага пошуку, які фактычна ўособлівае базу дадзенаў для неструктураванага тэксту.

Зошыт 01_building_a_doc_store_on_vector_search раскрывае процэс стварэння такога індэксу. Перш чым індэкс можна будзе прыўязаць да агента, ён павінен ужэ існаваць. У гэй частцы рассказваецца толькі пра основныя крокі, а налаштаванне і оптымізацыя прыхоўваюцца.

Стварэнне індэксу выконваецца за трох крокаў:

• Парсінг — гэта ачынэнне дакумента і чытанне яго зместу.
• Разбіўка на часткі — гэта выкарыстоўванне інструменту для розбівання дакумента на адзеленыя секцыі.
• Укладанне — гэта пераклад кожнай часткі у сэмантычны вектар, які зберагаецца ў індэксе.

Кожны з іх мае своія нюансы, а памылкі на раннім этапе тыхо пагароджуюць усё, што будзе адбывацца пасля. У навучальным матэрыяле на всю высоту вікорыстоўваюцца стандартныя настройкі. У рэальных умовах разныя дакументы можаць патрабаваць розных парсероў для правільнага выкарыстоўвання тэксту, а разныя сцэнарыі можаць заставіць патрабаваць розных размераў фрагментаў тэксту, табелей і рысункоў, а таксама розных модэляў укладання.

Databricks апранае інструменты, якія спрыяюць гэтаму. Сервіс Volumes аддае можлівасць вікорыстоўваць хмарны, абсалютна кераваны сховішча об’ектаў для необработаных файлоў. Функцыя ai_parse_documents выкарыстоўвае мінімум налаштаванняў для выкарыстоўвання тэксту, табелей і рысункоў і добра масштабуецца. Spark UDF-ы можаць раздзеляць выкарыстоўваны тэкст на фрагменты рознай дробнасці, якія можна будзе укласты за дапамогою будзь-кага з прэдставленых модэляў укладання.

Калі ужо ёсць эмбеддынгі, для пошуку сэроднечнасці патрабуецца індэкс для вектарнага пошуку. Новы хранальнік дадзеных можа здавацца дапамогай, але Delta Sync справляецца з гэтым, автаматычна ствараючы эмбеддынгі і індэксуючы фрагменты дадзеных, калі яны дадаюцца, змěнююцца або выдалены. Не трэба кераваць новай інфраструктурой і не трэба падтрымваць заданні сінхронізаціі межу табліцай фрагментаў і індэксам.

У першых двух кроках нотбукі ствараныя пад час наладкі файлы у фармаце markdown прыемляюцца, дзеляцца на перакрываючыяся фрагменты по 800 сімвалаў, а пасля завантажуюцца ў Databricks Vector Search. Бібліятэка databricks_langchain мае готовы элемент VectorSearchRetrieverTool, які паў’язвае індэкс з агентам langgraph.

Калі індэкс ужо створаны і працюе, трэці крок перазначае ролю агента. Ён дужа супаменяе пакульшыя версіі, алі ў яго ёсць адна дапамога — ToolNode, які прыймае спіс інструментаў. У даным случае гэты спіс містыць толькі VectorSearchRetrieverTool.

У рэзультаты ўтвараецца такі прайсупутак: запыт прыйходзіць і проходзіць праз шаблон запыту. Мадэль бачыць гэты запыт разам з інструментамі і ўсіма ўпышамі пра яны і вяршыць, чы робіць запыт у індэксе. Ёна можа гэта робіць неадко, і адпавядае корыстніку толькі тады, калі знаходзіць тое, што шукала.

Гэта ўжо рабочы агент тыпу RAG. Граф все ўсё застаецца компактным, пры чым едынай дапамогай являецца вузол інструмента, што паказвае, як мало структуры трэба для цыклу пошуку. Аднак асістэнту з ведамасцю патрэбна ўсё жа ешчэ адна дзялёчка — памяць.

Надаўанне памяці агенту

Як ён зараз практыкуецца, агент не мае жаднай памяці. Падзейны запыт, які апіляецца на паказваны ранейшаю адказ, проста не функцыонуе, таму што мадэль не памятае, што было сказана чырвоны момент.

Ёнколі агенту трэба берчы за увагу паказваныя ранейшаю запыты, langgraph патрабуе checkpointer, які храніць історыю чату. Checkpointers можаць быць як файлы з простым тэкстам, так і цэлыя базы дадзеных. Для масштабавання, змены часу адпаведзення і безпекі лепшы выбор — база дадзеных, а на Databricks гэта значыць Lakebase.

Памяц бывае двух відаў. Короткатэрмінная памяц охопляе толькі чырвоную актыўную сесію. Даўгатэрмінная памяц зберагае факты між сесіямі. Практычна кожная прыкладка патрабуе першага віда, а патрэбна лі чынзвойга залежыць ад сферы прыменення.

Короткатэрмінная памяц

Папка 02_memory адмініструецца разам з 01_short_term_memory, якая додае пункт перапрацавкі. Крокі 1-3 ствараюць StateGraph, ідэнтычныя паканальнаму, а крок 4 показвае, насколькі незручным стае спілкуванне без памяці.

Стварэнне пункта перапрацавкі, прычаўанага да Lakebase, вярнае цэласообразнасць, а databricks_langchain прысвячае клас CheckpointSaver, які можна выкарыстоўваць для стварэння такога пункта перапрацавкі і прычаўання яго да графа.

Агент — гэта служба, якаю выкарыстоўваюць многія корыстувальнікі, таму зберажаныя дыялогі патрабуюць власніка. thread_id выпаловае гэту ролю. У прыметнай аплікацыі фронтэнд павінен ствараць унікальны thread_id для кожнай актыўной сесіі, ўжо тады кожны корыстувальнік бачыць толькі свою історыю чату.

Да кроку 6 пункт перапрацавкі вжо створаны, і спілкуванне праходзіць па-прыроднаму.

Доўгастраўная памяць

Кораткастая памяць знікае, калі заканчываецца сесія. Чырабаць карыстальніка і яго пяраспактуванні агенту трэбае дзяржаць дзяржаўную памяць, а тое, чы робіць гэта, залежыць ад продукту. Асістэнт, які працуе дзяўно, павінен памяцаць пакананыя размовы, факты, такія як імя карыстальніка, а таксама пяраспактуванні, напрыклад, жаданне кораткіх, чыстых адказоў працоў падробных пояснэнняў. Служба адказоў на запыткі ў портале кліента можа лепшая не зберагаць гэтыя дакладнасці, адколі гэта значыць неабходнасць давягчаць на сябе барацтва з захаваннем, шыфраваннем і карыстоўваннем персональных дадзеных працоў дзяўна.

Для кораткастай памяці дапамагае толькі CheckpointSaver. Дзяржаўная памяць выклікае патрэбу ў спецыяльнай разрабоце. Зазвычай не хочацца зберагаць кожную размову на будучыню. Цінныя ў тым, што трэба зберагчы, являюцься факты, такія як імя чы горад нараджэння, а таксама пяраспактуванні.

Зошыт 02_long_term_memory расглядае тэхнічныя аспекты. Крокі 1–4 перазбудовваюць агента RAG з короткакалендарным запам’ятовуванням, а крок 5 паказвае, як пры зменшэнні сесіі і thread_id прыязначэння знікаюць.

У кроку 6 вводзіцца об’ект DatabricksStore, які зберагае даныя ў Lakebase. Гэтая частка простая; справжнім пытанням дызайну ёсць выбор таго, што трэба зберагаць. У кроку 7 выкарыстоўваецца просты падход: калькі фактов заносяцца ў хранілню як жорсткая настройка.

Ёжы выкарыстоўваць іх, у кроку 8 перазрабатываецца агент. Раней вузел агента быў простай функцыяй, якая вызывала invoke у базовай модэлі. Цяпер гэта болей складная функцыя: яна прымеў ID карыстальніка (жорсткая настройка для дэманстрацыі), запрашвае факты гэтага карыстальніка з DatabricksStore і склеюе іх у кантэкст, які надаецца модэлі. Гэты патэрн явна выклікае патрэбу адзяйныго дызайну, каб ён працаваў эфектыва.

Болей гнучкій падчынні дозволяе самаму модэлі выбіраць, калі зберагаць, выдаліць і запрашваць мемары. 12-й крок рэалізуе базовую версію: тры новыя інструменты взаімаюцца з модулем мемароў, а прапанне сістэмы зміняецца, каб паведаміць модэлю пра іх і стварыць стымул да ўжывання.

Рэзультатам яўляецца цалковы асістэнт, і кожную з можнасцей можна працаваць окрэма, адтакуль яны былі рэалізаваны праз аднаэтажны блок нотатак і адзінэтажную змяну графа. Ён шукае дакументы за дапамогою вектарнага індэксу, сочыць за тэкушчай розмовай за дапамогою короткага тэрмінавога мемару і запамячвае дэталі пра корыстнікаў у разных сэсіях за дапамогою дзейнага тэрмінавога мемару.

Куды далей

Шлях развітку працюў ад бота, які перадаваў запіты безпосерэдна LLM, да версіі з шаблонамі запітоў, короткастроковай і дзяўгастроковай памяцюю, а таксі як методам Vector Search для аналізу кантэксту. Наступны крок — перадача цігаў у працэс выпрацоўкі: ацэнка якасці агента, дадаўанне ўсё большай колькасці функцыяналу і ўпроваджэнне яго як сервіса для канечных корыстувачаў.