---
title: Jev AI სისტემა LiteTMS-ში: სად დავნერგეთ ხელოვნური ინტელექტი
description: გაიგეთ, როგორ ეხმარება TypeSafe-ის Jev AI მოდელი LiteTMS-ს მძღოლის შეტყობინებების, ლოკაციებისა და იმპორტის შეფასებაში JSON და Java მაგალითებით.
slug: where-jev-helps-in-litetms
locale: ka
date: 2026-09-24
updated: 2026-09-25
category: technology
tags: jev, ai, transport, driver-chat, data-import
author: LiteTMS Team
draft: false
---

ჩვენ LiteTMS-ის რამდენიმე სამუშაო პროცესში ჩავაშენეთ Jev - ხელოვნური ინტელექტის მოდელი კომპანიისგან [TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=litetms.eu). მას შეუძლია შეამჩნიოს მძღოლის შეტყობინებები, რომლებიც ყურადღებას მოითხოვს, გადაამოწმოს, აღნიშნავს თუ არა ორი განსხვავებული ტოპონიმი ერთსა და იმავე ქალაქს, შემოგთავაზოთ იმპორტის ფაილის წაკითხვის ვარიანტი და თავიდან აგარიდოთ იმ შეტყობინების თარგმნა, რომელიც ისედაც ადრესატის ენაზეა დაწერილი. ეს არის მცირე შეფასებები სატრანსპორტო მართვის სისტემაში (TMS) და არა ახალი ჩატ-ასისტენტი ოფისისთვის.

თუ ეს სახელი თქვენთვის უცნობია, [ჩვენი პირველი სტატია Jev-ის შესახებ](/en/blog/jev-ai-decisions-transport) მის არსს განმარტავს. ტექსტის გენერატორი ხელოვნური ინტელექტი პასუხობს მოთხოვნას (prompt). Jev კი შექმნილია უფრო კონკრეტულ კითხვაზე პასუხის გასაცემად, მაგალითად: „საჭიროებს თუ არა ეს შეტყობინება პასუხს?“ შემდეგ LiteTMS ამ შეფასებას შესაბამის სამუშაო პროცესში იყენებს.

## მძღოლის შეტყობინებები, რომლებიც განსაკუთრებულ ყურადღებას იმსახურებს

მძღოლმა შეიძლება გამოაგზავნოს რუტინული სტატუსი, დასვას შეკითხვა ან შეგატყობინოთ პრობლემის შესახებ. ოფისს არ უნდა უწევდეს თითოეული შეტყობინების ერთნაირი სისწრაფითა და პრიორიტეტით განხილვა. მძღოლის ჩატში ჩვენ დავამატეთ Jev-ის შემოწმება, რომელიც შემოსულ შეტყობინებებს თემატიკის მიხედვით ახარისხებს და აფასებს, სჭირდება თუ არა დისპეტჩერს რეაგირება. მას შეუძლია იმუშაოს როგორც წერილობით შეტყობინებებთან, ასევე ხმოვან ჩანაწერებთან მათი ტექსტად გარდაქმნის შემდეგ.

მაგალითად, „სატვირთოს საბურავი გაუსკდა“ და „ადგილზე ვარ“ სრულიად განსხვავებული შინაარსისაა. შეტყობინება, რომელიც შეფასებულია, როგორც რეაგირების მომთხოვნი, შეიძლება გამოჩნდეს ყურადღების ცენტრის პანელზე, ხოლო სატრანსპორტო საშუალების გაუმართაობამ შეიძლება გადაუდებელი შეტყობინებაც გამოიწვიოს. ოფისს კვლავინდებურად შეუძლია მიმოწერის წაკითხვა, პასუხის გაცემა და საკითხის მოგვარებულად მონიშვნა. Jev არ უგზავნის პასუხს მძღოლს და არ წყვეტს, თუ როგორ უნდა მოგვარდეს გაუმართაობა.

გახვრეტილი საბურავის შესახებ შეტყობინების შემთხვევაში, ხელოვნური ინტელექტის შეფასება JSON ფორმატში ასე გამოიყურება:

