Los valores más óptimos para las opciones de tu índice vectorial dependen de tu caso de uso, tu conjunto de datos de vectores y los vectores de búsqueda. Puedes establecer y ajustar estos valores creando un nuevo índice de vectores y configurando index_option_list en la instrucción CREATE VECTOR INDEX. Es posible que debas realizar ajustes iterativos para encontrar los mejores valores para tu carga de trabajo específica.
A continuación, se incluyen algunos lineamientos útiles que puedes seguir cuando elijas valores adecuados:
tree_depth (nivel del árbol): Si la tabla que indexas tiene menos de 10 millones de filas, usa un tree_depth de 2. De lo contrario, un tree_depth de 3 admite tablas de hasta 10,000 millones de filas aproximadamente.
num_leaves: Usa la raíz cuadrada de la cantidad de filas del conjunto de datos. Un valor más grande puede aumentar el tiempo de compilación del índice de vectores. Evita establecer num_leaves como un valor mayor que table_row_count dividido por 1,000, ya que esto genera hojas demasiado pequeñas y un rendimiento deficiente.
num_leaves_to_search: Esta opción especifica cuántos nodos hoja del índice se buscan. Aumentar num_leaves_to_search mejora la recuperación, pero también incrementa la latencia y el costo. Recomendamos usar un número que sea el 1% de la cantidad total de hojas definidas en la instrucción CREATE VECTOR INDEX como el valor de num_leaves_to_search. Si usas una cláusula de filtro, aumenta este valor para ampliar la búsqueda.
Si se logra una recuperación aceptable, pero el costo de la consulta es demasiado alto, lo que genera un QPS máximo bajo, intenta aumentar num_leaves siguiendo estos pasos:
Establece num_leaves en algún múltiplo k de su valor original (por ejemplo, 2 * sqrt(table_row_count)).
Establece num_leaves_to_search para que sea el mismo múltiplo k de su valor original.
Experimenta con la reducción de num_leaves_to_search para mejorar el costo y las QPS, y mantener la recuperación.
Mejora la recuperación
Para mejorar la recuperación, considera ajustar el valor de num_leaves_to_search o volver a compilar tu índice de vectores.
Aumentar el valor de num_leaves_to_search
Si el valor de num_leaves_to_search es demasiado pequeño, es posible que te resulte más difícil encontrar los vecinos más cercanos para algunos vectores de consulta. Crear un nuevo índice de vectores con un valor de num_leaves_to_search aumentado puede ayudar a mejorar la recuperación, ya que se buscan más hojas. Las búsquedas recientes pueden contener más de estos vectores desafiantes.
Vuelve a compilar el índice de vectores
La estructura de árbol del índice de vectores se optimiza para el conjunto de datos en el momento de la creación y, luego, permanece estática. Por lo tanto, si se agregan vectores significativamente diferentes después de crear el índice de vectores inicial, la estructura del árbol podría ser subóptima, lo que generaría una recuperación más deficiente.
Para volver a compilar tu índice de vectores sin tiempo de inactividad, haz lo siguiente:
Crea un índice vectorial nuevo en la misma columna de incorporación que el índice vectorial actual y actualiza los parámetros (por ejemplo, OPTIONS) según corresponda.
Una vez que se complete la creación del índice, usa la sugerencia FORCE_INDEX para apuntar al índice nuevo y actualizar la búsqueda de vectores. Esto garantiza que la búsqueda use el nuevo índice de vectores. Es posible que también debas volver a ajustar num_leaves_to_search en tu nueva búsqueda.
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Información o código de muestra incorrectos","incorrectInformationOrSampleCode","thumb-down"],["Faltan la información o los ejemplos que necesito","missingTheInformationSamplesINeed","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-09-05 (UTC)"],[],[],null,["# Vector indexing best practices\n\n| **PostgreSQL interface note:** The examples in this topic are intended for GoogleSQL-dialect databases. This feature doesn't support PostgreSQL interface.\n\n\u003cbr /\u003e\n\n\n| **Note:** This feature is available with the Spanner Enterprise edition and Enterprise Plus edition. For more information, see the [Spanner editions overview](/spanner/docs/editions-overview).\n\n\u003cbr /\u003e\n\nThis page describes vector indexing best practices that optimize your\n[vector indexes](/spanner/docs/vector-indexes) and improve\n[approximate nearest neighbor (ANN) query results](/spanner/docs/find-approximate-nearest-neighbors#query-vector-embeddings).\n\nTune the vector search options\n------------------------------\n\nThe most optimal values for your vector index options depend on your use case,\nvector dataset, and on the query vectors. You can set and tune these values\nby creating a new vector index and setting the [`index_option_list`](/spanner/docs/reference/standard-sql/data-definition-language#index_option_list)\nin the `CREATE VECTOR INDEX` statement. You might need to perform iterative\ntuning to find the best values for your specific workload.\n\nHere are some helpful guidelines to follow when picking appropriate values:\n\n- `tree_depth` (tree level): If the table you're indexing has fewer than 10\n million rows, use a `tree_depth` of `2`. Otherwise, a `tree_depth` of `3`\n supports tables of up to about 10 billion rows.\n\n- `num_leaves`: Use the square root of the number of rows in the dataset. A\n larger value can increase vector index build time. Avoid setting `num_leaves`\n larger than the `table_row_count` divided by 1000 as this results in overly\n small leaves and poor performance.\n\n- `num_leaves_to_search`: This option specifies how many leaf nodes of the index\n are searched. Increasing `num_leaves_to_search` improves recall but also\n increases latency and cost. We recommend using a number that is 1% the total\n number of leaves defined in the `CREATE VECTOR INDEX` statement as the value\n for `num_leaves_to_search`. If you're using a filter clause, increase\n this value to widen the search.\n\nIf acceptable recall is achieved, but the cost of querying is too high,\nresulting in low maximum QPS, try increasing `num_leaves` by following these\nsteps:\n\n1. Set `num_leaves` to some multiple k of its original value (for example, `2 * sqrt(table_row_count)`).\n2. Set `num_leaves_to_search` to be the same multiple k of its original value.\n3. Experiment with reducing `num_leaves_to_search` to improve cost and QPS while maintaining recall.\n\nImprove recall\n--------------\n\nTo improve recall, consider tuning the `num_leaves_to_search` value or\nrebuilding your vector index.\n\n### Increase the `num_leaves_to_search` value\n\nIf the `num_leaves_to_search` value is too small, you might find it more\nchallenging to find the nearest neighbors for some query vectors. Creating a new\nvector index with an increased `num_leaves_to_search` value can help improve\nrecall by searching more leaves. Recent queries might contain more of these\nchallenging vectors.\n\n### Rebuild the vector index\n\nThe tree structure of the vector index is optimized for the dataset at the time\nof creation, and is static thereafter. Therefore, if significantly different\nvectors are added after creating the initial vector index, then the tree\nstructure might be sub-optimal, leading to poorer recall.\n\nTo rebuild your vector index without downtime:\n\n1. Create a new vector index on the same embedding column as the current vector index, updating parameters (for example, `OPTIONS`) as appropriate.\n2. After the index creation completes, use the [`FORCE_INDEX` hint](/spanner/docs/secondary-indexes#index-directive) to point at the new index to update the vector search query. This ensures that the query uses the new vector index. You might also need to retune `num_leaves_to_search` in your new query.\n3. Drop the outdated vector index.\n\nWhat's next\n-----------\n\n- Learn more about Spanner [vector indexes](/spanner/docs/vector-indexes).\n\n- Learn more about Spanner [approximate nearest neighbors](/spanner/docs/find-approximate-nearest-neighbors).\n\n- Learn more about the [GoogleSQL `APPROXIMATE_COSINE_DISTANCE()`, `APPROXIMATE_EUCLIDEAN_DISTANCE()`, `APPROXIMATE_DOT_PRODUCT()`](/spanner/docs/reference/standard-sql/mathematical_functions) functions.\n\n- Learn more about the [GoogleSQL `VECTOR INDEX` statements](/spanner/docs/reference/standard-sql/data-definition-language#vector_index_statements)."]]
