Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Cómo funcionan la fragmentación y el análisis de contenido para las bases de conocimiento

Amazon Bedrock divide primero los documentos o el contenido en partes administrables para una recuperación de datos eficiente. Luego, los fragmentos se convierten en incrustaciones y se escriben en un índice vectorial (representación vectorial de los datos), manteniendo una correspondencia con el documento original. Las incrustaciones vectoriales permiten comparar matemáticamente los textos.

Fraccionamiento estándar

Amazon Bedrock admite los siguientes enfoques estándar de fragmentación:

También puedes elegir no fragmentar tus documentos. Cada documento se trata como un único fragmento de texto. Es posible que desee preprocesar sus documentos dividiéndolos en archivos separados antes de elegir no fragmentar como enfoque o estrategia de fragmentación.

El siguiente es un ejemplo de cómo configurar la fragmentación de tamaño fijo:

API

{
...
   "vectorIngestionConfiguration": {
      "chunkingConfiguration": {
         "chunkingStrategy": "FIXED_SIZE",
         "fixedSizeChunkingConfiguration": {
            "maxTokens": "100",
            "overlapPercentage": "10"
         }
      }
   }
}

Fragmentación jerárquica

La fragmentación jerárquica implica organizar la información en estructuras anidadas de fragmentos secundarios y primarios. Al crear una fuente de datos, puede definir el tamaño del fragmento principal, el tamaño del fragmento secundario y el número de fichas que se superponen entre cada fragmento. Durante la recuperación, el sistema recupera inicialmente los fragmentos secundarios, pero los reemplaza por fragmentos principales más amplios para proporcionar al modelo un contexto más completo.

Las incrustaciones de texto pequeñas son más precisas, pero la recuperación busca un contexto integral. Un sistema de fragmentación jerárquica equilibra estas necesidades al reemplazar los fragmentos secundarios recuperados por los fragmentos principales cuando sea apropiado.

Para la fragmentación jerárquica, las bases de conocimiento de Amazon Bedrock permiten especificar dos niveles o la siguiente profundidad para la fragmentación:

También estableces las fichas superpuestas entre los fragmentos. Este es el número absoluto de fichas superpuestas entre los fragmentos principales consecutivos y los fragmentos secundarios consecutivos.

El siguiente es un ejemplo de configuración de la fragmentación jerárquica:

API

{
...
    "vectorIngestionConfiguration": {
        "chunkingConfiguration": {
            "chunkingStrategy": "HIERARCHICAL",
            "hierarchicalChunkingConfiguration": { // Hierarchical chunking
                "levelConfigurations": [{
                    "maxTokens": 1500 // Parent max tokens
                },
                {
                    "maxTokens": 300 // Child max tokens
                }],
                "overlapTokens": 60
            }
        }
    }
}

Fragmentación semántica

La fragmentación semántica es una técnica de procesamiento del lenguaje natural que divide el texto en fragmentos significativos para mejorar la comprensión y la recuperación de la información. Su objetivo es mejorar la precisión de la recuperación centrándose en el contenido semántico y no solo en la estructura sintáctica. Al hacerlo, puede facilitar una extracción y manipulación más precisas de la información relevante.

Al configurar la fragmentación semántica, tiene la opción de especificar los siguientes hiperparámetros.

El siguiente es un ejemplo de configuración de la fragmentación semántica:

API

{
...
    "vectorIngestionConfiguration": {
        "chunkingConfiguration": {
            "chunkingStrategy": "SEMANTIC",
            "semanticChunkingConfiguration": { // Semantic chunking 
                "maxTokens": 300,
                "bufferSize": 0,
                "breakpointPercentileThreshold": 95
            }
        }
    }
}

Opciones de análisis avanzadas

Puede utilizar técnicas de análisis avanzadas para analizar la información no textual de los documentos. Esta función le permite seleccionar un modelo básico o un perfil de inferencia para analizar datos complejos, como tablas y gráficos. Además, puede adaptarlo a sus necesidades específicas sobrescribiendo las solicitudes predeterminadas para la extracción de datos, lo que garantiza un rendimiento óptimo en un conjunto diverso de casos de uso. En la actualidad, Anthropic Claude 3 Sonnet y Anthropic Claude 3 Haiku son compatibles.

Existen límites en cuanto a los tipos de archivos y los datos totales que se pueden analizar mediante el análisis avanzado. Para obtener información sobre los tipos de archivos para el análisis avanzado, consulte Formatos de documentos. Para obtener información sobre el total de datos que se pueden analizar mediante el análisis avanzado, consulte Cuotas.

El siguiente es un ejemplo de configuración de un modelo básico para facilitar el análisis avanzado:

API

{
...
    "vectorIngestionConfiguration": {
        "chunkingConfiguration": { ... },
        "parsingConfiguration": {   // Parse tabular data within docs 
            "parsingStrategy": "BEDROCK_FOUNDATION_MODEL",
            "bedrockFoundationModelConfiguration": {
                "parsingPrompt": {
                    "parsingPromptText": "string"
                },
                "modelArn": "string"
            }
        }
    }
}

Selección de metadatos para CSVs

Al ingerir archivos CSV (valores separados por comas), puede hacer que la base de conocimientos trate determinadas columnas como campos de contenido y no como campos de metadatos. En lugar de tener cientos o miles de pares de archivos de contenido/metadatos, ahora puede tener un solo CSV archivo y el correspondiente archivo metadata.json, lo que proporciona a la base de conocimientos consejos sobre cómo tratar cada columna dentro de su archivo. CSV

Hay límites para los campos y atributos de metadatos de los documentos por fragmento. Consulte Cuotas para ver las bases de conocimiento

