Jev AI у LiteTMS: дзе мы знайшлі яму прымяненне

Мы ўбудавалі Jev, мадэль штучнага інтэлекту ад TypeSafe AI, у некалькі рабочых працэсаў LiteTMS. Яна дапамагае заўважаць паведамленні кіроўцаў, якія патрабуюць увагі, правяраць, ці адносяцца дзве назвы да аднаго горада, падказваць, як інтэрпрэтаваць файл імпарту, і пазбягаць перакладу паведамленняў, калі яны ўжо напісаны на мове чытача. Гэта кропкавыя ацэнкі ўнутры сістэмы кіравання транспартам, а не чарговы чат-асістэнт для офіса.

Калі гэтае імя вам яшчэ не знаёмае, наш першы артыкул пра Jev тлумачыць агульную канцэпцыю. Тэкставы ШІ генеруе разгорнуты адказ на запыт. Jev жа створаны для адказу на больш вузкае пытанне, напрыклад: «Ці патрабуе гэтае паведамленне адказу?» LiteTMS выкарыстоўвае гэтую ацэнку ў адпаведным працэсе.

Паведамленні ад кіроўцаў, якія патрабуюць пільнай увагі

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

Напрыклад, «У цягача прабіта кола» значна адрозніваецца ад «Я прыбыў». Паведамленне, якое патрабуе дзеянняў, адлюстроўваецца ў спісе задач, якія патрабуюць увагі, а тэхнічная праблема з транспартам можа таксама выклікаць тэрміновае апавяшчэнне. Офіс усё адно можа прачытаць перапіску, адказаць і адзначыць пытанне як вырашанае. Jev не адпраўляе адказы кіроўцу і не вырашае, як ухіляць паломку.

Для паведамлення пра прабітае кола ацэнка ШІ ў фармаце JSON выглядае так:

{
  "input": { "driver_message": "I have a flat tyre and cannot continue." },
  "jev_assessment": {
    "category": "vehicle_problem",
    "needs_action_probability": 0.94
  }
}

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

Назвы населеных пунктаў у замовах і транспартных дакументах

У дакуменце можа быць напісана «Köln», а ў замове - «Cologne». Літаральнае тэкставае параўнанне ўспрымае іх як два розныя словы, хоць гаворка ідзе пра адзін і той жа горад. Мы дадалі праверку праз Jev менавіта для такіх задач: пры апрацоўцы замоваў з дапамогай ШІ і пры праверцы пунктаў у дакументах CMR.

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

Для двух варыянтаў назвы горада ацэнка можа выглядаць так:

{
  "input": { "document_place": "Köln", "order_city": "Cologne" },
  "jev_assessment": { "same_city_probability": 0.92 }
}

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

Файлы імпарту з нестандартнымі загалоўкамі

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

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

Выкажам здагадку, што ў табліцы аўтапарка выкарыстоўваецца «Unit ref.» для рэгістрацыйных нумароў і «Internal ID» для ўнутраных кодаў транспарту ў кампаніі. Прыклады значэнняў дапамагаюць Jev адрозніць гэтыя слупкі. Калі звычайныя правілы апрацоўкі загалоўкаў пакідаюць поле рэгістрацыйнага нумара пустым, ацэнка можа выглядаць наступным чынам:

{
  "input": {
    "columns": {
      "col_0": { "header": "Unit ref.", "examples": ["WX 4821A", "PO 7619K"] },
      "col_1": { "header": "Internal ID", "examples": ["FLEET-17", "FLEET-42"] }
    },
    "field_to_match": "registration_number"
  },
  "jev_assessment": { "column": "col_0", "probability": 0.93 }
}

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

Невялікая праверка перад перакладам у чаце

Часам паведамленне ўжо напісана на мове чалавека, які яго чытае. Перш чым запускаць поўны пераклад у чаце, LiteTMS можа запытаць у Jev праверку гэтага факта. Упэўненае супадзенне дазваляе сістэме паказаць арыгінальнае паведамленне; няпэўны адказ накіроўвае яго па звычайным шляху перакладу. Гэта звужае рамкі рашэння: чытач усё роўна атрымае пераклад, калі сістэма не можа ўпэўнена яго прапусціць.

