Els LLM només poden "veure" una quantitat limitada de text alhora (la finestra de context). Això funciona per a tasques petites, però deixa de funcionar quan una base de coneixement abasta milers de pàgines. Encara que la finestra de context sigui suficient, el rendiment pot disminuir pel problema de "l'agulla en un paller".
La RAG ("generació augmentada per recuperació") s'ha convertit en un patró molt habitual: es manté una base de coneixement (documents, wikis, polítiques, transcripcions, etc.), es fa una cerca semàntica a partir de la consulta de l'usuari per recuperar els fragments més rellevants mitjançant incrustacions i, després, aquests fragments s'envien a l'LLM juntament amb la pregunta. Això limita el context del model i, si es fa bé, pot millorar la qualitat de les respostes i reduir les al·lucinacions.
pgai és una extensió de codi obert per a Postgres (amb eines complementàries) que ajuda a crear fluxos de treball de "recuperació amb IA" sobre PostgreSQL, una base de dades de codi obert de confiança.
La idea principal és traslladar més parts del procés estàndard de RAG a la capa de base de dades (ingesta → fragmentació → incrustació → sincronització de les incrustacions), en lloc de tractar la base de dades com un "simple emmagatzematge" d'incrustacions.
Les primeres impressions són prometedores, però quan el procés de RAG es complica mínimament, sobretot pel que fa als mètodes de fragmentació, deixa de ser adequat. Tot i això, seguirem el projecte de prop.
Hi ha moltes maneres de crear una RAG. Per consultar una anàlisi més extensa dels diversos enfocaments, llegiu Exemples pràctics de solucions RAG personalitzades. Quan la qualitat importa, les possibilitats de disseny són sorprenentment àmplies, però l'enfocament "predeterminat" sol ser aquest:
Agafeu un conjunt de documents.
Dividiu-los en fragments. Hi ha molts mètodes per fer-ho (p. ex., per paràgrafs o agrupacions semàntiques).
Convertiu cada fragment en una incrustació.
Emmagatzemeu les incrustacions en una base de dades vectorial (Pinecone, Milvus, etc.) o a Postgres mitjançant pgvector.
En el moment de la consulta, cerqueu els fragments més propers `i envieu-los a l'LLM (de nou, també hi ha moltes maneres de fer-ho).
En moltes arquitectures, els passos (1)–(3) es duen a terme fora de la base de dades, al codi de l'aplicació o en un procés de dades, i la base de dades s'utilitza principalment per:
emmagatzemar incrustacions
cercar incrustacions
pgai és una extensió de codi obert per a Postgres, desenvolupada per Timescale, que intenta difuminar aquesta frontera.
En lloc de tractar les incrustacions com un element que l'aplicació ha de gestionar manualment, pgai les converteix en una funció de la base de dades:
Definiu quina taula o quins documents voleu incrustar.
Especifiqueu el model d'incrustació i una estratègia de fragmentació.
pgai gestiona la resta, inclosa l'actualització de les incrustacions quan canvien les dades d'origen.
La proposta és atractiva:
Menys codi d'integració a mida que calgui mantenir.
Hauria de ser més fàcil mantenir les incrustacions "actualitzades" quan canviïn els documents d'origen.
Postgres/pgai gestiona els reintents, els límits de freqüència, les tasques fallides, etc.
Nota per als lectors: pgai inclou pgvector, una altra extensió molt popular de RAG per a Postgres. pgvector afegeix a Postgres emmagatzematge vectorial i cerca per similitud, mentre que pgai es basa en aquestes funcions per automatitzar passos del procés de RAG, com ara la fragmentació, la incrustació i l'actualització de les incrustacions.
1) És fàcil de posar en marxa.
El recorregut ideal és força senzill:
Descarregueu les imatges de Docker de Timescale (base de dades + procés de treball).
Proporcioneu la clau de l'API del proveïdor d'incrustacions.
Executeu una mica d'SQL per declarar el vectoritzador (bàsicament: què cal incrustar, com s'ha de fragmentar i quin model s'ha d'utilitzar).
Després, pgai configura un procés de treball del vectoritzador perquè s'executi per separat i generi incrustacions de manera asíncrona (p. ex., cada cinc minuts o amb la freqüència que vulgueu).
2) És pràctic executar tot el procés "a prop" de la base de dades.
pgai pot ingerir contingut de taules i carregar documents des de llocs com S3 per, després, analitzar-los, fragmentar-los i incrustar-los. També pot gestionar diversos formats de documents de text, com ara PDF, Markdown, etc.
1) Es perd molt de control, i la RAG de vegades en necessita.
Els sistemes RAG d'alt rendiment, mesurat segons la qualitat de les respostes, sovint necessiten processos a mida, com ara:
regles de fragmentació personalitzades (per encapçalaments, pàgines, torns de paraula, etc.)
fragmentació que tingui en compte les metadades (conservar els títols de secció, les marques de temps, els autors i el tipus de document)
estratègies d'incrustació diferents per a cada tipus de document
pgai ofereix menys flexibilitat en aquests aspectes.
Actualment hi ha dues estratègies principals de fragmentació: el divisor de text per caràcters i el divisor recursiu de text per caràcters, a més d'una opció sense fragmentació. Això pot ser suficient per a alguns casos d'ús, però molts sistemes RAG en producció necessiten més personalització.
Seria fantàstic que Timescale incorporés algunes de les estratègies de fragmentació més sofisticades que trobem en biblioteques com Chonkie i que també admetés dissenys avançats com la recuperació contextual d'Anthropic.
2) Centrat en el text, no multimodal.
Molts problemes interessants de RAG ja no es limiten exclusivament al text:
PDF amb diagrames
captures de pantalla i imatges
enregistraments d'àudio
clips de vídeo
Encara que se'n pugui "extreure el text", això no equival a un veritable procés d'incrustació multimodal.
Si pgai acaba admetent models multimodals d'extrem a extrem (carregar → fragmentar → incrustar imatges grans, àudio o vídeo emmagatzemats a S3, amb una sincronització robusta), seria molt atractiu. Avui, però, és un flux de treball d'incrustació de text.
3) Si només necessiteu incrustacions, potser no necessiteu pgai.
Si el vostre procés d'ingesta ja és personalitzat, o ho ha de ser, "incrustar fragments de text" no és la part més difícil de la RAG. En aquest cas, pgai resol la part més fàcil del problema.
A més, si la vostra base de coneixement s'actualitza amb poca freqüència, la sincronització automàtica de les incrustacions no aporta tant valor.
Una manera especialment útil d'aprofitar pgai seria desplegar una interfície de text a SQL sobre les vostres bases de dades. Això es pot aconseguir fàcilment amb el mòdul semantic_catalog que ofereix pgai. Només cal configurar-ho així:
Bash
i fer que el catàleg semàntic extregui els diccionaris de dades amb pgai semantic-catalog create. Això genera context a partir del vostre magatzem de dades amb un aspecte semblant a aquest:
Plain Text
Ara pgai pot accedir a aquest context de diverses maneres:
Mitjançant la cerca semàntica:
Aquesta consulta retornarà les taules, les funcions i altres objectes que podrien ser rellevants per a la vostra consulta en llenguatge natural:
Bash
Obtenció del context en brut:
Això mostrarà el context YAML en brut relacionat amb la vostra consulta en llenguatge natural:
Bash
Generació d'SQL:
També podeu generar directament l'SQL en brut necessari per respondre la consulta. El context del pas anterior s'envia a un LLM, que genera la resposta:
Bash
Si esteu creant un sistema RAG relativament senzill, val la pena provar pgai si voleu:
utilitzar Postgres com a font de referència,
un mínim de codi d'integració,
incrustacions que es mantinguin sincronitzades automàticament,
una manera ràpida d'aplicar text-a-SQL a les vostres bases de dades,
experimentar amb eines RAG i extensions de Postgres noves.
Probablement convé esperar abans d'adoptar pgai si el vostre procés de RAG necessita algun dels elements següents:
molta lògica d'ingesta o fragmentació personalitzada
molts tipus de documents amb requisits d'anàlisi diferents
incrustacions multimodals
Finalment, tot i que és evident que pgvector ha tingut una adopció notable, no és clar que pgai generi el mateix nivell d'interès i, per tant, de suport, malgrat que només existeix des de fa uns 18 mesos.
pgai planteja un enfocament interessant de la RAG: permet que les bases de dades assumeixin més tasques operatives rutinàries perquè el codi de l'aplicació sigui més senzill.
Ara mateix:
és útil i realment agradable per a configuracions RAG senzilles
no és prou flexible per a processos més personalitzats, especialment els multimodals
És prometedor i, sens dubte, val la pena seguir-ne l'evolució.