```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-ის შემოწმება ამ კონკრეტული შემთხვევისთვის შეკვეთების AI-დამუშავებისას და CMR დოკუმენტებში ადგილმდებარეობის გადამოწმებისას.

შეკვეთის რეგისტრაციისას მას შეუძლია შემოთავაზებულ ლოკაციებს შორის არჩევანის გაკეთება ან საეჭვო შესაბამისობის გადასამოწმებლად დატოვება. CMR-ის შემოწმებისას, ერთი და იმავე ქალაქის მაღალი ალბათობით დადასტურებამ შეიძლება მოხსნას *ლოკაციის სახელწოდების შეუსაბამობა*, რომელიც სხვა შემთხვევაში დაფიქსირდებოდა. ცალკე AI ეტაპი კითხულობს დოკუმენტს, ხოლო Jev აფასებს, ემთხვევა თუ არა პუნქტების სახელწოდებები ერთმანეთს.

ქალაქების ორი სახელწოდებისთვის შეფასება შეიძლება ასე გამოიყურებოდეს:

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

ერთი და იმავე ქალაქის მაღალ ქულას შეუძლია პუნქტის სახელწოდების შეუსაბამობა მოხსნას. CMR-ის შემოწმების სხვა ნაწილები კვლავ დამოუკიდებელი რჩება.

## უცნობი სვეტის სათაურების მქონე იმპორტის ფაილები

ახალ სისტემაში მონაცემების გადატანა ხშირად ელექტრონული ცხრილით იწყება. ერთ ფაილში მითითებულია „სარეგისტრაციო ნომერი“, მეორეში - „სახელმწიფო ნომერი“, მესამეში კი ისეთი სათაურებია, რომელთა ამოცნობაც რთულია. LiteTMS ჯერ შესაბამისობის სტანდარტულ წესებს იყენებს. იქ, სადაც ეს წესები საკმარისი არ არის, Jev-ს შეუძლია შესთავაზოს, რა ტიპის ჩანაწერებს შეიცავს ფაილი და რომელი სვეტები რომელ ველებს შეესაბამება.

ეს რეკომენდაციები მონიშნულია როგორც AI-დახმარება, ხოლო მომხმარებელს, რომელსაც ფაილი შემოაქვს, ჩანაწერების შექმნამდე შეუძლია გადახედოს ველების შესაბამისობას. ეს მიდგომა ჩვენ დავუკავშირეთ როგორც იმპორტის ზოგად მასტერს, ასევე CRM გარიგებებისა და ტვირთების იმპორტს. მსგავს შემოწმებას ასევე შეუძლია კონტრაგენტების სიაში უკვე არსებული კომპანიის ამოცნობა სახელწოდების განსხვავებული მართლწერის მიუხედავად, რაც საკმარისი დამთხვევისას დუბლირებული ჩანაწერების თავიდან აცილებაში გვეხმარება.

ვთქვათ, ავტოპარკის იმპორტირებულ ცხრილში სახელმწიფო სანომრე ნიშნებისთვის გამოყენებულია „Unit ref.“, ხოლო კომპანიის შიდა სატრანსპორტო კოდებისთვის - „Internal ID“. სანიმუშო მნიშვნელობები Jev-ს ეხმარება მათ ერთმანეთისგან გარჩევაში. როდესაც სათაურების სტანდარტული წესები რეგისტრაციის ველს ცარიელს ტოვებს, შეფასება შეიძლება ასე გამოიყურებოდეს:

```json
{
  "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“, რაც ნიშნავს: „ადგილზე ვარ, დატვირთვას ველოდები“. პოლონურენოვანი მკითხველისთვის შემოწმებამ შესაძლოა შემდეგი შეფასება აჩვენოს:

```json
{
  "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-ის სახელმძღვანელოში](https://docs.typesafe.ai/introduction/quickstart?utm_source=litetms.eu) არის ნაჩვენები, მოთხოვნა შეიცავს `state`-ს, ანუ შესაფასებელ ინფორმაციას, და `questions`-ს - გასაკეთებელ შეფასებებს. `noul` ტიპის შეკითხვა აბრუნებს რიცხვს 0-დან 1-მდე, რაც დებულების სისწორის ალბათობას გამოხატავს. `choice` ტიპის შეკითხვა ირჩევს ჩამოთვლილი ვარიანტებიდან, რითაც ჩვენ შეტყობინების კატეგორიას ვადგენთ.

აქ წარმოდგენილია მოქმედების საჭიროების შეკითხვა ცალკე, მოდელის იმ იდენტიფიკატორით, რომელიც ჩვენს OpenRouter ინტეგრაციაშია კონფიგურირებული:

```json
{
  "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."
    }
  }
}
```

პასუხის შესაბამისი ნაწილი შესაძლოა ასე გამოიყურებოდეს:

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

აპლიკაცია კითხულობს `answers.needs_action.noul`-ს და იყენებს წესს. LiteTMS იყენებს მოქმედების ზღვრულ მნიშვნელობას `0.55`-ს მძღოლის შეტყობინებაზე ყურადღების მისაქცევად. JSON-ის დეკოდირების შემდეგ, იგივე შემოწმება Java-ში ასე შეიძლება დაიწეროს:

```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-ში კატეგორიის შეფასება წესის მეორე ნაწილს განსაზღვრავს: სატრანსპორტო საშუალების პრობლემა, რომელიც ყურადღებას მოითხოვს, ასევე კვალიფიცირდება როგორც გადაუდებელი შეტყობინება. მოდელი აფასებს შეტყობინებას, ხოლო აპლიკაცია განსაზღვრავს მოქმედებას. თუ პასუხი არ არის მიღებული, ჩატის ჩვეულებრივი პროცესი გრძელდება.

