O bază de cunoștințe pentru Claude care răspunde corect din documentele tale

O bază de cunoștințe pentru Claude este setul de documente, proceduri și conexiuni la date din care Claude își ia răspunsurile despre firma ta. Ca să răspundă corect, are nevoie de trei lucruri. Documentele trebuie să fie scurte și la zi. Datele se citesc direct din sisteme precum Zoho CRM. Răspunsurile se verifică pe un set de întrebări de test înainte de lansare.

Claude nu știe nimic despre prețurile, procedurile sau clienții tăi. Anthropic recomandă Claude Opus 5.5 pentru majoritatea sarcinilor. Cunoștințele lui generale sunt de încredere până în iunie 2026, conform paginii oficiale cu prezentarea modelelor Claude. Tot ce ține de firma ta trebuie deci să vină din baza de cunoștințe.

Când baza de cunoștințe are goluri, modelul le umple cu ce pare plauzibil. Așa apar răspunsurile inventate. Un termen de retur „tipic” sau o procedură „obișnuită” sună corect, dar nu e a ta. Soluția nu ține de model. Ține de ce documente îi dai, în ce formă și cât de des le verifici.

Ghidul acesta merge prin fiecare pas. Mai întâi alegi documentele și le scrii într-o formă ușor de citit. Apoi conectezi datele live din Zoho și împachetezi procedurile. La final testezi răspunsurile înainte ca echipa să se bazeze pe ele.

În baza de cunoștințe pentru Claude intră doar documentele pe care echipa le folosește deja ca referință oficială. Criteriul e simplu. Dacă un om nou ar primi documentul în prima zi și l-ar aplica fără întrebări, documentul intră.

Documentele care intră de obicei sunt acestea:

• proceduri operaționale: retur, garanție, escaladare, predare între ture;
• politici comerciale: condiții de plată, reduceri permise, cine aprobă ce;
• șabloane de răspuns către clienți, cu tonul firmei;
• întrebări frecvente interne, cu răspunsul validat de cineva anume;
• fișe de produs sau de serviciu care nu se schimbă de la o zi la alta.

Rămân afară ciornele, versiunile vechi și documentele „de lucru”. Fiecare fișier în plus e o șansă ca Claude să citeze o regulă care nu mai e valabilă. Rămân afară și datele personale ale clienților. Acestea se citesc la nevoie din sistem, cu acces controlat, nu se copiază în documente.

Tot afară rămân datele care se schimbă des: stocul, statusul comenzilor, prețurile curente din CRM, istoricul unui client. Un document cu prețurile de luna trecută produce răspunsuri greșite cu toată siguranța. Pentru asemenea date există o altă cale, conexiunea live, descrisă mai jos.

Regula de bază: un singur document valabil pentru fiecare subiect. Dacă ai două proceduri de retur, alegi una înainte de orice altceva.

Forma documentului decide cât de ușor găsește Claude regula corectă. Un document scurt, despre un singur subiect, cu regula scrisă explicit, dă răspunsuri mai sigure decât un manual de o sută de pagini.

Un subiect pe fișier

Procedura de retur stă într-un fișier, garanția în altul. Numele fișierului spune ce conține, de exemplu retur-produse.md. Primul paragraf enunță regula. Excepțiile vin după, fiecare sub titlul ei.

Antet cu dată și proprietar

Fiecare document începe cu data ultimei actualizări și numele persoanei care răspunde de el. Proprietarul este omul pe care îl întrebi când regula nu mai pare corectă. Fără proprietar, nimeni nu actualizează documentul.

Text, nu scanări

Toate modelele Claude actuale citesc și imagini. Totuși, un PDF scanat cu un tabel strâmb e greu de verificat de un om. Text simplu cu titluri, de pildă în format Markdown, se citește și se corectează ușor.

Aceiași termeni peste tot

Dacă în vânzări spui „ofertă”, iar în contabilitate „proformă” pentru același lucru, scrie asta explicit. Un glosar scurt, pus lângă proceduri, evită confuziile. Scrie și excepțiile clar: „nu se aplică pentru produsele la comandă”. Ce nu e scris, Claude nu are de unde ști.

Datele care se schimbă zilnic în Zoho se citesc live, în momentul întrebării, printr-o conexiune MCP. Model Context Protocol (MCP) este un standard open source prin care Claude se conectează la instrumente și surse de date externe. Documentația Anthropic despre conectarea Claude la instrumente prin MCP spune că se pot lega sute de instrumente astfel.

Avantajul e direct. Dacă un preț se schimbă azi în CRM, răspunsul de azi îl folosește. Nu mai există un document cu prețuri care trebuie ținut în paralel. Același principiu stă în spatele unui raport zilnic de KPI cu Claude pentru manageri, construit din datele Zoho.