Возьмем кіроўцу, які піша «Jestem na miejscu, czekam na załadunek», што азначае «Я на месцы, чакаю загрузкі». Для чытача, які карыстаецца польскай мовай, праверка можа даць такую ацэнку:

{
  "input": {
    "message": "Jestem na miejscu, czekam na załadunek.",
    "reader_language": "pl"
  },
  "jev_assessment": { "language": "pl", "probability": 0.96 }
}

Вызначаная мова супадае з мовай чытача, таму LiteTMS можа паказаць арыгінал. Для чытача, які карыстаецца англійскай мовай, гэтае ж польскае паведамленне па-ранейшаму патрабуе перакладу. Кароткі адказ накшталт «OK» менш інфарматыўны: калі мову немагчыма ўпэўнена вызначыць, застаецца даступным звычайны шлях перакладу.

Як ацэнка Jev убудавана ў LiteTMS

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

Тэхнічны погляд: TypeSafe Jev, JSON і Java

Для чытачоў, якія хочуць убачыць, што адбываецца знутры, карыснай адпраўной кропкай з'яўляецца пытанне, якое мы адпраўляем. Як паказвае кіраўніцтва па хуткім старце TypeSafe, запыт змяшчае state (інфармацыю для ацэнкі) і questions (ацэнкі, якія трэба зрабіць). Пытанне тыпу noul вяртае лік ад 0 да 1, які адлюстроўвае імавернасць таго, што сцвярджэнне слушнае. Пытанне тыпу choice выбірае сярод названых варыянтаў, і менавіта так мы запытваем катэгорыю паведамлення.

Вось само пытанне пра дзеянне, якое выкарыстоўвае ідэнтыфікатар мадэлі, настроены ў нашай інтэграцыі з OpenRouter:

{
  "model": "typesafe/jev-1.13",
  "state": {
    "driver_message": "I have a flat tyre and cannot continue."
  },
  "questions": {
    "needs_action": {
      "type": "noul",
      "instructions": "The dispatcher must act on driver_message today: reply, give instructions, inform the customer or arrange help. Routine updates and thanks need no action."
    }
  }
}

Адпаведная частка адказу можа выглядаць так:

{
  "answers": {
    "needs_action": {
      "type": "noul",
      "noul": 0.94
    }
  }
}

Дадатак счытвае answers.needs_action.noul і прымяняе правіла. LiteTMS выкарыстоўвае парог дзеяння 0.55 для прыцягнення ўвагі да паведамлення кіроўцы. Пасля дэкадавання JSON гэтую ж праверку можна запісаць на Java:

Double probability = 0.94; // Value from answers.needs_action.noul
boolean needsAttention = probability != null
    && Double.isFinite(probability)
    && probability >= 0.55
    && probability <= 1.0;

if (needsAttention) {
    System.out.println("Flag the message for dispatcher review");
}

Перад параўнаннем з парогавым значэннем код правярае, ці з'яўляецца значэнне карэктным. У LiteTMS ацэнка катэгорыі забяспечвае другую частку правіла: праблема з транспартным сродкам, якая патрабуе ўвагі, таксама кваліфікуецца як тэрміновае апавяшчэнне. Мадэль ацэньвае паведамленне; дадатак вызначае дзеянне. Калі адказ адсутнічае, звычайны працоўны працэс чата працягваецца.

Парогаваe значэнне залежыць ад таго, што адбываецца далей. Для прапановы слупка пры імпарце LiteTMS прымае выбраны слупок з імавернасцю не менш за 0.60; для пропуску перакладу патрабуецца, каб мова чытача была вызначана з імавернасцю не менш за 0.90. Такім чынам, паказчык 0.85 можа падтрымаць прапанову слупка, якую правярае чалавек, але яго недастаткова для пропуску перакладу ў чаце. Кожнае правіла адлюстроўвае наступствы канкрэтнага рашэння.