Antes de ingerir un CSV archivo, asegúrese de lo siguiente:

El CSV archivo se analiza fila por fila y la estrategia de fragmentación y la incrustación vectorial se aplican al campo de contenido. Actualmente, las bases de conocimiento de Amazon Bedrock admiten un campo de contenido. El campo de contenido se divide en fragmentos y los campos de metadatos (columnas) que están asociados a cada fragmento se tratan como valores de cadena.

Por ejemplo, supongamos que hay una CSV con una columna «Descripción» y una columna «Fecha de creación». El campo de descripción es el campo de contenido y la fecha de creación es un campo de metadatos asociado. El texto de descripción se divide en fragmentos y se convierte en incrustaciones vectoriales para cada fila de. CSV El valor de la fecha de creación se trata como una representación en cadena de la fecha y se asocia a cada fragmento de la descripción.

Si no se proporciona ningún campo de inclusión/exclusión, todas las columnas se tratan como columnas de metadatos, excepto la columna de contenido. Si solo se proporcionan campos de inclusión, solo las columnas proporcionadas se tratan como metadatos. Si solo se proporcionan campos de exclusión, todas las columnas, excepto las columnas de exclusión, se tratan como metadatos. Si proporciona lo mismo fieldName en ambos fieldsToInclude yfieldsToExlcude, Amazon Bedrock generará una excepción de validación. Si hay un conflicto entre inclusión y exclusión, [se producirá un error].

Las filas en blanco que se encuentren dentro de a CSV se ignoran o se omiten.

Transformación personalizada

Tiene la capacidad de definir una función Lambda de transformación personalizada para inyectar su propia lógica en el proceso de ingesta de la base de conocimientos.

Es posible que tenga una lógica de fragmentación específica que no sea compatible de forma nativa con las bases de conocimiento de Amazon Bedrock. Utilice la opción de estrategia de no fragmentación mientras especifica una función Lambda que contenga su lógica de fragmentación. Además, tendrá que especificar un bucket de Amazon S3 para que la base de conocimientos escriba los archivos que desee fragmentar con la función Lambda.

Tras la fragmentación, la función Lambda volverá a escribir los archivos fragmentados en el mismo depósito y devolverá las referencias a la base de conocimientos para su posterior procesamiento. Si lo desea, tiene la posibilidad de proporcionar las suyas propias AWS KMS clave para el cifrado de los archivos que se almacenan en su bucket de S3.

Como alternativa, puede especificar los metadatos a nivel de fragmento y, al mismo tiempo, hacer que la base de conocimientos aplique una de las estrategias de fragmentación compatibles de forma nativa. En este caso, seleccione una de las estrategias de fragmentación predefinidas (por ejemplo, fragmentación predeterminada o de tamaño fijo) y, al mismo tiempo, proporcione una referencia a la función Lambda y al bucket de S3. En este caso, la base de conocimientos almacenará los archivos analizados y prefragmentados en el bucket predefinido de S3 antes de llamar a la función Lambda para añadir más metadatos a nivel de fragmento.

Tras añadir metadatos a nivel de fragmento, la función Lambda volverá a escribir los archivos fragmentados en el mismo depósito y devolverá las referencias a la base de conocimientos para su posterior procesamiento. Tenga en cuenta que los metadatos a nivel de fragmento tienen prioridad y sobrescriben los metadatos a nivel de archivo, en caso de que se produzcan colisiones.

Para ver un ejemplo del uso de una función Lambda de Python para la fragmentación personalizada, consulte Fragmentación personalizada con la función Lambda.

Para obtener información sobre los contratos API y archivarlos, consulte las siguientes estructuras:

APIcontraer al añadir una transformación personalizada mediante la función Lambda

{
...
    "vectorIngestionConfiguration": {
        "customTransformationConfiguration": { // Custom transformation 
            "intermediateStorage": {
                "s3Location": { // the location where input/output of the Lambda is expected 
                    "uri": "string"
                }
            },
            "transformations": [{
                "transformationFunction": {
                    "transformationLambdaConfiguration": {
                        "lambdaArn": "string"
                    }
                },
                "stepToApply": "string" // enum of POST_CHUNKING
            }]
        },
        "chunkingConfiguration": {
            "chunkingStrategy": "string",
            "fixedSizeChunkingConfiguration": {
                "maxTokens": "number",
                "overlapPercentage": "number"
            }
            ...
        }
    }
}

Formato de entrada de transformación Lambda personalizado

{
    "version": "1.0",
    "knowledgeBaseId": "string",
    "dataSourceId": "string",
    "ingestionJobId": "string",
    "bucketName": "string",
    "priorTask": "string",
    "inputFiles": [{
        "originalFileLocation": {
            "type": "S3",
            "s3_location": {
                "uri": "string"
            }
        },
        "fileMetadata": {
            "key1": "value1",
            "key2": "value2"
        },
        "contentBatches": [{
            "key":"string"
        }]
    }]
}

Formato de salida de transformación Lambda personalizado

{
    "outputFiles": [{
        "originalFileLocation": {
            "type": "S3",
            "s3_location": {
                "uri": "string"
            }
        },
        "fileMetadata": {
            "key1": "value1",
            "key2": "value2"
        },
        "contentBatches": [{
            "key": "string"
        }]
    }]
}

El formato de archivo de los objetos al que se hace referencia en fileContents

{
    "fileContents": [{
        "contentBody": "...",
        "contentType": "string", // enum of TEXT, PDF, ...
        "contentMetadata": {
            "key1": "value1",
            "key2": "value2"
        }
    }
    ...
    ]
}