Հուսալի RAG գիտելիքի բազա կառուցելու համար միայն PDF-ներ վերբեռնելն ու chat պատուհան ավելացնելը բավարար չէ։ Պետք է կառավարել ամբողջ շղթան՝ աղբյուրների մաքրումից և իմաստային հատվածավորումից մինչև retrieval, հղումներ, մուտքի իրավունքներ, գնահատումներ և մարդու ներգրավում։
Փոքր բիզնեսի համար լավ AI գիտելիքի օգնականը պետք է ոչ միայն արագ պատասխանի, այլև ցույց տա՝ ինչ փաստաթղթից է վերցրել պատասխանը, հրաժարվի ենթադրություններից և զգայուն տվյալները հասանելի դարձնի միայն իրավասու աշխատակիցներին։ Ստորև ներկայացված architecture-ը կարելի է նախնական տարբերակով կառուցել 2–4 շաբաթում՝ առանց մեծ տվյալագիտական թիմի։
Ինչպես է աշխատում RAG architecture-ը
Retrieval augmented generation-ը լեզվային մոդելին կապում է ձեր կազմակերպության փաստաթղթերին։ Հարց ստանալուց հետո համակարգը նախ գտնում է համապատասխան հատվածները, ապա մոդելին հանձնարարում է պատասխանել դրանց հիման վրա։
- Փաստաթղթերը ներմուծվում և մաքրվում են։
- Տեքստը բաժանվում է իմաստային հատվածների՝ chunks-ի։
- Յուրաքանչյուր chunk վերածվում է embedding-ի և պահվում vector database-ում։
- Օգտատիրոջ հարցի համար որոնվում են առավել համապատասխան հատվածները։
- LLM-ը կազմում է պատասխան՝ կցելով աղբյուրներն ու հղումները։
- Ցածր վստահության կամ զգայուն հարցը փոխանցվում է մարդուն։
Տեխնիկական հավաքածուն կարող է ներառել OpenAI կամ Anthropic մոդելներ, Pinecone, Weaviate, Qdrant կամ PostgreSQL-ի pgvector ընդլայնումը, իսկ orchestration-ի համար՝ LangChain կամ LlamaIndex։ Փոքր նախագծի դեպքում pgvector-ը հաճախ նվազեցնում է առանձին ենթակառուցվածքի անհրաժեշտությունը։
Ինչու է «վերբեռնել և հարցնել» մոտեցումը ձախողվում
Կեղտոտ աղբյուրներ և հակասող տարբերակներ
Եթե նույն pricing policy-ի երեք տարբերակ կա Google Drive-ում, համակարգը չի կարող ինքնուրույն որոշել՝ որն է գործողը։ Սկանավորված PDF-ների վատ OCR-ը, աղյուսակների կոտրված տողերը և առանց վերնագրերի արտահանումները ևս աղավաղում են որոնումը։
Կամայական chunking
Յուրաքանչյուր 500 նշանից հետո կտրելը կարող է հարցը բաժանել պատասխանից կամ պայմանը՝ բացառությունից։ Չափազանց մեծ chunks-ը բերում են ավելորդ համատեքստ, իսկ շատ փոքրերը կորցնում են իմաստը։
Հղումների և սահմանների բացակայություն
Առանց հղման աշխատակիցը չի կարող ստուգել պատասխանը։ Եթե մոդելին նաև թույլատրված է լրացնել բացերը ընդհանուր գիտելիքով, համոզիչ ձևակերպված սխալը հեշտ է ընդունել որպես ընկերության քաղաքականություն։
Լավ RAG համակարգը նախ պետք է կարողանա ասել «բավարար աղբյուր չունեմ», հետո միայն՝ գեղեցիկ պատասխանել։
Աղբյուրների մաքրում և կառավարման կանոններ
Սկսեք ոչ թե մոդելից, այլ փաստաթղթերի հաշվառումից։ Նշեք յուրաքանչյուր աղբյուրի սեփականատիրոջը, գործող տարբերակը, թարմացման ամսաթիվը, գաղտնիության մակարդակը և այն թիմերը, որոնց այն հասանելի է։
Գործնական checklist
- Հեռացրեք կրկնօրինակները և արխիվացրեք հնացած տարբերակները։
- PDF, DOCX և Notion էջերը վերածեք կառուցվածքային տեքստի՝ պահպանելով վերնագրերն ու աղյուսակները։
- OCR-ից հետո ձեռքով ստուգեք թվերը, ամսաթվերը և պայմանագրային դրույթները։
- Ավելացրեք metadata՝ բաժին, երկիր, փաստաթղթի տեսակ, սեփականատեր և version։
- Սահմանեք վերանայման պարբերականություն՝ օրինակ՝ pricing-ը ամսական, HR handbook-ը՝ եռամսյակային։
- Կանխեք API keys-ի, գաղտնաբառերի և անձնական տվյալների ինդեքսավորումը։
Որպես non-US founder՝ առանձնացրեք ԱՄՆ բիզնեսի փաստաթղթերը՝ Delaware formation records, հարկային նամակներ, Stripe ընթացակարգեր և բանկային SOP-ներ։ Իրավական կամ հարկային նյութերը նշեք որպես տեղեկատվական աղբյուր, ոչ թե անհատական մասնագիտական խորհրդատվություն։
Chunking, embeddings և retrieval-ի նախագծում
Բաժանեք ըստ կառուցվածքի, ոչ միայն երկարության
Սկսելու համար փորձարկեք մոտ 300–800 token-անոց chunks և 10–20% overlap, բայց դրանք մի ընդունեք որպես համընդհանուր կանոն։ FAQ-ի մեկ հարց-պատասխանը կարող է լինել առանձին chunk, իսկ երկար SOP-ը՝ բաժանվել քայլերի և ենթավերնագրերի հիման վրա։
Յուրաքանչյուր chunk-ի հետ պահեք փաստաթղթի անունը, բաժինը, version-ը, canonical ID-ն և թույլտվությունների metadata-ն։ Դրանք անհրաժեշտ են թե՛ filtering-ի, թե՛ ճշգրիտ citation-ի համար։
Ընտրեք hybrid retrieval
Embeddings-ը լավ են իմաստային նմանության համար, իսկ keyword search-ը՝ ճշգրիտ անվանումների, invoice ID-ների կամ «Form 5472» տիպի հարցումների համար։ Hybrid search-ը համատեղում է երկուսը, իսկ reranker-ը վերադասավորում է թեկնածու հատվածները՝ մինչև LLM-ին ուղարկելը։
| Մոտեցում | Ուժեղ կողմ | Թույլ կողմ |
|---|---|---|
| Keyword search | Ճշգրիտ տերմիններ և կոդեր | Չի հասկանում վերաձևակերպումները |
| Vector search | Իմաստային նմանություն | Կարող է բերել թեմատիկ, բայց ոչ պատասխանող տեքստ |
| Hybrid + reranking | Ավելի հավասարակշռված արդյունք | Ավելացնում է latency և ծախս |
Առաջին տարբերակում որոնեք, օրինակ, 10–20 թեկնածու chunk, reranker-ից հետո մոդելին փոխանցեք լավագույն 3–6-ը։ Վերջնական թվերը ընտրեք ձեր գնահատման տվյալներով, ոչ թե պատահական կանխադրույթով։
Հղումներ, թույլտվություններ և անվտանգ պատասխաններ
Յուրաքանչյուր պնդում կապեք աղբյուրին
Պատասխանի citation-ը պետք է բացի կոնկրետ փաստաթուղթը կամ բաժինը, ոչ միայն ցուցադրի «Source 1»։ Prompt-ում պահանջեք պատասխանել միայն տրամադրված context-ից, նշել հակասող աղբյուրները և չհորինել բացակայող մանրամասներ։
Թույլտվությունը ստուգեք որոնումից առաջ
Role-based access control-ը միայն chat interface-ում կիրառելը վտանգավոր է։ Vector որոնումը պետք է նախապես զտվի ըստ օգտատիրոջ թիմի, դերի և փաստաթղթի գաղտնիության։ Customer support-ի աշխատակիցը չպետք է retrieval արդյունքներում անգամ ստանա payroll կամ board նյութեր։
- Օգտագործեք SSO կամ կազմակերպության հաստատված նույնականացում։
- Պահեք audit log՝ հարց, retrieval արդյունքներ, պատասխան և օգտատեր։
- Mask արեք անձնական և ֆինանսական զգայուն տվյալները։
- Սահմանեք retention policy chat history-ի և logs-ի համար։
Գնահատում, մոնիթորինգ և մարդու միջամտություն
Մինչ գործարկումը հավաքեք 50–100 իրական հարց տարբեր բաժիններից։ Յուրաքանչյուրի համար նշեք ընդունելի պատասխանը, պարտադիր աղբյուրը, թույլատրելի օգտատերերին և այն դեպքերը, երբ օգնականը պետք է հրաժարվի պատասխանել։
Չափեք առանձին փուլերը
- Retrieval recall. Ճիշտ աղբյուրը հայտնվե՞լ է թեկնածուների մեջ։
- Groundedness. Պատասխանի պնդումները հաստատվո՞ւմ են տրված հատվածներով։
- Citation accuracy. Հղումը բացո՞ւմ է պնդումը հաստատող բաժինը։
- Permission safety. Չարտոնված հարցումները վերադարձնո՞ւմ են անվտանգ մերժում։
- Answer usefulness. Կարո՞ղ է աշխատակիցը կատարել հաջորդ քայլը։
Առաջին 2–4 շաբաթվա pilot-ը սահմանափակեք մեկ գործառույթով, օրինակ՝ support SOP-ներով։ Վերանայեք անհաջող հարցերը շաբաթական, իսկ աղբյուրների կամ prompt-ի յուրաքանչյուր փոփոխությունից հետո նորից աշխատեցրեք նույն evaluation set-ը։
Մարդուն փոխանցեք իրավական, հարկային, վճարումների սառեցման, հաշվի հասանելիության և հաճախորդի վեճերի հարցերը։ Escalation-ը պետք է ուղարկի հարցը, գտնված աղբյուրները և conversation summary-ն Slack, Zendesk կամ համապատասխան ticketing համակարգ՝ առանց օգտատիրոջը ստիպելու ամեն ինչ կրկնել։
Գործարկման որոշման պարզ շրջանակ
- Սահմանեք սահմանը. Ընտրեք մեկ թիմ և առավելագույնը 2–3 աղբյուրային համակարգ։
- Կառուցեք baseline. Փորձեք keyword, vector և hybrid retrieval նույն հարցերի վրա։
- Ավելացրեք guardrails. Կիրառեք permissions, citations և «չգիտեմ» պատասխանը։
- Անցկացրեք փակ pilot. Ներգրավեք 5–15 աշխատակից և գրանցեք feedback-ը։
- Ընդլայնեք միայն ապացույցով. Նոր աղբյուր ավելացրեք, երբ retrieval և citation թեստերը կայուն անցնում են։
Ծախսերը բաժանեք չորս մասի՝ փաստաթղթերի մշակում, embeddings և պահեստավորում, retrieval/reranking, LLM պատասխաններ։ Ամսական բյուջեն գնահատեք ձեր փաստաթղթերի ծավալով և հարցումների քանակով. առանց դրանց կոնկրետ դոլարային թիվ խոստանալը մոլորեցնող կլինի։
Հաճախ տրվող հարցեր
RAG-ը վերացնո՞ւմ է hallucination-ը
Ոչ։ Այն նվազեցնում է չհիմնավորված պատասխանների հավանականությունը, եթե retrieval-ը, prompt-ը և citations-ը ճիշտ են, բայց սխալ կամ հնացած աղբյուրը կարող է դեռ սխալ պատասխան տալ։
Արդյո՞ք պետք է fine-tune անել մոդելը
Գիտելիքի հաճախ փոփոխվող բազայի համար սովորաբար նախընտրելի է RAG-ը։ Fine-tuning-ը կարող է օգնել ձևաչափին կամ վարքագծին, բայց այն չի փոխարինում թարմ աղբյուրների retrieval-ին։
Ո՞ր vector database-ն ընտրել
Եթե արդեն օգտագործում եք PostgreSQL և ծավալը փոքր է, սկսեք pgvector-ից։ Առանձին Pinecone, Weaviate կամ Qdrant ընտրեք, երբ պահանջվում են հատուկ scaling, filtering կամ կառավարման հնարավորություններ։
Որքա՞ն հաճախ պետք է թարմացնել ինդեքսը
Կապեք թարմացումը աղբյուրի փոփոխությանը։ Հաճախ փոխվող support և pricing նյութերը կարող են վերաինդեքսավորվել ավտոմատ, իսկ կայուն handbook-ները՝ հաստատված հրապարակումից հետո։
Երբ կարող է օգնել Founder Portal-ը
Founder Portal-ը կարող է օգնել non-US founder-ին կապել RAG օգնականը ԱՄՆ ընկերության գործառնական գործընթացների, Stripe կամ banking workflow-ների և Zapier-ով ավտոմատացումների հետ՝ պահպանելով վերահսկելի escalation-ը։