Câteva reguli din documentația Anthropic contează la configurare:

• serverele HTTP sunt opțiunea recomandată pentru serverele MCP la distanță;
• transportul SSE este depreciat și e bine evitat;
• Claude Code afișează un avertisment când rezultatul unui instrument MCP depășește 10.000 de tokeni;
• implicit, rezultatul unui instrument MCP e limitat la 25.000 de tokeni.

Limita de rezultat are o consecință practică. Claude trebuie să ceară înregistrări filtrate, nu un modul întreg. O întrebare despre un client citește fișa clientului, nu toate contactele din CRM.

La început, conexiunea poate fi folosită doar pentru citire. Scrierea în CRM sau în helpdesk vine după ce răspunsurile s-au dovedit corecte o perioadă.

Agent Skills sunt foldere organizate de instrucțiuni, scripturi și resurse care extind ce poate face Claude. Pentru o bază de cunoștințe, un Skill e un mod ordonat de a împacheta procedurile unei echipe. Detaliile vin din ghidul Anthropic despre Agent Skills.

Un Skill are în rădăcină un fișier SKILL.md. Acesta începe cu un antet YAML care conține numele și descrierea. Lângă el stau documentele de procedură și eventualele scripturi. Limitele de care ții cont sunt acestea:

• numele are maximum 64 de caractere, doar litere mici, cifre și cratime;
• descrierea are maximum 1024 de caractere, nu e goală și nu conține etichete XML;
• toate fișierele unui Skill, necomprimate, au maximum 30 MB;
• o cerere poate folosi maximum 20 de Skills.

Descrierea decide când e folosit Skill-ul. Claude vede numele și descrierea fiecărui Skill și încarcă instrucțiunile complete doar când are nevoie de ele. O descriere vagă înseamnă că procedura nu e deschisă la momentul potrivit.

O versiune de Skill este o copie completă, nu o diferență. La fiecare încărcare trimiți toate fișierele. Un fișier omis nu e preluat din versiunea anterioară.

Skills rulează într-un container fără acces la rețea. Un Skill nu poate deci citi date live din Zoho, iar asta rămâne treaba conexiunii MCP. Diferența dintre Projects și Skills e explicată în ghidul despre Projects și Skills în Claude pentru o echipă mică.

Exemplul de față arată o bază de cunoștințe pentru o echipă de suport care lucrează în Zoho Desk. Procedurile stau într-un Skill, iar tichetele se citesc live prin MCP.

Skill-ul cu procedurile

Skill-ul se numește proceduri-suport-clienti, un nume care respectă regula cu litere mici și cratime. Folderul conține aceste fișiere:

• SKILL.md, cu numele și descrierea;
• retur-produse.md, procedura de retur și excepțiile ei;
• garantie.md, condițiile de garanție;
• escaladare.md, cine preia ce, după tipul problemei;
• sabloane-raspuns.md, formulările aprobate către clienți.

Descrierea din SKILL.md poate fi: „Procedurile echipei de suport pentru retur, garanție și escaladare. Folosește-le când un agent întreabă cum se tratează cererea unui client.” În același fișier scrii o instrucțiune explicită: „Dacă răspunsul nu e în aceste documente, spune că nu ai informația și indică persoana de la escaladare.”

Conexiunea live la tichete

Un server MCP pe HTTP citește din Zoho Desk statusul tichetului și istoricul clientului, doar pentru citire.

O întrebare de la cap la coadă

Un agent scrie: „Clientul din tichetul deschis ieri cere retur după termenul standard. Ce facem?” Claude citește tichetul prin MCP. Apoi deschide retur-produse.md și aplică excepția scrisă acolo. Răspunsul numește documentul folosit, ca agentul să poată verifica. Dacă echipa lucrează în Slack, același flux e descris în ghidul despre Claude în Slack pentru suport intern.

Fiecare tip de conținut are un loc potrivit în baza de cunoștințe pentru Claude. Criteriul principal e cât de des se schimbă conținutul. Tabelul de mai jos rezumă alegerea și felul în care verifici fiecare tip.

Regula care rezultă din tabel e scurtă. Ce se schimbă rar se scrie o dată și se verifică la fiecare modificare. Ce se schimbă des nu se scrie deloc, ci se citește din sistem.

Testarea bazei de cunoștințe se face cu un set fix de întrebări al căror răspuns corect îl știi dinainte. Setul îl scrie proprietarul fiecărui proces, nu cine configurează Claude. El știe unde greșesc de obicei colegii.

Setul de test are trei tipuri de întrebări:

• întrebări al căror răspuns stă într-un document;
• întrebări care cer date live din Zoho, cu răspunsul verificat în sistem;
• întrebări al căror răspuns nu există nicăieri.