ზღვრული მაჩვენებელი დამოკიდებულია იმაზე, თუ რა ნაბიჯი მოსდევს მას. იმპორტის სვეტის შეთავაზებისთვის LiteTMS იღებს შერჩეულ სვეტს არანაკლებ `0.60` ალბათობით; თარგმანის გამოტოვება კი მოითხოვს, რომ მკითხველის ენა შერჩეული იყოს მინიმუმ `0.90` ალბათობით. ამიტომ, `0.85` ქულა საკმარისია სვეტის შესათავაზებლად, რომელსაც ადამიანი გადაამოწმებს, მაგრამ არასაკმარისია ჩატის თარგმნის გამოსატოვებლად. თითოეული წესი ასახავს კონკრეტული გადაწყვეტილების შედეგს.

## FAQ

### ვინ შექმნა Jev AI?

TypeSafe AI-მ შექმნა Jev, როგორც System One მოდელი სტრუქტურირებული გადაწყვეტილებებისთვის. LiteTMS მას აინტეგრირებს კონკრეტულ პროცესებში, როგორიცაა მძღოლის შეტყობინებების შეფასება და პუნქტების დასახელებების შედარება.

### რისთვის გამოიყენება Jev AI LiteTMS-ში?

Jev დაკავშირებულია მძღოლის შეტყობინებების დახარისხებასთან, შეკვეთის მიღებისას ერთი და იმავე ქალაქის შემოწმებასთან და CMR-ში პუნქტების შედარებასთან, იმპორტის შეთავაზებებთან და ჩატის თარგმნამდე ერთი და იმავე ენის შემოწმებასთან. პლატფორმისა და კომპანიის პარამეტრები განსაზღვრავს, გააქტიურებულია თუ არა კონკრეტული ფუნქცია სამუშაო გარემოში.

### პასუხობს თუ არა Jev მძღოლებს ან ამტკიცებს თუ არა CMR დოკუმენტებს?

არა. მას შეუძლია მძღოლის შეტყობინება მონიშნოს ყურადღების მისაქცევად და შეაფასოს, აღნიშნავს თუ არა ორი განსხვავებული დასახელება ერთსა და იმავე ქალაქს. შეტყობინებას ამუშავებს ადამიანი, ხოლო ერთი და იმავე ქალაქის დადასტურება არ ამოწმებს მთლიან CMR დოკუმენტს.

### რა ხდება, თუ Jev-ის შეფასება გაურკვეველია ან სისტემა მიუწვდომელია?

LiteTMS ინარჩუნებს არსებულ სამუშაო პროცესს. მაგალითად, ენის გაურკვეველი შემოწმების შემთხვევაში გამოიყენება ჩატის თარგმნის სტანდარტული გზა, ხოლო იმპორტის გაურკვეველი შეთავაზებისას სვეტების შესაბამისობას ადამიანი გადაამოწმებს.