Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Providing vectors on objects sent to insertMany seems to be ignored #247

Closed
adambeer opened this issue Jan 6, 2025 · 3 comments
Closed

Comments

@adambeer
Copy link

adambeer commented Jan 6, 2025

Im on v1.27.9 with a pre-defined schema that uses openAI as the vectorizer. Im trying to perform a small test by providing my own vectors with my objects to ingest so I dont incur any vectorization costs. Im setting my X-OpenAI-Api-Key to just "abc123" because there should be no need to call their API when I provide my own vectors:

Per the weaviate documentation

However I am getting 401 errors from OpenAI through weaviate saying incorrect API key for every object I'm trying to ingest..

let testObject = {
    class: "Document",
    vector: randomVector, // 3072 dimension vector copied from a call to text-embedding-3-large
    properties: {
        ...
    }
};
const documentCollection = client.collections.get('Document');
let batchObjects = Array(5).fill(testObject);
const response = await documentCollection.data.insertMany(batchObjects);

If I'm not doing something incorrect here, this is very concerning because we have had a system that has been live for a while (and was working at that time) that was using this structure (fetching vectors ourselves) and we would be incurring double costs for vectorization if this is truly broken.

@silentrob
Copy link

There is a small possibility this is related to #243. I am using insertMany and having a vector issue.

@tsmith023
Copy link
Contributor

Hi @adambeer, the expected name of the field when passed to insertMany is vectors as here. Can you confirm whether this is how your production code is defined or whether this is just a typo in your MRE above?

@adambeer
Copy link
Author

adambeer commented Jan 8, 2025

@tsmith023 Thank you! I didnt realize the parameter name had changed. It works as expected now. Closing.

@adambeer adambeer closed this as completed Jan 8, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants