Sari la conținut
← Construiește un AI Assistant pentru business
Progres curs 0 / 8 lecții (0%)

Arhitectura unui asistent util

Lectură estimată: 4 minute

Estimare pentru text, la un ritm de 180 de cuvinte pe minut. Timpul pentru analizarea codului, exerciții și proiecte se adaugă separat și depinde de ritmul tău.

Problema pe care o vei rezolva: Asistent care răspunde numai din documente

Document fictiv D1: program luni–vineri 09–17. D2: retururile sunt analizate individual; nu există termen promis. Întrebări: programul de sâmbătă, o rambursare garantată și o solicitare de schimbare a adresei clientului.

Rezultatul urmărit

Construiește un tabel întrebare–sursă–răspuns–acțiune permisă. Definește contractul unei unelte de consultare și separă-l de orice unealtă care modifică date.

Cum recunoști o soluție corectă

Asistentul nu inventează programul de sâmbătă sau termenul rambursării. Schimbarea adresei cere autentificare și autorizare pe server. O citare a D2 nu justifică o promisiune absentă din D2.

Parcurge lecțiile în ordine și păstrează exercițiile în registrul descărcabil. Ultima lecție include atelierul de 40 de minute în care combini conceptele și testezi o variație a situației inițiale. Exemplele comerciale sunt fictive; nu reprezintă rezultate ale unor clienți.

Un asistent AI util pentru un business nu e „un chatbot care știe tot". E un sistem îngust, care răspunde bine la un set clar de întrebări pe baza documentelor tale, știe când nu știe și predă cazul unui om când e nevoie. Lecția asta e despre arhitectura de bază, înainte de orice cod.

Componentele

  • Baza de cunoștințe: documentele din care răspunde (FAQ, politici, fișe de produs, proceduri).
  • Recuperarea (retrieval): găsirea fragmentelor relevante pentru o întrebare.
  • Modelul: primește întrebarea + fragmentele și formulează răspunsul.
  • Promptul de sistem: rolul, tonul, regulile, ce are voie și ce nu.
  • Escaladarea: calea prin care un caz ajunge la om.
  • Jurnalizarea și măsurarea: ce s-a întrebat, ce s-a răspuns, a fost bun?

De ce „îngust" e mai bun

Un asistent care încearcă să răspundă la orice va greși des și imprevizibil. Unul care acoperă „întrebări despre comenzi, livrare, retururi și produse" poate fi făcut fiabil. Definește domeniul explicit și fă-l să refuze politicos ce e în afara lui.

Ce decizi înainte de a construi

  • Ce întrebări trebuie să acopere (fă o listă reală din istoricul de suport).
  • Ce nu atinge niciodată (prețuri negociate, date personale, promisiuni).
  • Unde trăiește: pe site, în chat, intern pentru echipă?
  • Cum arată succesul: % de întrebări rezolvate fără om, satisfacție.

Exercițiu

Ia ultimele 100 de întrebări primite la suport. Grupează-le. Ce procent ar putea fi acoperit de un asistent îngust bazat pe documentele tale? Aceea e ținta realistă.

Greșeli frecvente

  • Ținti un asistent „care știe tot" în loc de unul îngust și fiabil.
  • Nu definești explicit ce e în afara domeniului.
  • Nu ai o listă reală de întrebări pe care trebuie să le acopere.
  • Nu definești de la început cum măsori succesul.

De reținut

  • Asistent util = îngust, bazat pe documentele tale, cu escaladare.
  • Componente: bază de cunoștințe, retrieval, model, prompt de sistem, escaladare, măsurare.
  • Definește domeniul și fă-l să refuze politicos restul.
  • Pornește de la întrebările reale din istoricul de suport.

Pe scurt

Proiectează întâi: ce acoperă, ce nu, unde trăiește, cum măsori. Un asistent îngust și bine definit bate unul ambițios și imprevizibil.

Arhitectură cu granițe între răspuns și acțiune

Un asistent util separă interfața, căutarea în documente, generarea răspunsului și acțiunile cu efect. Nu da modelului acces direct și nelimitat la baza de date. Pentru întrebări despre program, răspunsul poate cita un document aprobat. Pentru modificarea unei comenzi, serverul verifică identitatea, dreptul de acces și confirmarea necesară. Instrucțiunea din prompt nu este un înlocuitor pentru autorizarea executată de aplicație.

Exemplu de lucru

Flux: mesaj → validare → identificare intenție → căutare autorizată → răspuns cu sursă.
Acțiune: propunere → verificare server → confirmare → execuție → jurnal.
Documente publice: program, servicii.
Documente private: acces numai conform utilizatorului.
Fallback: nu există sursă suficientă → clarificare sau operator.

Interpretarea rezultatului

Un răspuns corect despre o comandă a altui client rămâne o încălcare de acces. Testează granițele înainte de stilul conversației. Pentru un prototip, începe numai cu documente publice și fără acțiuni externe, apoi adaugă funcții controlat.

Exercițiu de consolidare

Descrie ce verificări sunt necesare înainte de a permite schimbarea unei adrese de livrare.

Aplicație practică

Sarcina

Desenează un asistent cu bază de cunoștințe și transfer la om.

Rezolvare orientativă și verificare

Separă interfața, căutarea, modelul, uneltele și jurnalul. Exemplul AsistAi din portofoliu este context public, nu benchmark verificat.

Greșeală de evitat

Nu trimite cheia API în JavaScript-ul livrat browserului.

Documentație și surse

Ți-a plăcut lecția? Continuă cursul complet

Ai citit o lecție gratuită. Celelalte lecții, aplicațiile practice și materialele se deblochează odată cu cursul.

299 lei

Plată unică, acces pe viață la toate cele 8 lecții.

Vezi ce conține cursul →

Folosim cookie-uri esențiale pentru funcționarea site-ului și, cu acordul tău, cookie-uri de analiză și publicitate. Partenerii noștri, inclusiv Google, pot folosi cookie-uri pentru a afișa reclame relevante. Detalii în Politica de cookie-uri.