Skip to content

Python: Bug: search ignores the advertised vector_field_name and searches another vector field #14740

Open

Description

@Elon-Jiang

Describe the bug

The Python VectorSearch.search() overloads advertise vector_field_name, but the implementation accepts vector_property_name and leaves the advertised keyword in **kwargs. With two vector fields, the public in-memory search silently selects the default field instead of the requested field. The same query therefore returns a different record.

I found this through source inspection and reproduced it locally through real InMemoryCollection.upsert() and search() calls. This is not a production-incident report.

To Reproduce

import asyncio

from semantic_kernel.connectors.in_memory import InMemoryCollection
from semantic_kernel.data.vector import VectorStoreCollectionDefinition, VectorStoreField


async def main():
    definition = VectorStoreCollectionDefinition(fields=[
        VectorStoreField('key', name='id', type='str'),
        VectorStoreField('vector', name='title', type='float', dimensions=2),
        VectorStoreField('vector', name='body', type='float', dimensions=2),
    ])
    collection = InMemoryCollection(record_type=dict, definition=definition, collection_name='field-selection-repro')
    await collection.upsert([
        {'id': 'a', 'title': [1.0, 0.0], 'body': [0.0, 1.0]},
        {'id': 'b', 'title': [0.0, 1.0], 'body': [1.0, 0.0]},
    ])
    observations = {}
    for key, kwargs in {'overload_parameter': {'vector_field_name': 'body'},
                        'runtime_parameter': {'vector_property_name': 'body'},
                        'default': {}}.items():
        found = await collection.search(vector=[1.0, 0.0], top=1, **kwargs)
        observations[key] = [hit.record['id'] async for hit in found.results]
    print(observations)

asyncio.run(main())

Observed output:

{'overload_parameter': ['a'], 'runtime_parameter': ['b'], 'default': ['a']}

Expected behavior

The advertised vector_field_name="body" selects the body vector, returning b, just as vector_property_name="body" does. Callers following the overload should not silently search title instead.

Platform

  • Language: Python 3.12.13, macOS ARM64.
  • Source: current main, df1cb33d0d32699c8d6a2e5b3ea7e5f8990d86d5 (full Python source snapshot).
  • AI model: none; vectors are supplied directly. No cloud, database, model call, or external-service substitute is used.

Additional context / proposed contribution

The mismatch is in python/semantic_kernel/data/vector.py. The overloads use vector_field_name, while the implementation resolves vector_property_name.

I would like to take this fix. My proposed compatibility approach is to accept the advertised keyword as an alias, retain vector_property_name for existing callers, and reject conflicting values rather than silently choosing one. I would add public in-memory search regressions for default selection, both spellings, and the conflict case.

Could a maintainer confirm the intended direction and assign this to Elon-Jiang if contributions are welcome? If the intended fix is to correct the overloads instead, please let me know. I am waiting for agreement before preparing a product patch, per CONTRIBUTING.

AI assistance was used for investigation, reproduction, and this report. Current all-state keyword searches and the 24 open vector-related PRs did not reveal an overlapping fix; those searches are scoped rather than an assertion of exhaustive absence.

Activity

  1. pcbeingused333 commented on Nov 7, 2026

    @pcbeingused333
    Contributor

    I've taken this one: #14743 aligns the search() overloads with the implementation's vector_property_name and adds a test with a two-vector collection.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    pythonPull requests for the Python Semantic Kerneltriage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions