{"id":6492,"date":"2026-09-01T08:30:00","date_gmt":"2026-09-01T06:30:00","guid":{"rendered":"http:\/\/blog-david.moreno-morales.com\/?p=6492"},"modified":"2026-08-30T19:12:01","modified_gmt":"2026-08-30T17:12:01","slug":"rag-busqueda-semantica-o-contexto-directo-como-elegir-la-arquitectura-adecuada-para-una-aplicacion-con-ia","status":"publish","type":"post","link":"https:\/\/blog-david.moreno-morales.com\/index.php\/2026\/09\/01\/rag-busqueda-semantica-o-contexto-directo-como-elegir-la-arquitectura-adecuada-para-una-aplicacion-con-ia\/","title":{"rendered":"RAG, b\u00fasqueda sem\u00e1ntica o contexto directo: c\u00f3mo elegir la arquitectura adecuada para una aplicaci\u00f3n con IA"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

El patr\u00f3n m\u00e1s sencillo consiste en proporcionar al modelo toda la informaci\u00f3n necesaria junto con la petici\u00f3n. No hay \u00edndice vectorial, chunking ni pipeline de recuperaci\u00f3n.<\/p>

Imaginemos una aplicaci\u00f3n que analiza el manual interno de un equipo, un contrato concreto o el c\u00f3digo de un repositorio peque\u00f1o. Si el contenido cabe en el contexto aceptado por el modelo y el coste es razonable, introducir una infraestructura RAG completa puede aportar m\u00e1s complejidad que valor.<\/p>

Las ventanas de contexto actuales pueden ser enormes. Google documenta modelos Gemini con ventanas de un mill\u00f3n de tokens o m\u00e1s y plantea expl\u00edcitamente el contexto largo como alternativa viable para determinados problemas que anteriormente requer\u00edan RAG. Tambi\u00e9n advierte de que enviar m\u00e1s informaci\u00f3n tiene implicaciones de coste y latencia y que la recuperaci\u00f3n sobre contextos muy grandes no es perfecta en todos los escenarios.<\/p>

Cu\u00e1ndo tiene sentido<\/h3>

El contexto directo encaja especialmente bien cuando:<\/p>

  • El corpus es peque\u00f1o o mediano.<\/li>
  • Cambia poco.<\/li>
  • Cada consulta necesita buena parte de los documentos.<\/li>
  • Quieres reducir componentes de infraestructura.<\/li>
  • El n\u00famero de consultas no hace prohibitivo reenviar el mismo contenido.<\/li><\/ul>

    La cach\u00e9 de contexto puede cambiar todav\u00eda m\u00e1s esta ecuaci\u00f3n cuando muchas peticiones reutilizan un prefijo grande de informaci\u00f3n. La documentaci\u00f3n actual de Gemini, por ejemplo, contempla caching expl\u00edcito e impl\u00edcito para reducir el coste asociado a esos patrones.<\/p>

    Su principal limitaci\u00f3n<\/h3>

    Que algo quepa<\/em> en la ventana de contexto no significa que debamos enviarlo siempre. M\u00e1s tokens implican m\u00e1s datos que procesar y normalmente m\u00e1s tiempo hasta obtener la respuesta. Adem\u00e1s, en problemas con m\u00faltiples piezas concretas de informaci\u00f3n escondidas en un contexto enorme, la precisi\u00f3n puede degradarse. Por eso el tama\u00f1o m\u00e1ximo de contexto no deber\u00eda convertirse en un objetivo de arquitectura.<\/p>

    La pregunta correcta no es cu\u00e1nto contexto admite el modelo, sino cu\u00e1nto contexto necesita realmente para responder.<\/p>

    Opci\u00f3n 2: b\u00fasqueda sem\u00e1ntica<\/h2>

    La b\u00fasqueda sem\u00e1ntica intenta recuperar contenido por significado y no \u00fanicamente mediante coincidencias literales.<\/p>

    Para ello, normalmente convertimos documentos y consultas en embeddings: representaciones vectoriales que permiten calcular qu\u00e9 fragmentos est\u00e1n sem\u00e1nticamente pr\u00f3ximos.<\/p>

    Supongamos que un usuario pregunta:<\/p>

    \u00ab\u00bfQu\u00e9 ocurre si un empleado deja la empresa?\u00bb<\/p>

    El documento quiz\u00e1 no contiene esa frase. Puede hablar de \u00abprocedimiento de baja\u00bb, \u00abrevocaci\u00f3n de credenciales\u00bb o \u00aboffboarding\u00bb.<\/p>

    Una b\u00fasqueda literal podr\u00eda perder informaci\u00f3n relevante. Una b\u00fasqueda basada en embeddings tiene m\u00e1s posibilidades de relacionar ambos conceptos.<\/p>

    Cu\u00e1ndo funciona bien<\/h3>

    La b\u00fasqueda sem\u00e1ntica es atractiva cuando:<\/p>

    • Los usuarios formulan preguntas con vocabulario diferente al de los documentos.<\/li>
    • Queremos descubrir contenido conceptualmente similar.<\/li>
    • Existen grandes cantidades de texto no estructurado.<\/li>
    • No necesitamos generar siempre una respuesta: quiz\u00e1 solo queremos devolver documentos relevantes.<\/li><\/ul>

      Este \u00faltimo punto es importante.<\/p>

      Una b\u00fasqueda vectorial no es RAG por s\u00ed misma.<\/strong><\/p>

      Puedes usar embeddings para un buscador interno, recomendaciones o detecci\u00f3n de similitud sin que intervenga ning\u00fan LLM generativo.<\/p>

      El problema de utilizar solo vectores<\/h3>

      El significado no lo es todo.<\/p>

      Hay consultas donde una coincidencia exacta importa mucho:<\/p>

      • ERR_CONNECTION_RESET<\/code>;<\/li>
      • SKU-28491<\/code>;<\/li>
      • Factura 2026-00381<\/code>;<\/li>
      • nombres propios;<\/li>
      • versiones;<\/li>
      • fechas;<\/li>
      • referencias legales.<\/li><\/ul>

        Microsoft destaca precisamente esta diferencia: la b\u00fasqueda vectorial funciona bien para similitud conceptual, mientras que la b\u00fasqueda textual mantiene ventajas para coincidencias exactas y terminolog\u00eda especializada.<\/p>

        Eso nos lleva a una arquitectura cada vez m\u00e1s habitual.<\/p>

        Opci\u00f3n 3: b\u00fasqueda h\u00edbrida<\/h2>

        La b\u00fasqueda h\u00edbrida ejecuta dos estrategias a la vez:<\/p>

        • b\u00fasqueda textual o keyword<\/li>
        • b\u00fasqueda vectorial.<\/li><\/ul>

          Despu\u00e9s combina sus resultados.<\/p>

          Azure AI Search, por ejemplo, ejecuta ambas consultas en paralelo y fusiona sus rankings mediante Reciprocal Rank Fusion RRF, para obtener un \u00fanico conjunto ordenado de resultados. Tambi\u00e9n permite a\u00f1adir reranking sem\u00e1ntico posteriormente.<\/p>

          Este enfoque resuelve una debilidad frecuente de los sistemas puramente vectoriales.<\/p>

          Pensemos en:<\/p>

          \u00ab\u00bfQu\u00e9 cambios afectan al endpoint \/v2\/orders<\/code> en la versi\u00f3n 4.3?\u00bb<\/p><\/blockquote>

          La similitud sem\u00e1ntica puede localizar documentaci\u00f3n relacionada con pedidos y APIs.<\/p>

          La b\u00fasqueda textual puede garantizar que aparezcan resultados que contienen exactamente \/v2\/orders<\/code> y 4.3<\/code>.<\/p>

          La combinaci\u00f3n suele proporcionar una recuperaci\u00f3n m\u00e1s robusta.<\/p>

          Una regla pr\u00e1ctica<\/h3>

          Cuando tus datos contienen una mezcla de lenguaje natural y elementos que deben coincidir exactamente\u00a0 (c\u00f3digos, nombres, n\u00fameros, fechas o identificadores), eval\u00faa b\u00fasqueda h\u00edbrida antes de apostar exclusivamente por vectores.<\/p>

          No significa que siempre gane. Significa que deber\u00edas medirla.<\/p>

          Opci\u00f3n 4: RAG<\/h2>

          RAG empieza a aportar todo su valor cuando la informaci\u00f3n disponible supera lo que tiene sentido enviar directamente al modelo y debemos seleccionar din\u00e1micamente qu\u00e9 contexto utilizar.<\/p>

          Un pipeline habitual puede parecerse a esto:<\/p>

          fuentes \u2192 ingesti\u00f3n \u2192 chunking \u2192 \u00edndices \u2192 recuperaci\u00f3n \u2192 reranking \u2192 construcci\u00f3n del contexto \u2192 LLM \u2192 respuesta<\/p>

          La ventaja fundamental es la escalabilidad. El modelo no tiene que recibir toda la base documental. Solo recibe una selecci\u00f3n de evidencia potencialmente relevante.<\/p>

          Anthropic describe el mismo principio al explicar que RAG permite escalar a bases de conocimiento que exceden la ventana de contexto: el sistema recupera solamente fragmentos relevantes y los incorpora a la petici\u00f3n.<\/p>

          Pero cada etapa a\u00f1ade decisiones nuevas.<\/p>

          Chunking<\/h3>

          \u00bfC\u00f3mo dividir documentos?<\/p>

          Un fragmento demasiado peque\u00f1o puede perder contexto. Uno demasiado grande incorpora ruido y consume m\u00e1s tokens.<\/p>

          Anthropic ha mostrado precisamente c\u00f3mo los chunks aislados pueden perder informaci\u00f3n esencial, por ejemplo, a qu\u00e9 empresa o periodo pertenece una cifra, y propone a\u00f1adir contexto espec\u00edfico a cada fragmento antes de indexarlo mediante su enfoque de Contextual Retrieval.<\/p>

          Recuperaci\u00f3n<\/h3>

          \u00bfCu\u00e1ntos resultados recuperamos?<\/p>

          Recuperar poco puede dejar fuera la respuesta correcta. Recuperar demasiado introduce ruido y aumenta el contexto enviado.<\/p>

          Reranking<\/h3>

          Una primera b\u00fasqueda puede generar candidatos r\u00e1pidamente. Un reranker posterior puede volver a ordenarlos utilizando una evaluaci\u00f3n sem\u00e1ntica m\u00e1s potente.<\/p>

          Filtros y seguridad<\/h3>

          En aplicaciones empresariales, relevancia no equivale a autorizaci\u00f3n. Un documento puede ser perfecto para responder una pregunta y, aun as\u00ed, el usuario no deber\u00eda poder verlo. Por eso permisos, tenant, departamento, regi\u00f3n, versi\u00f3n o clasificaci\u00f3n del documento deben formar parte del dise\u00f1o de recuperaci\u00f3n y no a\u00f1adirse como parche despu\u00e9s.<\/p>

          Observabilidad<\/h3>

          Un sistema RAG necesita responder preguntas que una llamada sencilla a un LLM no plantea:<\/p>

          • \u00bfse recuper\u00f3 el documento correcto?<\/li>
          • \u00bfel problema fue retrieval o generaci\u00f3n?<\/li>
          • \u00bfqu\u00e9 chunks llegaron al modelo?<\/li>
          • \u00bfqu\u00e9 puntuaci\u00f3n ten\u00edan?<\/li>
          • \u00bfqu\u00e9 versi\u00f3n del documento se utiliz\u00f3?<\/li>
          • \u00bfel modelo respondi\u00f3 utilizando realmente la evidencia recuperada?<\/li><\/ul>

            Sin esa observabilidad, optimizar RAG se convierte r\u00e1pidamente en ensayo y error.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

            \n\t\t\t\t\t\t
            \n\t\t\t\t\t
            \n\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t\t\"\u00c1rbol\t\t\t\t\t\t\t\t\t\t\t
            \u00c1rbol de decisi\u00f3n: \u00bfContexto directo, b\u00fasqueda o RAG?<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t
            \n\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t\t\"Anatom\u00eda\t\t\t\t\t\t\t\t\t\t\t
            Anatom\u00eda de un RAG moderno<\/figcaption>\n\t\t\t\t\t\t\t\t\t\t<\/figure>\n\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t\t
            \n\t\t\t
            \n\t\t\t\t\t\t
            \n\t\t\t\t\t\t\t\t\t

            Entonces, \u00bfqu\u00e9 arquitectura elegir?<\/h2>

            Una forma pr\u00e1ctica de decidir es comenzar por la opci\u00f3n m\u00e1s sencilla y aumentar complejidad \u00fanicamente cuando los requisitos lo justifiquen.<\/p>

            Usa contexto directo cuando\u2026<\/h3>

            El conocimiento necesario es acotado, relativamente estable y cabe de forma econ\u00f3mica en cada interacci\u00f3n.<\/p>

            Es especialmente \u00fatil para prototipos, an\u00e1lisis de documentos concretos y procesos donde casi todo el corpus es relevante para cada consulta.<\/p>

            Usa b\u00fasqueda sem\u00e1ntica cuando\u2026<\/h3>

            Necesitas localizar informaci\u00f3n por significado sobre un corpus amplio y las coincidencias conceptuales son m\u00e1s importantes que las literales.<\/p>

            Tambi\u00e9n sirve cuando el producto final es un buscador y no necesariamente una respuesta generada.<\/p>

            Usa b\u00fasqueda h\u00edbrida cuando\u2026<\/h3>

            Necesitas significado y<\/strong> precisi\u00f3n lexical.<\/p>

            Es una candidata especialmente fuerte en documentaci\u00f3n t\u00e9cnica, cat\u00e1logos, soporte, normativa y datos empresariales con identificadores, versiones y terminolog\u00eda espec\u00edfica.<\/p>

            Usa RAG cuando\u2026<\/h3>

            El corpus es demasiado grande o din\u00e1mico para enviarlo completo, necesitas recuperar solamente una parte por petici\u00f3n o requieres control expl\u00edcito sobre evidencia, filtros, permisos y trazabilidad.<\/p>

            Y recuerda: RAG no obliga a elegir \u00fanicamente b\u00fasqueda vectorial.<\/p>

            Un RAG puede recuperar mediante:<\/p>

            • SQL<\/li>
            • b\u00fasquedas textuales<\/li>
            • vectores<\/li>
            • b\u00fasqueda h\u00edbrida<\/li>
            • APIs<\/li>
            • grafos<\/li>
            • herramientas especializadas<\/li>
            • o una combinaci\u00f3n de varias fuentes<\/li><\/ul>

              En producci\u00f3n, probablemente acabar\u00e1s con una arquitectura h\u00edbrida<\/h2>

              Las fronteras entre estos patrones se est\u00e1n haciendo menos r\u00edgidas. Una aplicaci\u00f3n puede mantener instrucciones y documentaci\u00f3n fundamental en contexto directo, consultar mediante b\u00fasqueda h\u00edbrida una base documental extensa, recuperar datos operacionales mediante SQL y entregar finalmente todas esas evidencias al mismo modelo. Ese dise\u00f1o sigue siendo RAG en sentido amplio, pero su arquitectura de recuperaci\u00f3n es mucho m\u00e1s sofisticada que \u00abembeddings + base vectorial\u00bb.<\/p>

              Por eso conviene pensar en capas:<\/p>

              1. Fuente de verdad<\/strong><\/p>

              \u00bfD\u00f3nde vive realmente la informaci\u00f3n?<\/p>

              2. Selecci\u00f3n<\/strong><\/p>

              \u00bfC\u00f3mo determinamos qu\u00e9 informaci\u00f3n necesita esta consulta?<\/p>

              3. Autorizaci\u00f3n<\/strong><\/p>

              \u00bfQu\u00e9 parte de esa informaci\u00f3n puede conocer este usuario?<\/p>

              4. Ranking<\/strong><\/p>

              \u00bfQu\u00e9 evidencia es m\u00e1s relevante?<\/p>

              5. Contexto<\/strong><\/p>

              \u00bfCu\u00e1nto de esa evidencia enviamos al modelo?<\/p>

              6. Generaci\u00f3n<\/strong><\/p>

              \u00bfC\u00f3mo obligamos al sistema a distinguir entre evidencia disponible y conocimiento no fundamentado?<\/p>

              7. Evaluaci\u00f3n<\/strong><\/p>

              \u00bfC\u00f3mo sabemos que funciona?<\/p>

              La arquitectura se elige con evaluaciones, no con intuici\u00f3n<\/h2>

              Antes de decidir que una arquitectura es mejor, crea un conjunto de preguntas representativas de producci\u00f3n.<\/p>

              Incluye consultas f\u00e1ciles y dif\u00edciles:<\/p>

              • Preguntas sem\u00e1nticas.<\/li>
              • T\u00e9rminos exactos.<\/li>
              • Acr\u00f3nimos.<\/li>
              • Informaci\u00f3n distribuida entre varios documentos.<\/li>
              • Documentos similares pero pertenecientes a versiones diferentes.<\/li>
              • Preguntas sin respuesta.<\/li>
              • Contenido que el usuario no puede consultar.<\/li><\/ul>

                Despu\u00e9s mide al menos:<\/p>

                Recall de recuperaci\u00f3n:<\/strong> \u00bfapareci\u00f3 la evidencia correcta entre los candidatos?<\/p>

                Precisi\u00f3n del ranking:<\/strong> \u00bfla evidencia correcta qued\u00f3 suficientemente arriba?<\/p>

                Groundedness:<\/strong> \u00bfla respuesta se apoya en las fuentes recuperadas?<\/p>

                Latencia:<\/strong> \u00bfcu\u00e1nto tarda cada etapa?<\/p>

                Coste:<\/strong> \u00bfcu\u00e1nto cuesta ingesti\u00f3n, almacenamiento, b\u00fasqueda, reranking y generaci\u00f3n?<\/p>

                Mantenibilidad:<\/strong> \u00bfqu\u00e9 infraestructura tendr\u00e1 que operar el equipo durante los pr\u00f3ximos a\u00f1os?<\/p>

                El patr\u00f3n m\u00e1s sofisticado no siempre gana.<\/p>

                Una soluci\u00f3n con contexto directo puede superar a un RAG mal dise\u00f1ado.<\/p>

                Una b\u00fasqueda keyword bien configurada puede resolver mejor determinados dominios que una base vectorial.<\/p>

                Y una buena b\u00fasqueda h\u00edbrida puede evitar m\u00faltiples capas de complejidad posterior.<\/p>

                Conclusi\u00f3n<\/h2>

                RAG sigue siendo una de las arquitecturas m\u00e1s \u00fatiles para construir aplicaciones sobre conocimiento empresarial, pero ya no deber\u00eda ser el punto de partida autom\u00e1tico.<\/p>

                Empieza por una pregunta m\u00e1s sencilla:<\/p>

                \u00bfQu\u00e9 necesita el modelo para responder correctamente y cu\u00e1l es la forma m\u00e1s eficiente de proporcion\u00e1rselo?<\/strong><\/p>

                Si toda la informaci\u00f3n necesaria cabe razonablemente en el contexto, empieza por contexto directo.<\/p>

                Si necesitas recuperar por significado, prueba b\u00fasqueda sem\u00e1ntica.<\/p>

                Si tu dominio mezcla significado con coincidencias exactas, eval\u00faa b\u00fasqueda h\u00edbrida.<\/p>

                Si el corpus crece, cambia constantemente, requiere permisos y necesitas seleccionar evidencia din\u00e1mica, construye RAG.<\/p>

                Y solo despu\u00e9s a\u00f1ade chunking avanzado, m\u00faltiples \u00edndices, rerankers, agentes o pipelines adicionales.<\/p>

                Porque una buena arquitectura de IA no es la que incorpora m\u00e1s componentes.<\/p>

                Es la que consigue la evidencia correcta, para la consulta correcta, con el coste, la latencia y la complejidad adecuados.<\/p>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t

                \n\t\t\t\t\t\t
                \n\t\t\t\t\t
                \n\t\t\t
                \n\t\t\t\t\t\t
                \n\t\t\t\t\t

                REFERENCIAS\n<\/h4>\t\t\t\t<\/div>\n\t\t\t\t
                \n\t\t\t\t\t\t\t\t\t
                • Long context | Gemini API | Google AI for Developers \u2014 https:\/\/ai.google.dev\/gemini-api\/docs\/long-context \u2014 Documentaci\u00f3n oficial sobre ventanas de contexto largas, casos de uso, caching, costes, latencia y limitaciones.<\/li>
                • Hybrid Search Overview | Azure AI Search | Microsoft Learn \u2014 https:\/\/learn.microsoft.com\/en-us\/azure\/search\/hybrid-search-overview \u2014 Documentaci\u00f3n oficial sobre b\u00fasqueda h\u00edbrida, combinaci\u00f3n de texto y vectores y Reciprocal Rank Fusion.<\/li>
                • Create a Hybrid Query | Azure AI Search | Microsoft Learn \u2014 https:\/\/learn.microsoft.com\/en-us\/azure\/search\/hybrid-search-how-to-query \u2014 Gu\u00eda oficial actualizada sobre consultas h\u00edbridas y semantic ranking.<\/li>
                • Contextual Retrieval in AI Systems | Anthropic \u2014 https:\/\/www.anthropic.com\/engineering\/contextual-retrieval \u2014 Fuente t\u00e9cnica original sobre Contextual Embeddings, Contextual BM25 y problemas de p\u00e9rdida de contexto en RAG tradicional.<\/li>
                • Retrieval Augmented Generation (RAG) for Projects | Anthropic Help Center \u2014 https:\/\/support.anthropic.com\/en\/articles\/11473015-retrieval-augmented-generation-rag-for-projects \u2014 Ejemplo actual de uso pr\u00e1ctico de RAG para escalar conocimiento m\u00e1s all\u00e1 de la ventana de contexto.<\/li>
                • Vector store files | OpenAI API Reference \u2014 https:\/\/platform.openai.com\/docs\/api-reference\/vector-stores-files \u2014 Referencia oficial sobre archivos en vector stores utilizados por herramientas de recuperaci\u00f3n como File Search.<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"

                  Comparaci\u00f3n orientada a decisiones entre patrones para conectar modelos con informaci\u00f3n empresarial.<\/p>\n","protected":false},"author":1,"featured_media":6499,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42],"tags":[63,55,49,52,62,48],"class_list":["post-6492","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-arquitectura","tag-arquitectura","tag-automatizacion","tag-ia","tag-inteligenciaartificial","tag-rag","tag-software"],"_links":{"self":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6492","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/comments?post=6492"}],"version-history":[{"count":3,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6492\/revisions"}],"predecessor-version":[{"id":6504,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/posts\/6492\/revisions\/6504"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/media\/6499"}],"wp:attachment":[{"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/media?parent=6492"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/categories?post=6492"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog-david.moreno-morales.com\/index.php\/wp-json\/wp\/v2\/tags?post=6492"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}