[ENH] URI Data Loader

[atroyn]

Description of changes

This PR adds URIs and DataLoaders into Chroma.

• DataLoader works like EmbeddingFunction, except it takes a URIs and outputs the specified datatype.
• A DataLoader using pillow for image file loading.
• Adds uris as a field on add, query, as well as an include field
• Adds data as an include field

URIs specify a place where data can be loaded from, and can be used to load data for embedding, or as the result of retrieval.

This makes multimodal retrieval with data stored externally as files seamless and extensible.

This PR is stacked on #1293

Test

Integration tests pass.

A new unit test for data loaders: https://github.com/chroma-core/chroma/blob/c71c3efa15d2a9252db26470b9ff1cdb10a2b681/chromadb/test/data_loader/test_data_loader.py

Try the notebook: https://github.com/chroma-core/chroma/blob/c71c3efa15d2a9252db26470b9ff1cdb10a2b681/examples/multimodal/multimodal_retrieval.ipynb

Documentation

Documentation for this and #1293 chroma-core/docs#157

TODOs

• Concurrent Loading
• Tests
• Wiring through FastAPI
• Documentation

[github-actions]

Reviewer Checklist

Please leverage this checklist to ensure your code review is thorough before approving

Testing, Bugs, Errors, Logs, Documentation

• Can you think of any use case in which the code does not behave as intended? Have they been tested?
• Can you think of any inputs or external events that could break the code? Is user input validated and safe? Have they been tested?
• If appropriate, are there adequate property based tests?
• If appropriate, are there adequate unit tests?
• Should any logging, debugging, tracing information be added or removed?
• Are error messages user-friendly?
• Have all documentation changes needed been made?
• Have all non-obvious changes been commented?

System Compatibility

• Are there any potential impacts on other parts of the system or backward compatibility?
• Does this change intersect with any items on our roadmap, and if so, is there a plan for fitting them together?

Quality

• Is this code of a unexpectedly high quality (Readbility, Modularity, Intuitiveness)

[HammadB]

Do we support the case where you want to add an image that you have preloaded but also give its uri so you can fetch it later? I think that will be a common usage pattern.

[atroyn]

Do we support the case where you want to add an image that you have preloaded but also give its uri so you can fetch it later? I think that will be a common usage pattern.

Good catch. On the one hand, I can see that your image might be already loaded in memory and stored somewhere, so loading it again from the URI to embed it is redundant. We can avoid that by giving images priority over uris if both are present in terms of which we embed. Having that implicit ordering makes me a little uncomfortable.

Additionally, it might imply the semantics that we store your images if you provide us a URL to a file on add, and similarly that we update the contained image on update. I would like to avoid that confusion, so I think for now let's leave it this way and see if people run into sharp edges.