Spring AI nədir və hansı problemləri həll edir?

Spring AI nədir və hansı problemləri həll edir?

Java servisi HTTP müştərisi ilə dil modelinə sual göndərə bilər. Əsas iş bu çağırışı tətbiqin qalan hissəsinə uyğunlaşdırmaqdır: mesajları hazırlamaq, provayderi seçmək, cavabları emal etmək, sonra isə sənəd və alətləri əlavə etmək. Spring AI bunun üçün abstraksiyalar və Spring Boot inteqrasiyası təqdim edir. Spring AI özünün təlim keçmiş dil modelini təqdim etmir.

1. Modeli tətbiqdən ayır

Böyük dil modeli (LLM) verilən giriş və öyrəndiyi parametrlər əsasında cavab yaradır. Səlis cavab yenə də səhv ola bilər. Hansı məlumatın göndəriləcəyinə, hansı istifadəçinin onu istəyə biləcəyinə və nəticənin necə işlənəcəyinə tətbiq qərar verir. Bu qərarlar Java kodunda və tətbiqin qaydalarında qalır.

Spring Boot servisi başladır və konfiqurasiya edir. Spring AI ChatModel kimi interfeyslər vasitəsilə servisi model imkanlarına bağlayır. Seçilmiş modeli provayder uzaq serverdə və ya sənin idarə etdiyin infrastrukturda işlədir. Starter inteqrasiyanı konfiqurasiya edir; uzaqdakı modeli JVM-ə endirmir.

Spring AI embedding, vektor saxlancları, alət çağırışları və digər model imkanları üçün də API-lər təqdim edir. Embedding, məsələn, əlaqəli mətnləri tapmaq üçün istifadə edilən ədədi təsvirdir. Bu hissələri tətbiqə lazım olduqca öyrənəcəyik. Spring AI ilə tanışlıq

2. Bir sorğunun keçdiyi yolu izlə

Layihəmizin adı study-coach olacaq. Bu kiçik servis öyrənənlərin Java backend haqqında suallarını cavablandıracaq. Modeldən istifadə edən ilk endpoint bu yolu izləyəcək:

Client -> StudyController -> StudyService -> ChatClient -> ChatModel -> Provider
Client <- JSON response  <- answer text  <- model response            <- Provider

StudyController HTTP müqaviləsinə və giriş məlumatının yoxlanmasına cavabdehdir. StudyService modelə göndərilən sorğunu hazırlayır. ChatClient tətbiq kodu üçün ardıcıl metod çağırışları ilə işləyən API təqdim edir, ChatModel implementasiyası isə provayder inteqrasiyasını idarə edir. Provayderin cavabı öz JSON cavabımızın daxilində mətn kimi geri qayıdır.

Ortaq API quruluşu təkrarlanan inteqrasiya kodunu azaldır, amma provayderlər bütün detallarda bir-birini əvəz etmir. Provayderi dəyişəndə model imkanlarını, parametrləri, qiyməti, gecikməni və xəta davranışını yenə yoxlamaq lazımdır. ChatClient sənədləri

3. İlk funksiyanı kiçik saxla

POST /api/study/questions bu JSON gövdəsini qəbul edir:

{"question":"What is the difference between an interface and a class in Java?"}

Uğurlu HTTP 200 cavabında mətn tipli bir answer sahəsi olur. Mətni provayder yaratdığı üçün əvvəlcədən gözlənilən dəqiq cümlə yoxdur. Sual sahəsi yoxdursa, null-dırsa, boşdursa və ya həddən uzundursa, model çağırılmadan HTTP 400 qaytarılır. Sualı Java sətir uzunluğunun 2 000 vahidi ilə məhdudlaşdıracağıq. Bunlar UTF-16 kod vahidləridir. Bu hədd nə token sayını, nə də bütöv HTTP sorğusunun ölçüsünü məhdudlaşdırır.

