DXC скараціла разбор ІТ-збояў на 95% — але вынікі правярала сама

13 кастрычніка 2026 года DXC у абвяшчэнні партнёрства з LangChain заявіла, што яе платформа OASIS скараціла сярэдні час вырашэння ІТ-задач на 95% у 500 вымераных выпадках, а дакладнасць дыягностыкі склала не менш за 92% пры параўнанні з меркаваннем старэйшых інжынераў DXC; кіраўнік глабальнай інфраструктурнай службы кампаніі Дэн Грэй падкрэсліў: «models alone are not enough». OASIS ужо працуе ў вытворчых асяроддзях, а яе выкарыстанне сярод кліентаў пашыраецца.

У тэхнічным дакладзе DXC і LangChain ад 14 кастрычніка тыя ж 95% сярэдняга скарачэння часу і не менш за 92% дакладнасці прыведзеныя для 56 вымераных выпадкаў. Даклад дае час да і пасля выкарыстання OASIS для асобных задач і тлумачыць, як агент перадае рызыкоўнае рашэнне чалавеку. Ён не вызначае, ці ўваходзяць гэтыя 56 выпадкаў у шырэйшую групу з анонсу.

Што менавіта DXC вымерала

Дзве апублікаваныя групы маюць розную ступень падрабязнасці. Анонс паведамляе агульны вынік для 500 выпадкаў, а тэхнічны даклад называе 56 і паказвае пяць прыкладаў з інтэрваламі часу. Лічбы з гэтых дакументаў нельга складаць ці трактаваць як два незалежныя эксперыменты: абедзве ацэнкі паходзяць ад DXC, а спосаб адбору і суадносіны груп не растлумачаныя.

• Інцыдэнт файлавай сістэмы: раней ад 53 да 90 хвілін, з OASIS — ад 3 да 6 хвілін.
• Праблема прадукцыйнасці базы даных: ад 2–3 гадзін да 5–12 хвілін.
• Праверка воблачнай палітыкі: ад 4–8 гадзін да 15–30 хвілін.
• Праверка пасля ўсталявання абнаўленняў: ад 45–90 хвілін да 5–10 хвілін.
• Разбор складанай праблемы: ад 2–6 дзён да 8–10 хвілін.

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

Працэнт паскарэння адносіцца да часу вырашэння задач; дакладнасць дыягностыкі — асобная метрыка. Яе DXC звярала з меркаваннем уласных старэйшых інжынераў. Агляд Forkast адзначае, што кампанія не назвала кліентаў і не прывяла незалежнага аўдыту гэтых вынікаў. Таму апублікаванае паскарэнне застаецца вымярэннем DXC, а не незалежна ўсталяваным паказчыкам для кожнага вытворчага асяроддзя.

Як OASIS вядзе расследаванне

LangGraph і LangSmith маюць у OASIS розныя ролі. LangGraph кіруе паслядоўнасцю працы агентаў, захоўвае стан расследавання і дазваляе перадаваць часткі задачы спецыялізаваным агентам. LangSmith служыць для распрацоўкі, ацэнкі і назірання за іх працай; у межах партнёрства DXC ліцэнзуе гэты інструмент. Сама OASIS застаецца платформай і аперацыйнай мадэллю DXC, а не функцыяй LangChain, даступнай кожнаму карыстальніку яе інструментаў.

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

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

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

Дзе рашэнне застаецца за чалавекам

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

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

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

Чытайце таксама:

• Quiet time у Teams выключае гукі, але не хавае вашу даступнасць
• ШІ закрануў офісныя ролі ў 38% кампаній — штат скарацілі толькі 6%
• Першыя крыптабанкі Беларусі зарэгістраваныя, але працаваць яшчэ нельга