refactor: classes and configs

[cachho]

Description

I want to share my WIP refactor and the thoughts behind it.

We currently have a problem with classes and methods being mixed into other classes, where they don't belong. Often times, it doesn't only make little sense from a logical standpoint, it also makes everything harder to maintain. For instance the collection name is clearly a database attribute, yet we go out of our way to assign it to the class.

Here's the new concept:

The app class is the highest in the hierarchy and has multiple equal subclasses

By subclasses I mean logical subclasses and not parent and child classes in python.

app.database
app.llm
app.embedding

llm is what's currently the QueryConfig, so the name might change. But it's everything that has to do with how you interact with the llm, such as max tokens, temperature, etc.
app.embedding is a new concept I came up with, that unites embedding_function, ChunkerConfig and LoaderConfig. From a language standpoint, it might make more sense to call it embedder.

Not coincidentally, these 3 parts are the interchangeable parts.

Each one of these parts has its own config. This way they are all accessible from the main app

app.database.config
app.llm.config
app.embedding.config

AppConfig is kind of obsolete, because everything falls into one of the three categories. As my PR stands right now, this can already be seen, all that's left is log_level, id (which should go to database too) and collect_metrics.

For the App, CustomApp and OpenSourceApp the idea is similar to know, it will just take away some of the config options and provide a opinionated default.

Outcome

The interface is then app = App(llm=Llm(), db=VectorDb(), embedding=Embedding()). In it's longest form with all configs it's app = App(llm=Llm(config=LlmConfig()), db=VectorDb(config=DbConfig()), embedding=Embedding(config=EmbeddingConfig())). Yes, this is longer, but it's also more logical. If you have an opinionated app, it will also be shorter.

Main purpose

The main purpose besides being more logical is that it will make the app easier to serialize. You have hierarchical components.

so in a json format it would be

{
  "app": {
    "db": {},
    "llm": {},
    "embedding": {}
  }
}

currently it's something like this, and some options are not even connected to the app.

{
  "app": {
    "config": {
      "db": {},
      "llm_model": {}
    },
    "db": {}
  }
}

Fixes # (issue)

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Refactor (does not change functionality, e.g. code style improvements, linting)
• Documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Please delete options that are not relevant.

• Unit Test
• Test Script (please provide)

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

Maintainer Checklist

• closes #xxxx (Replace xxxx with the GitHub issue number)
• Made sure Checks passed

[taranjeet]

@cachho : can you please resolve the conflicts here?

[taranjeet]

this is a big, good and critical PR. Great work @cachho here.
cc @deshraj