Големите езикови модели могат да „виждат“ само ограничено количество текст наведнъж (контекстния прозорец). Това работи при малки задачи, но се проваля, когато базата от знания обхваща хиляди страници. Дори когато контекстният прозорец е достатъчен, производителността пак може да спадне заради проблема с „иглата в купа сено“.
RAG („генериране с подпомагане чрез извличане“) се утвърди като много разпространен подход: поддържате база от знания (документи, уикита, правила, транскрипции и др.), извършвате семантично търсене по заявката на потребителя, за да извлечете чрез векторни представяния най-подходящите откъси, а след това ги подавате на големия езиков модел заедно с въпроса. Това ограничава контекста на модела и при правилно изпълнение може да подобри качеството на отговорите и да намали халюцинациите.
pgai е разширение с отворен код за Postgres (заедно със съпътстващи инструменти), което помага за изграждането на работни процеси за „извличане с ИИ“ върху надеждната база данни с отворен код PostgreSQL.
Основната идея е повече от стандартния RAG конвейер да се премести в слоя на базата данни (приемане → разделяне → създаване на векторни представяния → синхронизиране), вместо базата данни да се използва „само като хранилище“ за векторни представяния.
Първоначалните ни впечатления са, че решението е обещаващо, но става неподходящо дори при малко по-сложен RAG конвейер, особено заради подходите за разделяне. Въпреки това ще следим проекта отблизо.
Има много начини за изграждане на RAG. За по-подробен преглед на различните подходи прочетете Практически примери за персонализирани RAG решения. Когато качеството е важно, възможностите за проектиране се оказват изненадващо многобройни, а обичайният подход „по подразбиране“ най-често изглежда така:
Вземете набор от документи.
Разделете ги на фрагменти. Има много различни методи за това (например по абзаци или семантични групи).
Преобразувайте всеки фрагмент във векторно представяне.
Съхранявайте векторните представяния във векторна база данни (Pinecone, Milvus и др.) или в Postgres чрез pgvector.
При заявка намерете най-близките фрагменти `и ги подайте на големия езиков модел (отново... и това може да стане по много начини).
В много технологични стекове стъпки (1)–(3) се изпълняват извън базата данни — в кода на приложението или в конвейер за данни, а базата се използва основно за:
съхраняване на векторни представяния
търсене във векторните представяния
pgai е разширение за Postgres (с отворен код, разработено от Timescale), което се опитва да заличи тази граница.
Вместо приложението ви ръчно да управлява векторните представяния, pgai ги превръща във функция на базата данни:
Определяте за коя таблица или кои документи да се създадат векторни представяния.
Посочвате модела за векторни представяния и стратегията за разделяне.
pgai управлява останалото, включително актуализирането на векторните представяния при промяна на изходните данни.
Обещанието е привлекателно:
По-малко специализиран свързващ код за поддръжка.
Би трябвало да е по-лесно векторните представяния да се поддържат „актуални“ при промяна на изходните документи.
Postgres/pgai управлява повторните опити, ограниченията на честотата, неуспешните задачи и т.н.
Бележка към читателя: pgai включва pgvector (друго много популярно RAG разширение за Postgres). 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 код, необходим за отговор на заявката ви. Контекстът от предишната стъпка се изпраща към голям езиков модел, който генерира отговор:
Bash
Ако изграждате сравнително проста RAG система, струва си да изпробвате pgai, ако искате:
Postgres като основен източник на достоверни данни,
минимално количество свързващ код,
автоматично синхронизирани векторни представяния,
бърз начин за добавяне на преобразуване от текст към SQL към базите ви данни,
да експериментирате с нови RAG инструменти и разширения за Postgres.
Вероятно е по-добре да изчакате с pgai, ако RAG конвейерът ви изисква някое от следните:
силно персонализирана логика за приемане или разделяне
много типове документи с различни изисквания за анализиране
мултимодални векторни представяния
И накрая, макар че pgvector очевидно се използва широко, не е ясно дали pgai ще привлече същия интерес и съответно ще получи същата поддръжка (въпреки че съществува едва от около 18 месеца).
pgai предлага интересен подход към RAG, при който базите данни поемат повече от рутинната оперативна работа, за да остане кодът на приложението по-прост.
В момента решението е:
използваемо и наистина удобно за прости RAG конфигурации
недостатъчно гъвкаво за по-специализирани конвейери (особено мултимодални)
Решението е обещаващо и определено си струва да следим развитието му.