Al treilea tip e cel mai important. Răspunsul corect acolo e „nu am informația” plus persoana de contact. Dacă Claude inventează un răspuns la o asemenea întrebare, baza de cunoștințe nu e gata. Scrie întrebările în română, exact cum le pune echipa, cu prescurtări și termeni amestecați.

Rulezi setul înainte de lansare și din nou după fiecare modificare de document. O versiune nouă de Skill poate strica o regulă care mergea înainte.

Aici contează fixarea versiunii. Ghidul Anthropic avertizează: dacă cererea omite versiunea sau folosește „latest”, versiunea încărcată de oricine din workspace schimbă imediat ce rulează agenții în producție. Fixezi deci versiunea testată și o schimbi abia după ce noua versiune trece testele. Dacă ai activat Compliance API, Activity Feed înregistrează crearea și ștergerea Skills și a versiunilor lor. Așa știi cine a schimbat ce.

Bazele de cunoștințe se strică rar din cauza modelului și des din cauza documentelor. La Svennis, înainte să punem documentele în fața lui Claude, cerem un proprietar numit pentru fiecare procedură. Cele mai multe răspunsuri greșite pe care le vedem la clienți vin din proceduri vechi rămase în folder, pe care nu le mai urmărea nimeni.

Problemele care apar cel mai des sunt acestea:

• Două versiuni ale aceleiași reguli. Claude alege una, iar alegerea poate fi cea veche.
• Lipsa instrucțiunii „nu știu”. Fără ea, modelul completează golurile cu ce sună plauzibil.
• Versiunea „latest” în producție. O modificare netestată ajunge direct la echipă.
• Fișiere omise la o versiune nouă de Skill. Versiunea e o copie completă, deci fișierul lipsă dispare.
• Interogări prea largi prin MCP. Rezultatul lovește limita implicită de 25.000 de tokeni și răspunsul se bazează pe date incomplete.
• Conținut extern neverificat. Documentația Anthropic avertizează că serverele MCP care aduc conținut extern pot expune la injecție de prompt.

Injecția de prompt înseamnă text ascuns într-o sursă externă care încearcă să-i dea lui Claude alte instrucțiuni. Pentru o bază de cunoștințe internă, protecția e simplă. Conectezi doar sursele pe care le controlezi.

O firmă din România își poate scrie baza de cunoștințe pentru Claude direct în română. Toate modelele Claude actuale sunt multilingve, conform documentației Anthropic. Nu ai nevoie de traduceri în engleză ale procedurilor.

În practică, documentele românești amestecă termeni. Echipa spune lead, follow-up sau pipeline, dar scrie „ofertă” și „factură”. Glosarul de termeni interni rezolvă confuzia. Folosește diacritice consecvent în documente și în întrebările de test, ca să verifici că răspunsul corect vine și când cineva scrie fără ele.

Datele personale cer o atenție aparte. Ghidul Anthropic spune că Agent Skills nu sunt acoperite de acordurile de zero data retention (ZDR). Definițiile Skills și datele de execuție se păstrează după politica standard de retenție Anthropic. Concluzia practică: nu pui date despre clienți în Skills. Le citești la nevoie din Zoho CRM sau din helpdesk, prin conexiunea MCP.

Contează și locul în care lucrează echipa. Dacă echipa lucrează în Teams și Outlook, baza de cunoștințe poate fi folosită acolo, fără un instrument nou. Pașii sunt descriși în ghidul despre Claude în Microsoft 365 și Teams.

O bază de cunoștințe pentru Claude se construiește pe un singur proces, nu pe toată firma deodată. Alege procesul cu cele mai multe întrebări repetate, de obicei suportul sau vânzările, și urmează pașii de mai jos.

1. Strânge procedurile procesului ales și păstrează o singură versiune valabilă pentru fiecare subiect.
2. Numește un proprietar pentru fiecare document și pune data actualizării în antet.
3. Rescrie documentele: un subiect pe fișier, regula în primul paragraf, excepțiile explicite.
4. Împachetează procedurile într-un Skill cu o descriere clară și cu instrucțiunea „nu știu”.
5. Conectează datele din Zoho prin MCP, doar pentru citire, cu interogări filtrate.
6. Scrie setul de test cu cele trei tipuri de întrebări și rulează-l înainte de lansare.
7. Fixează versiunea testată și rulează testele din nou la fiecare schimbare.

Pasul concret de azi e alegerea locului în care echipa va folosi baza de cunoștințe. Pentru o echipă mică, cel mai util punct de plecare e ghidul despre Projects și Skills în Claude. Acolo vezi cum lucrează toți din aceleași documente și aceleași proceduri.