# Cómo encuentra las respuestas tu asistente > Fragmentos, embeddings, top K y todo lo demás, explicado desde cero — y qué cambia realmente cada ajuste. Source: https://welcomeai.dev/es/docs/retrieval-settings Category: Empieza aquí Updated: 2026-09-06 --- Tu asistente no conoce tu negocio. Cada vez que alguien pregunta algo, lee unos cuantos pasajes de tu contenido y responde a partir de ellos. Esta página explica cómo los elige, y qué cambia cada ajuste de la pestaña **Recuperación**. No damos nada por sabido. Si nunca has oído hablar de un embedding, empieza por arriba. ## La versión corta 1. Añades un **documento**. 2. Lo dividimos en **fragmentos**: pasajes de unos pocos párrafos. 3. Cada fragmento se convierte en un **embedding**: una lista larga de números que representa su significado. 4. Alguien hace una pregunta. La pregunta también se convierte en un embedding. 5. Buscamos los fragmentos cuyos números están más cerca de los de la pregunta. Eso es la **recuperación**. 6. Los mejores se le pasan al modelo junto con la pregunta. Responde a partir de ellos, y los cita. Esos seis pasos tienen un nombre con el que te vas a encontrar: **RAG**, siglas en inglés de generación aumentada por recuperación. Es la diferencia entre un asistente que responde a partir de tu contenido y uno que responde a partir de lo que le tocó leer en internet. Todo lo que hay en la pestaña Recuperación ajusta uno de esos pasos. ## Documentos y fragmentos Un **documento** es una cosa que añadiste: un PDF, una página que rastreamos, un artículo de soporte, un par de pregunta y respuesta. Lo que se busca no son los documentos. Un manual de cuarenta páginas trata de unas cuarenta cosas, y devolverlo entero porque un párrafo encajaba enterraría la respuesta. Por eso cada documento se divide en **fragmentos**. El fragmento es la unidad de todo lo que viene después. Es lo que se busca, lo que se recupera, lo que lee el modelo y a lo que apunta una cita. ### Tamaño de fragmento Cuánto texto entra en cada uno, medido en **tokens**: unas tres cuartas partes de una palabra, así que 800 tokens son unas 600 palabras, más o menos una página. - Los **fragmentos grandes** arrastran más de su alrededor. La respuesta ve más contexto, y también más texto que no tenía nada que ver con la pregunta. - Los **fragmentos pequeños** encajan con más precisión. Si son demasiado pequeños, un pasaje pierde el contexto que lo hacía tener sentido: una línea que dice "esto viene incluido en todos los planes" no sirve de nada si no sabes qué es *esto*. 800 es un buen valor por defecto. Bájalo si tu contenido son entradas cortas —FAQ, fichas de producto— y las respuestas suenan rellenas. ### Solape Los fragmentos hay que cortarlos por algún sitio, y una frase puede caer justo en el corte. Entonces no pertenece bien a ninguno de los dos, y ninguno responde la pregunta que contiene a medias. El **solape** repite el final de cada fragmento al principio del siguiente, para que lo que esté cerca de un corte aparezca entero al menos en uno. El precio es la duplicación: el texto que aparece dos veces se guarda dos veces y, si se recuperan los dos fragmentos, se lee dos veces. 120 tokens es un buen valor por defecto. ## Los embeddings, y por qué existen La búsqueda por palabra clave falla con las paráfrasis. Quien pregunta "¿me devuelven el dinero?" no encuentra nada en un documento que dice "los reembolsos se hacen dentro de los 14 días", porque no comparten ninguna palabra. Un **embedding** resuelve eso. Es una lista de números —1.536— producida por un modelo que ha leído muchísimo texto, organizada de modo que los pasajes que significan cosas parecidas obtienen números parecidos. "Los reembolsos se hacen" y "¿me devuelven el dinero?" acaban cerca aunque no compartan ninguna palabra. Guardamos un embedding por fragmento en una **base de datos vectorial** —aquí, PostgreSQL con una extensión que sabe buscar esas listas rápido—. Cuando llega una pregunta se convierte en embedding de la misma manera, y encontrar los fragmentos más cercanos es cuestión de medir distancias. Eso es la **búsqueda por similitud**. > Los dos lados tienen que medirse igual, y por eso cambiar el modelo de embeddings reindexa todo. Los > números de un modelo no significan nada para otro. ## La recuperación La **recuperación** es esa búsqueda, más las decisiones sobre qué conservar. ### Top K Cuántos fragmentos lee el asistente antes de responder. Es el ajuste que más importa, por dos razones. Decide qué probabilidad hay de que el pasaje correcto esté entre ellos, y es **la mayor parte de lo que cuesta una respuesta**, porque cada fragmento es texto que el modelo lee en cada pregunta. - **Más alto**: más probabilidad de que la respuesta esté ahí, y más ruido. Por encima de ocho, las coincidencias flojas suelen estorbar: el modelo tiene que averiguar a cuál de nueve pasajes creer. - **Más bajo**: más barato y más rápido en cada pregunta, y muchas veces mejor. Seis es un buen valor por defecto. Si las respuestas citan cosas que no vienen al caso, bájalo antes de tocar nada más. ### Umbral de similitud La búsqueda por similitud siempre devuelve algo. Pregúntale por el tiempo y te dará igualmente tus tres fragmentos menos ajenos, porque son los más cercanos que existen. El **umbral** es el mínimo: los fragmentos que no se acercan lo suficiente se descartan, aunque fueran los mejores disponibles. Es lo que permite que tu asistente diga "no tengo eso" en lugar de inventarse una respuesta con lo que tuviera más a mano. - **Más alto**: menos fragmentos y mejores; demasiado alto, y se tiran coincidencias reales. - **Más bajo**: entran más, incluidos los que solo lo parecen. 0,30 es el valor por defecto. Parece bajo, y esa es la idea: medido contra preguntas reales, las coincidencias buenas de este producto puntúan entre 0,33 y 0,58, así que un umbral cercano a 0,78 las descarta todas y deja en silencio que la mitad por palabras clave haga todo el trabajo. Si tu asistente responde preguntas que debería haber rechazado, súbelo de a poco y prueba cada paso en el Playground. ## Búsqueda híbrida La búsqueda por significado es mala con las cadenas exactas. Una referencia, un código de error, un nombre: no tienen un significado al que acercarse, simplemente tienen que coincidir. El modo **híbrido** ejecuta las dos: la búsqueda por significado *y* una búsqueda por palabra clave de toda la vida, y luego fusiona ambas clasificaciones. Es el valor por defecto y casi siempre es lo correcto. La búsqueda por palabra clave es también la razón de que exista el ajuste de **idioma de búsqueda de texto**: es lo que hace que "corriendo" encuentre "correr". Ponlo en el idioma en el que está escrito tu contenido. ### Refuerzo por página El widget nos dice en qué página está el visitante. Quien pregunta "¿cuánto cuesta esto?" en una página de precios se refiere a *esa* página. Este ajuste decide cuánto empujón reciben los fragmentos de la página actual. No cambia nada del coste ni de la velocidad: solo qué fragmentos ganan cuando están igualados. ## El contexto, y qué ve realmente el modelo Los fragmentos que sobreviven a todo eso forman el **contexto**: el texto que se le entrega al modelo junto con la pregunta y tus instrucciones. El modelo responde a partir de ahí. Por eso un asistente construido así puede citar sus fuentes. Cada afirmación viene de un fragmento, y cada fragmento viene de un documento, así que una **cita** no es más que un puntero a de dónde salió el pasaje. Y por eso también el asistente no sabe cosas que no le has dado. ## Por qué a veces vuelve algo que no viene al caso Tres razones, en el orden en que suelen aplicarse: 1. **Top K es un número, no un criterio.** Si pides seis fragmentos, te dan seis, aunque solo dos vengan al caso. Los demás son lo siguiente más cercano. 2. **Parecerse no es acertar.** Dos pasajes pueden tratar del mismo tema y que solo uno responda la pregunta. Los números no los distinguen. 3. **Un fragmento puede perder su contexto.** Un pasaje separado de su encabezado puede sonar general cuando era específico. Los arreglos, por orden: baja Top K, luego sube el umbral, y luego mira el tamaño de fragmento. Si hay una pregunta concreta que sale siempre mal, añadir una entrada corta de pregunta y respuesta que la responda directamente funciona mejor que cualquier ajuste. ## Cómo afecta esto a lo que pagas La recuperación es la mayor palanca que tienes sobre el uso de IA, y la menos evidente. Cada fragmento recuperado es entrada que el modelo lee en **cada pregunta**. Pasar de ocho fragmentos a cinco recorta alrededor de un tercio de la entrada en todas y cada una, y normalmente mejora las respuestas, porque los tres que quitaste eran los peores. Indexar, en cambio, es barato: hacer embeddings cuesta más o menos una centésima parte de lo que cuesta responder, y ocurre una vez por documento. Así que si tu uso es más alto de lo que esperabas: 1. **Baja Top K.** El mayor efecto, y normalmente mejora la calidad. 2. **Sube el umbral de similitud.** Descarta las coincidencias flojas antes de pagarlas. 3. **Y luego** piensa en el modelo. Tienes más detalle sobre cómo se mide el uso en [Uso de IA y límites](/help/ai-usage-and-limits). ## Cuándo no cambiar nada Los valores por defecto van bien para casi todo el contenido. Cambia un ajuste cada vez, haz las mismas preguntas en el **Playground** antes y después, y quédate con el cambio solo si las respuestas mejoran. Cambiar el tamaño de fragmento, el solape o el modelo de embeddings reindexa toda la base de conocimiento. Top K, el umbral, el modo de búsqueda y el refuerzo por página se aplican de inmediato a la siguiente pregunta, sin nada que reconstruir: esos son los que conviene probar.