Канфігурацыя, Стан, Хранэнне, Запрос: Інжыніерыя кантэксту ў LangGraph

Тыя, хто выкарбоввае працоўныя рашэнні з адпаведных фрэймворкаў, згодна з LangChain або LangGraph, зрэшты сталкнуцца з такімі тэрмінамі, як Config, State, Store і Context Engineering. Лёгка ўявіць, што «кантэкст» значыць толькі пасляпэўнюючую строка запытку. Аднак гэтая думка не вытрывае, калі прыкладнення пачынаюць растаць.

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

Што на самай працы ўключае кантэкст LLM

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

                    LLM
                     ▲
                     │
        ┌────────────┴────────────┐
        │                         │
   User Message             Additional Context
                                │
         ┌──────────────┬──────────────┬──────────────┐
         │              │              │
   Conversation     User Info     Retrieved Docs
      History

Запрос ўсьмо толькі адна з слоёў гэтага стаку.

Чаму важна адарожненне

Запіт на падтрымку, такі як «Дзе апошні замовленне?», вымагае інформацыі пра айдэнтыкацыю карыстальніка, пакульшыя запіты, апошнія замовленні, правілы і даны пра доставку. Калі ўсё гэта помешчаць у адны вялікі запрос кожны раз, ствараюцца вельмі дугія, дорогія і складныя для дыбагавання строкі. Інжынерыя кантэкста — гэта галузь, якая відпаведзядае за тое, што бачыць мадэль, звідку гэта кантэнт, калі ён доступны і як дазго ён застаецца — уключаючы таямніцы, якія мадэль ніколі не павінна бачыць.

Чатыры відзэны кантэкста

1. Config (незменны кантэкст часу выканання)

Config — гэта метаданныя запіту, якія не змінююцца пад час працы агента: ідэнтыфікатор карыстальніка, тэнант, план, локалка, часовы пояс, флагі функцый, аўтэнтыфікацыя. Яго можна перадаць праз спецыяльны об’ект configurable у LangChain:

await agent.invoke(
  {
    messages: [
      {
        role: "user",
        content: "Show my recent orders."
      }
    ]
  },
  {
    configurable: {
      userId: "123",
      tenantId: "companyA",
      plan: "premium"
    }
  }
);

Інструменты можаць чытаць яго безпечна:

const getOrders = tool(async (_, config) => {
    const userId = config.configurable.userId;

    return database.orders.find({
        userId
    });
});

Пользоватар ніколі не вводзіць ідэнтыфікатор; апарат з’яўляе яго з настройкаў пад час выканання.

2. Стан (рабочая памяць)

Стан — цэ характэрыстыка RAM пад час выканання: запісі, рэзультаты работы апарата, завантажаныя дакументы, проміжныя нотаткі, падсумкі. На адзін крок з настройкамі, стан мяняецца праз выконанне вузлаў.

User asks question

↓Search tool runs↓Results added to State↓Model reasons↓Final answer generated

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

3. Хранэнне (довгастраўная памяць)

Стан знікае, калі заканчываецца выканання. Хранэнне застаёцца пры ўсіх размовах: перакананні, прафілі, пярэднія взаімадзеянні, улюбленыя методы, тон напісання. Прыклад: паўтарылася мова пра створэнне дапрацоўак на React; чыраз тыдзень пытанне пра кераванне станам можа спрыяць выбору варыянтав, якія падходзяць для React, без неабяжнага запытання.

4. Кантэкст запытку

У канцэ ўчастакі Config, State і Store суплываюць у фінальны прыказ модэлю: найсвежэйшы тэкст карыстальніка, адцярожаная історыя, запрашаныя дасведчынкі, рэзультаты інструментаў, запамятаваныя праграмы. Памятайце: прыказ — гэта рэзультат кантэкстнага адарожвання, а не весь кантэкст.

Чаму не падаць усё ў прыказ?

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

Спраўа з інжынерыяй програмнае архітэктуры

