Големите јазични модели (LLM) можат да „видат“ само ограничено количество текст одеднаш (прозорецот за контекст). Ова функционира за мали задачи, но не и кога базата на знаење опфаќа илјадници страници. Дури и кога прозорецот за контекст е доволен, перформансите сепак може да се намалат поради проблемот со „игла во сено“.
RAG („генерирање збогатено со пребарување“) стана многу вообичаен пристап: одржувате база на знаење (документи, викија, политики, транскрипти итн.), вршите семантичко пребарување за корисничкото барање за да ги пронајдете најрелевантните извадоци преку векторски претставувања, а потоа тие делови, заедно со прашањето, ги внесувате во големи јазични модели (LLM). Ова го ограничува контекстот на моделот и, ако е правилно изведено, може да го подобри квалитетот на одговорите и да ги намали халуцинациите.
pgai е Postgres-проширување со отворен код (и придружни алатки) што помага да изградите работни процеси за „пребарување со ВИ“ врз доверливата база на податоци со отворен код PostgreSQL.
Главната идеја е поголем дел од стандардниот RAG-процес да се префрли во слојот на базата на податоци (внесување → делење → векторизирање → синхронизирање на векторските претставувања), наместо базата да се третира како „само складиште“ за нив.
Првичниот впечаток е дека решението ветува, но штом RAG-процесот стане барем малку посложен, особено во начинот на делење, веќе не е соодветно. Сепак, внимателно ќе го следиме овој проект.
RAG може да се изгради на многу начини. За подетален преглед на различните пристапи, прочитајте Практични примери на приспособени RAG-решенија. Кога квалитетот е важен, можностите за дизајн стануваат изненадувачки сложени, а вообичаениот „стандарден“ пристап главно изгледа вака:
Земете збирка документи.
Поделете ги на делови. Постојат многу начини за тоа (на пр. според пасуси или семантички групи).
Претворете го секој дел во векторско претставување.
Зачувајте ги векторските претставувања во векторска база на податоци (Pinecone, Milvus итн.) или во Postgres преку pgvector.
При барање, пронајдете ги најблиските делови `и внесете ги во големи јазични модели (LLM) (повторно... и ова може да се направи на многу начини).
Во многу технолошки системи, чекорите (1)–(3) се извршуваат надвор од базата, во апликациски код или податочен процес, а базата главно служи за:
чување векторски претставувања
пребарување векторски претставувања
pgai е Postgres-проширување (со отворен код, развиено од Timescale) што се обидува да ја избрише таа граница.
Наместо апликацијата рачно да управува со векторските претставувања, pgai ги претвора во функција на базата на податоци:
Одредувате која табела или кои документи сакате да се векторизираат.
Ги наведувате моделот за векторизација и стратегијата за делење.
pgai управува со сè друго, вклучително и со ажурирањето на векторските претставувања кога се менуваат изворните податоци.
Ветувањето е привлечно:
Помалку наменски поврзувачки код што треба да се одржува.
Полесно одржување на „свежи“ векторски претставувања при промена на изворните документи.
Postgres/pgai управува со повторните обиди, ограничувањата на стапката, неуспешните задачи итн.
Забелешка за читателите: pgai го вклучува pgvector (уште едно многу популарно Postgres-проширување за RAG). pgvector додава векторско складирање и пребарување според сличност во Postgres, а pgai се надоврзува на него за да ги автоматизира чекорите на RAG-процесот, како делење, векторизирање и ажурирање на векторските претставувања.
1) Лесно се поставува и стартува.
Во идеални услови, постапката е прилично едноставна:
Преземете ги Docker-сликите на Timescale (база на податоци + работник).
Внесете го API-клучот од давателот на услугата за векторизација.
Извршете малку SQL за да го дефинирате векторизаторот (односно: што да се векторизира, како да се подели и кој модел да се користи).
Потоа pgai овозможува работникот за векторизација да работи како посебен процес и асинхроно да создава векторски претставувања (на пр. на секои 5 минути или според саканиот распоред).
2) Практично е целиот процес да се одвива „блиску“ до базата на податоци.
pgai може да внесува содржина од табели, но и да вчитува документи од места како S3, а потоа да ги анализира, дели и векторизира. Поддржува и различни формати на текстуални документи, како PDF, Markdown итн.
1) Губите голем дел од контролата (а на RAG понекогаш му е потребна контрола).
RAG-системите со високи перформанси (мерени според квалитетот на одговорите) често бараат приспособени процеси, како:
приспособени правила за делење (според наслови, страници, промени на говорникот итн.)
делење што ги зема предвид метаподатоците (задржување на насловите на деловите, временските ознаки, авторите и видот на документот)
различни стратегии за векторизација за секој вид документ
pgai нуди помала флексибилност за наведеното.
Во моментов има две главни стратегии за делење: делител на текст според знаци и рекурзивен делител според знаци, како и опција без делење. Тоа може да биде доволно за некои случаи, но многу продукциски RAG-системи бараат поголемо приспособување.
Би било одлично ако Timescale вклучи некои од пософистицираните стратегии за делење што ги среќаваме во библиотеки како Chonkie и слично поддржи напредни решенија како контекстуалното пребарување на Anthropic.
2) Првенствено за текст, а не за мултимодални содржини.
Многу интересни RAG-проблеми веќе не се ограничени само на текст:
PDF-документи со дијаграми
снимки од екранот / слики
аудиоснимки
видеоклипови
Дури и ако можете да „извлечете текст“ од овие извори, тоа не е исто што и вистински мултимодален процес за векторизација.
Ако pgai на крајот понуди целосна поддршка за мултимодални модели (вчитување → делење → векторизирање на големи слики, аудио и видео зачувани во S3, со сигурна синхронизација), тоа би било привлечно. Но денес станува збор за процес за векторизација на текст.
3) Ако ви требаат само векторски претставувања, можеби не ви треба pgai.
Ако вашиот процес на внесување веќе е приспособен (или мора да биде), тогаш „векторизирањето делови од текст“ не е најтешкиот дел од RAG. Во таков случај, pgai го решава најлесниот дел од проблемот.
Исто така, ако базата на знаење ретко се ажурира, автоматската синхронизација на векторските претставувања не носи толкава вредност.
Особено добар начин за користење на pgai би бил поставување интерфејс за претворање текст-во-SQL над вашите бази на податоци. Ова може прилично лесно да се постигне со модулот semantic_catalog што го нуди pgai. Едноставно поставете го вака:
Bash
а потоа овозможете му на семантичкиот каталог да ги прочита вашите податочни речници со pgai semantic-catalog create. Ова создава контекст од вашето складиште на податоци, кој изгледа приближно вака:
Plain Text
Овој контекст сега му е достапен на pgai на повеќе начини:
Преку семантичко пребарување:
Ова барање ќе ги врати табелите, функциите и другите објекти што може да бидат релевантни за вашето барање на природен јазик:
Bash
Добивање необработен контекст:
Ова ќе го прикаже необработениот YAML-контекст поврзан со вашето барање на природен јазик:
Bash
Генерирање SQL:
Или можете директно да го генерирате необработениот SQL потребен за одговор на вашето барање. Контекстот од претходниот чекор се испраќа до големи јазични модели (LLM), по што се создава одговор:
Bash
Ако градите релативно едноставен RAG-систем, вреди да го испробате pgai доколку сакате:
Postgres како главен извор на податоци,
минимум поврзувачки код,
векторски претставувања што автоматски остануваат синхронизирани,
брз начин да примените претворање текст-во-SQL врз вашите бази на податоци,
да експериментирате со нови RAG-алатки и Postgres-проширувања.
Веројатно е подобро да почекате со pgai ако на вашиот RAG-процес му треба нешто од следново:
многу приспособена логика за внесување или делење
многу видови документи со различни барања за анализа
мултимодални векторски претставувања
На крајот, иако pgvector очигледно е широко прифатен, не е јасно дали pgai ќе привлече исто ниво на интерес, а со тоа и поддршка (иако постои само околу 18 месеци).
pgai е интересен RAG-пристап што им препушта на базите на податоци поголем дел од рутинската оперативна работа, со што апликацискиот код може да биде поедноставен.
Во моментов, тој е:
употреблив и навистина пријатен за едноставни RAG-поставувања
недоволно флексибилен за поспецифични процеси (особено мултимодални)
Ветува и дефинитивно вреди да се следи неговиот развој.