La lucha por la supremacía en IA
Esta publicación se publicó originalmente en The Sequence.
Qué es LangChain
Los Modelos de Lenguaje Grandes (LLMs) son la nueva ola tecnológica. Los gigantes, Google y Microsoft, están entrando en el Coliseo para luchar en la batalla de la IA y hacerse con la corona de las búsquedas. Esta colosal lucha es solo el comienzo del avance de los LLM, y LangChain está aquí para ayudar a impulsarlo aún más. Los LLM por sí solos ofrecen buenas capacidades conversacionales con memoria limitada y una tendencia a alucinar en sus respuestas. Un ejemplo de esta alucinación es cuando le preguntas a ChatGPT: "What are the difficulty levels in Read Dead Redemption"; ChatGPT responderá afirmando que no hay ajustes de dificultad. Esta respuesta es incorrecta, ya que RDR tiene 3 niveles de dificultad establecidos. Debido a que el LLM genera respuestas usando sus pesos, verificar información o proporcionar fuentes es imposible.
¿Qué pasa si queremos que los LLM respondan preguntas y resuman nuestros datos?
¿Qué pasa si queremos la capacidad de proporcionar fuentes de las respuestas?
¿Qué pasa si queremos que los LLM recuerden conversaciones anteriores que están fuera del límite de tokens?
Aquí es donde entra LangChain. LangChain es un marco que te permite encadenar diferentes cálculos y conocimientos con LLM para llevar la utilidad de los LLM aún más lejos. LangChain te permite crear chatbots específicos de dominio, agentes de acción para cálculos específicos, etc.
Qué papel desempeña Milvus
Entonces, ¿dónde entra Milvus? Los LLM solo pueden procesar una cierta cantidad de tokens (alrededor de cuatro caracteres) a la vez, lo que significa que los LLM no pueden analizar un documento grande o una colección de documentos. Para solucionar esto, podemos almacenar todos nuestros documentos en una base de datos, buscar solo los documentos relevantes para la pregunta de entrada y proporcionar esos documentos al LLM para la generación de respuestas. Milvus es perfecto para esto, ya que podemos aprovechar la búsqueda semántica para recuperar documentos más relevantes más rápido. Comenzamos tomando todos los documentos que analizamos y convirtiendo los textos en embeddings. Un beneficio significativo es que podemos usar el LLM original para generar los embeddings, manteniendo en última instancia el "proceso de pensamiento" del LLM en nuestra búsqueda. Con todos los datos incrustados, podemos almacenar el (embedding y texto original) junto con cualquier metadato dentro de Milvus. Luego, cuando llega una consulta, podemos tomar el texto de la consulta, incrustarlo usando el mismo modelo, buscar los textos relevantes y proporcionarlos a nuestro LLM para generar respuestas. Aunque este pipeline suena simple, crearlo puede requerir mucho trabajo. Por suerte, LangChain facilita hacer tal pipeline y ofrece el wrapper VectorStore para bases de datos vectoriales.
Integración
Aquí está la integración en la que trabajé entre Milvus y LangChain.
class VectorStore(ABC):
"""Interface for vector stores."""
@abstractmethod
def add_texts(
self,
texts: Iterable[str],
metadatas: Optional[List[dict]] = None,
**kwargs: Any,
) -> List[str]:
"""Run more texts through the embeddings and add to the vectorstore."""
@abstractmethod
def similarity_search(
self, query: str, k: int = 4, **kwargs: Any
) -> List[Document]:
"""Return docs most similar to query."""
def max_marginal_relevance_search(
self, query: str, k: int = 4, fetch_k: int = 20
) -> List[Document]:
"""Return docs selected using the maximal marginal relevance."""
raise NotImplementedError
@classmethod
@abstractmethod
def from_texts(
cls: Type[VST],
texts: List[str],
embedding: Embeddings,
metadatas: Optional[List[dict]] = None,
**kwargs: Any,
) -> VST:
"""Return VectorStore initialized from texts and embeddings."""
Como se mencionó anteriormente, integrar Milvus en LangChain implica extender la clase VectorStore. Para hacer esto, necesitábamos implementar algunas funciones clave: add_texts(), similarity_search(), max_marginal_relevance_search() y from_text(). El VectorStore de Milvus sigue una canalización simple en la mayoría de los casos de uso. Primero comienza recibiendo una colección de Documents. En la mayoría de los proyectos de LLM, un Document es una clase de datos que contiene el texto original y todos los metadatos que vienen con él. Los metadatos del Document suelen estar basados en JSON, lo que permite un almacenamiento más accesible dentro de Milvus. Una vez que el VectorStore de Milvus consume un Document, incrusta el texto que se encuentra en él utilizando la función de incrustación que se le proporcionó. En la mayoría de los sistemas de producción, estas funciones de incrustación suelen ser servicios LLM de terceros como OpenAI, Cohere, etc. Sin embargo, es posible usar tu modelo siempre que proporciones una función que acepte una entrada de texto y devuelva un vector. En esta etapa de la canalización, LangChain transfiere el control a Milvus mismo. Milvus recibe la incrustación, el texto original y los metadatos, y los almacena en una colección. A medida que más y más de estos documentos entran en la colección, se crean índices para realizar búsquedas más rápidas en todas las incrustaciones almacenadas.
La última etapa de esta canalización es realizar búsquedas de datos relevantes. Cuando un usuario envía una pregunta, el texto y los filtros de metadatos se envían al VectorStore de Milvus. Usando la misma función de incrustación que antes, Milvus incrusta la pregunta y realiza una búsqueda de similitud en sus datos. Milvus ofrece dos tipos de búsquedas como VectorStore: una predeterminada que devuelve los objetos en su orden sin modificar y otra en la que se utiliza el ordenamiento por máxima relevancia marginal. El ordenamiento por máxima relevancia marginal funciona encontrando los ejemplos con las incrustaciones que tienen la mayor similitud coseno con las entradas y luego agregándolos iterativamente mientras los penaliza por su cercanía a ejemplos ya seleccionados.
Integrar Milvus en LangChain tuvo algunos contratiempos, el más destacado fue que Milvus no puede manejar JSON. La falta de soporte para JSON dificultó las cosas debido a la naturaleza de cómo se generan las configuraciones para Milvus. Actualmente, solo hay dos rutas para usar el VectorStore de Milvus: crear un VectorStore sobre una colección de Milvus ya existente o crear un VectorStore basado en el primer documento pasado a Milvus. Si la Collection ya existe, el esquema queda establecido de forma definitiva. Todos los datos que se agreguen deben seguir el esquema al pie de la letra; si falta algún dato o está mal formado, el sistema ignorará la entrada completa.
Del mismo modo, si se agrega algún metadato adicional a un Document después de crear la Collection, ese metadato adicional será ignorado. Esto no se presta a un sistema muy adaptable y da como resultado tener que hacer bastante trabajo adicional limpiando entradas y trabajo adicional creando una nueva colección. Por suerte, en la versión 2.3, Milvus agregará la capacidad de almacenar JSON, simplificando esta integración y cualquier otra futura. Milvus 2.3 está actualmente en beta, así que no dudes en probarlo y proporcionarnos cualquier comentario.
Conclusión
El resultado es una memoria de trabajo y una base de conocimientos para los LLM. Desde que se fusionó la integración, LangChain ha cambiado un poco, incorporando la idea de los Retrievers. Los Retrievers son una forma de conectarse al almacenamiento externo y son la ruta que seguirá LangChain. Debido a la naturaleza de rápido movimiento de este proyecto, el código que se encuentra en Milvus VectorStore podría estar más limpio, y los próximos pasos serán limpiarlo y también añadir esta funcionalidad de retriever. Como se mencionó anteriormente, Milvus no puede manejar un esquema dinámico, lo que hace que lidiar con colecciones prefabricadas e inserciones a las que les faltan datos sea muy difícil. Una vez que Milvus admita metadatos JSON, será el momento de volver y rehacer esta integración.
En general, trabajar en este proyecto ha sido una gran experiencia. La comunidad es amigable, y Harrison es muy activo y servicial. Espero con interés ver las alturas que alcanza el proyecto LangChain.
Sigue leyendo
We spent 8 years making vector databases faster. Then we stopped.
Rarely queried embeddings still need to stay searchable. See how Vector Lakebase enables on-demand vector search without always-on compute costs.
Bringing AI to Legal Tech: The Role of Vector Databases in Enhancing LLM Guardrails
Discover how vector databases enhance AI reliability in legal tech, ensuring accurate, compliant, and trustworthy AI-powered legal solutions.
Proactive Monitoring for Vector Database: Zilliz Cloud Integrates with Datadog
we're excited to announce Zilliz Cloud's integration with Datadog, enabling comprehensive monitoring and observability for your vectorDB deployments.