Config адаптаваецца да параметрамі, які залежнаць цікавасці запытку. State адаптаваецца да рабочай памяці, якая выкорыстоўваецца для кожнай запыткі. Store адаптаваецца да базы дадзеных чыстаі службы прафілаў. Складанне запытак адаптаваецца да формавання выкладку на аднойчыну з калькольных джэрэл дадзеных. Такой падход памагае інжынерам, якія працуюць у частыне сервера, адымлівацца LangGraph без таго, каб спрыяць яго як чыгунную тэхналогію AI.

Практычныя прыкметы

• Зберагаеце Config маленькім і у фармаце з падтрымкай тыпаў.
• Складзіце рэдукеры/вузлы State, якія лёгкая да тэставання.
• Спрыяць запісы ў Store як намерованыя эвэнты продукту, а не як віпадковыя паслядкуванні.
• Фіксаваце, якія слоі спадзяліся на кожную запытку, для дэбагавання.
• Вядомае прывяліваце выкарыстоўванне функцый адымлівання і пошуку ў Store замест на копіюванне цэлых історый.

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

Шаблонамі, якія з’яўляюцца ў прыкладах практычнага выкарыстоўвання LangGraph

Большынства графаў пачынаецца з вузла-рутэра, які пераглядае настройкі (tenant, locale) і стан (пасяродні намеры последньага карыстальніка) пры выборэ шляху. Вузлы загрузкі запісваюць дакументы у стан; вузлы генеравання чытаюць стан і ніколі не трагаюць секрэтныя даны аутантыкація з настройкаў, за выключэнням момента, калі яны вікорыстоўваюць паказвачы інструментаў. Вузлы памяці вырашаюць, чы рэкомендацыя заслуговае на запіс у хранільніку пасля таго, як крок быў завершаны успешна.

Incoming Request

Функція паставлення контрольных точак (колі ёй дазволена) зберагае стан між крокамі, ўнаследкі чаго агенты, які працуюць дзялейчасова, можу продаваць свою працу. Гэта адрознівае яе ад хранільніка: контрольныя точкі забезпечваюць стойкасць на рэвену, тады як хранільнік — памяць продукту межа сесіямі.

↓Middleware↓Load Memory↓Update State↓Generate Prompt↓Call LLM

Калі дыбагуеце некарэктны адказ, запытайцеся, які слой не выканаў свою ролю. Неправы ідэнтыфікатор карыстальніка? Настройкі. Загублены рэзультат інструмента? Стан. Забытая рэкомендацыя? Хранільнік. Занадта велікія токены? Складанне запыту. Такая класыфікацыя ператварае нечыткія адказы на кшталт «мадэль выдумала» у конкрэтыя задачы на дальнейшую працу.

User
↓Agent.invoke()↓Config
(User ID, Tenant ID)↓Middleware↓State
(Chat History)↓Retriever
(Knowledge Base)↓Store
(Long-Term Memory)↓Prompt↓LLM↓Final Response

Таму інжыніерыя кантэкста — гэта не столькі мастацтва стварэння крэатыўных запітоў, сколькі дысцыплінованага абработкі дадзэнняў — тая ж самая спроможнасць, якая дапамагае падтрымваць звычныя веб-бэкенды. LangChain і LangGraph проста даюць назвы кантэйнерам, ў рэзультаце чаго функцыі ШЫ перастаюць складваць усё ў адну строчку.

Анты-шаблоны, якіх трэба утрымляцца

Заноска всего логу чату ў кожны запіт «на всякі случай» спалюе грошы і паслабляе ўвагу. Размешчэнне ключаў API ў сістэмных запітах «для зручнасці» створае рызык выкачкі дадзэнняў. Вжыванне модуля Store як сховішча для тымчасовых дадзэнняў забруднюе будучыя сесіі. Дазвол лептам мутаваць Config пад час працы разрушае гарантыю незменнасці, на якой базуюцься інструменты.

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

Завдзяк такім прычынам тэрміны Config, State, Store і Prompt Context перастаюць быць простымі слоўамі і становяцца „операцыйной сістэмай“ агента — тыхой інфраструктурой, якая робіць мадэль розумней, чым яна была бы без неё.