Token modelin mətni emal etmək üçün istifadə etdiyi vahiddir; sözün bir hissəsi və ya durğu işarəsi ola bilər. Token sayı modeldən və mətndən asılıdır. Qısa sətir sabit xərc və ya sabit kontekst ölçüsü demək deyil. Provayder istifadəsini qiymətləndirəndə həm giriş, həm də çıxış nəzərə alınmalıdır.

4. İlk versiyanın nəyi cavablandıra bildiyini bil

İlk versiya tədris köməkçisi üçün təlimatları system mesajında, sualı isə bir user mesajında göndərir. System mesajı davranışı istiqamətləndirir; giriş hüquqlarını yoxlamır və faktların düzgünlüyünə zəmanət vermir. Bu mərhələdə servisin kurs sənədləri, axtarışı, söhbət saxlanması və alətləri yoxdur.

Qapalı kurs fəslini xülasə etməyi istəmək həmin fəsli model üçün əlçatan etmir. “Buna başqa nümunə göstər” kimi növbəti sual da əvvəlki sorğuları avtomatik daşımır. Söhbət kontekstini açıq şəkildə əlavə edənə qədər hər sorğu müstəqildir.

Sonrakı modullar eyni layihəni genişləndirəcək: qiymətləndirmə cavab keyfiyyətini yoxlayacaq, prompt-lar təlimatları təşkil edəcək, RAG uyğun sənəd parçalarını tapacaq, yaddaş seçilmiş əvvəlki mesajları əlavə edəcək, alətlər isə icazə verilmiş əməliyyatlara bağlanacaq. RAG kontekst təqdim edir, amma yenə də düzgün cavaba zəmanət vermir. Qapalı məlumat modelə çatmamış giriş hüquqları yoxlanmalıdır.

5. Uzaq asılılığı nəzərə al

Uzaqdakı modelə çağırış vaxt apara, uğursuz ola və xərc yarada bilər. İlk endpoint sinxrondur: sorğu modelin cavabını gözləyir. Tətbiqin davranışını testdə modeli əvəz edən obyektlə yoxlayacağıq, real provayder yoxlamasını isə ayrıca addım kimi aparacağıq. Mock testinin keçməsi cavab keyfiyyətini, provayderə bağlantını və hesabın icazələrini təsdiqləmir.

Bu, 127.0.0.1 ünvanında işləyən lokal tədris tətbiqidir. Hələ istifadəçi autentifikasiyası yoxdur. Yayımlamadan əvvəl giriş nəzarəti, istifadə limitləri, vaxt məhdudiyyətləri, xəta cavabları və əməliyyatların müşahidəsi hazırlanıb yoxlanmalıdır. Prompt mətni bu nəzarəti tətbiq edə bilməz. Məşq suallarında giriş açarları və qapalı kurs/istifadəçi məlumatları göndərmə.

6. Kodu yazmazdan əvvəl dizaynı yoxla

Tapşırıq: bu tələblərin tətbiqə, yoxsa modelə aid olduğunu müəyyən et: boş sualı rədd etmək, irsiliyi izah etmək, ödənişli fəslə giriş hüququnu yoxlamaq və answer sahəsi olan düzgün JSON qaytarmaq. Sonra provayder əlçatmaz olanda nə baş verdiyini izah et.

Cavabın yoxlanması: Java validasiyası boş girişi rədd edir; model izahın mətnini hazırlayır; tətbiqin icazə yoxlaması fəslə girişi idarə edir; Spring-in JSON serializasiyası cavab obyektini yazır. Provayder çağırışı uğursuz olanda bunu boş, amma uğurlu cavab kimi təqdim etmək olmaz. Giriş modulundakı implementasiyada tutulmayan provayder xətalarının çoxu HTTP 500 ilə nəticələnir; production üçün xəta təsnifatını sonra əlavə edəcəyik.

Sualın provayderə qədər keçdiyi yolu, hansı qərarların Java-da qaldığını və inandırıcı cavabın niyə yenə qiymətləndirilməli olduğunu izah edə bilirsənsə, layihəni qurmağa hazırsan.