Արդյոք ժամանակացույցով AI գործակալներին իսկապես պե՞տք է վեկտորային տվյալների բազա

Ժամանակացույցով աշխատող AI գործակալը կարող է ապրել n8n-ում և ամեն առավոտ վեցին արթնանալ, որ գիշերվա աջակցության հարցումները դասավորի, կամ լինել Make-ի սցենար, որը պատրաստում է շաբաթական հաճախորդային հաշվետվությունը։ Վաղ թե ուշ հայտնվում է նույն պատը՝ գործակալն արթնանում է դատարկ և չգիտի, թե երեկ ինչ է եղել։ Հիշողություն տալու ուղեցույցները գրեթե միշտ սկսվում են նույն կերպ՝ վեկտորային տվյալների բազա, embeddings-ի խողովակաշար և ինդեքս, որը պետք է համաժամեցվի տվյալների հետ։

Այս ամենը կառուցելուց առաջ մշակող Abdeljabbar Elassali-ն dev.to-ի վերլուծության մեջ ավելի պարզ հարց է տալիս՝ արդյոք ժամանակացույցով գործակալին իսկապես պետք է վեկտորային տվյալների բազա։ Նրա կարծիքով ավտոմատացման դեպքերի մեծ մասում ազնիվ պատասխանը ոչ է՝ դեռ ոչ, գուցե երբեք էլ։

Որոնման ինդեքսը հիշողություն չէ

Վեկտորային տվյալների բազան պահում է embeddings և վերադարձնում է հարցմանն իմաստով ամենամոտ գրառումները։ Եթե հարցնես, թե որ անցյալ աշխատանքներն են առնչվել վերադարձի վեճերին, այն կգտնի իմաստով նման գրառումներ, նույնիսկ եթե դրանցից ոչ մեկում refund բառը չկա։ Սա օգտակար է, գրում է նա, և հենց դրանով էլ սպառվում է նրա խնդիրը։ Բազան չի որոշում, թե ինչ արժե հիշել, և չի մաքրում հնացած փաստերը. ինչ պահվում է, ինչ է մտնում prompt-ի մեջ և ինչ է ջնջվում, ճարտարապետություն է, որը կառուցվում է նրա շուրջը։

Ինչ է իրականում պետք ժամանակացույցով գործակալին

Աշխատանքի սկզբում գործակալին պետք են աշխատանքի անփոփոխ փաստերը (հաճախորդի անունը, բրենդի տոնը, շեմերը), տեղը, որտեղ կանգ է առել նախորդ աշխատանքը (վերջին մշակված դիմումի ID-ն, կուրսորը), հազվադեպ փոփոխվող նախընտրությունները և սովորած դասերը, օրինակ այն մատակարարը, որի հաշիվները միշտ երկրորդ ստուգում են պահանջում։ Այս չորս կատեգորիաներից երեքը բանալիով որոնում են. գործակալին պետք չէ հաճախորդի անվանը նման մի բան, նրան պետք է հենց անունը։ Նման փաստերը embeddings-ի խողովակաշարով անցկացնելը նշանակում է ամեն ընթերցման համար վճարել embedding-ի կանչի համար և ավելացնել ուշացում։ Նրա կանոնը պարզ է՝ եթե հիշողությունը տեղավորվում է մեկ էկրանում և ամեն հիշում կատարվում է հայտնի բանալիով, վեկտորային բազան ոչինչ չի տալիս։

Երբ նմանությամբ որոնումն արդարացնում է իրեն

Վեկտորները հայտնվում են, երբ արխիվը մեծ է ու չկառուցվածքավորված, իսկ հիշելու հարցը մշուշոտ է։ Elassali-ն տարբերում է վեկտորային որոնումը և առանձին վեկտորային բազան. pgvector-ը արդեն գոյություն ունեցող Postgres-ում ծածկում է գործակալի աշխատանքի մեծ մասը, իսկ Pinecone-ը, Qdrant-ը, Weaviate-ը և Milvus-ը կառուցված են մեծ հարցումների ծավալի, հիբրիդային որոնման և ծանր զտման համար։ Իսկական գործակալային հիշողությունն, ավելացնում է նա, չորս խնդիր ունի՝ պահում, վերականգնում, ընտրություն և հիգիենա, իսկ վեկտորային բազան երկրորդի կեսի միայն մեկ հնարավոր backend-ն է։ Որպես կարճ ճանապարհ նա նշում է Vilix AI-ն. այն MCP-ի միջոցով կապվում է գործիքների հետ և գործակալին ուղեկցում n8n-ում, Make-ում, Claude-ում, Codex-ում, Cursor-ում և OpenClaw-ում, առաջարկում անվճար պլան և 7-օրյա Pro փորձարկում։ Նրա եզրակացությունը՝ սկսիր նրանից, ինչ գործակալն իրականում հարցնում է, և վեկտորային որոնումը ավելացրու միայն այն ժամանակ, երբ մշուշոտ հիշումը չափելի կարիք կդառնա։