Skip to content

S3 Vector use-case: big files

0

Hello,

Considering this issue, S3 Vector can only contain keys with text values with size less than 2kb, or extended size of 40 kb. Otherwise, there will be a Metadata Error: Filterable metadata must have at most 2048 bytes.

How should this S3 Vector be used in an use-case where a user needs to search in a document of 1 MB ? Should the document be splitted into chunks less than 2 kb that should be inserted into S3 Vector ?
How the S3 Vector semantic search will search the document as a whole, because it seams that it can only search into each key independently ?

Thank you,

2 Answers
0

The filterable part can’t be bigger than 2 KB, so in one of the links to questions and commands you are using I see you are passing the actual document text which is filterable and is more than 2kb so likely S3 will reject to save it. It’s common to split large documents into sections when working with AI search systems, so you can break you document in fine small chunks and for each chunk you save, add a simple metadata key (such as doc_id) containing the name of the original file.

answered a year ago

-1

When working with large documents (like 1MB files) in S3 Vectors, you should use non-filterable metadata for storing the larger content while using chunking strategies for effective semantic search.

Here's how to approach this:

  1. Use non-filterable metadata for large content: While filterable metadata has a 2KB limit (or 40KB extended size), non-filterable metadata is designed specifically for storing larger amounts of contextual data. This is ideal for storing full document text, detailed descriptions, or other large content that doesn't need to be searchable but should be returned with query results.

  2. Implement a chunking strategy: Divide your large document into smaller, meaningful chunks (paragraphs, sections, etc.). Each chunk would be represented as a separate vector in your index.

  3. Store the chunks as vectors: For each chunk, create a vector embedding representing its semantic meaning, and store this in your S3 Vector index.

  4. Use metadata effectively:

  • Store the chunk's text content as non-filterable metadata
  • Use filterable metadata for attributes you want to query on (document ID, section number, categories, etc.)
  1. Retrieve and reconstruct: When performing semantic search, you'll get back the most relevant chunks. You can then retrieve the associated non-filterable metadata containing the actual text content.

This approach allows you to search across large documents by finding the most semantically relevant chunks, while still maintaining access to the full content through non-filterable metadata. The semantic search operates at the chunk level, finding the most relevant pieces of your document based on the vector similarity.

Remember that non-filterable metadata keys must be explicitly configured during vector index creation and cannot be changed to filterable later. You can configure up to 10 non-filterable metadata keys per vector index.
Sources
Metadata filtering - Amazon Simple Storage Service
S3 Vectors best practices - Amazon Simple Storage Service
Amazon OpenSearch Service vector database capabilities revisited | AWS Big Data Blog
Vector indexes - Amazon Simple Storage Service

answered a year ago

  • Thank you for your answer,
    Considering:

    This approach allows you to search across large documents by finding the most semantically relevant chunks, while still maintaining access to the full content through non-filterable metadata. The semantic search operates at the chunk level, finding the most relevant pieces of your document based on the vector similarity

    the conclusion is that S3 Vector can't semantically/conceptually search the whole document, but only parts of it. This could be one use-case.
    Is there an AWS service that can semantically/conceptually search the whole document (some concepts can be seen only in multiple chunks) ?

  • My god.

    Why there is no example, no detailed doc but just a general solution, do you expect customer to figure out by themselves? I checked all docs and other blogs, but I could find those answers which are essential to resolve the problem.

    First, how customer know why metadata was created over 2kb? How customer know what's the caused metadata keys?

    Seconds, without knowing which key is cause, how come customer knows which keys to be used non-filterable metadata to resolve the issue?

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.