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

feature: include api-version in the EMBEDDING_SERVER env values #1567

Closed
jooni22 opened this issue Jun 8, 2024 · 2 comments
Closed

feature: include api-version in the EMBEDDING_SERVER env values #1567

jooni22 opened this issue Jun 8, 2024 · 2 comments

Comments

@jooni22
Copy link
Contributor

jooni22 commented Jun 8, 2024

Description

image
https://github.com/search?q=repo%3Adevflowinc%2Ftrieve%202023-05-15&type=code

Target(s)

server, search, chat

Requirement to close

One example how it can be fixed
image

Community channels

Matrix is preferred. Reach out on discord or Matrix for further assistance.

@skeptrunedev skeptrunedev changed the title Problem with api embeddings after changing ip in env's feature: include api-version in the EMBEDDING_SERVER env values Jun 11, 2024
@vid277 vid277 self-assigned this Jun 12, 2024
@cdxker
Copy link
Member

cdxker commented Jun 12, 2024

The issue with this is that the EMBEDDING_SERVER_ORIGIN should just be "http://192.1681.146:8000". The server internally adds /embeddings. the api-version section is just used to be compatible with azure openai.

@vid277 vid277 removed their assignment Jun 13, 2024
@jooni22
Copy link
Contributor Author

jooni22 commented Jun 13, 2024

that's what depends on what direction you want to go, if trieve is to support as many possible implementations of model providers for embeddings/reranking/sparse as possible, it needs to be improved because the current code doesn't allow for anything other than embeddings.trieve.ai and azure openai. A direction needs to be taken to solve this problem. I have 2 suggestions:

  1. all checked API providers are listed one by one in .env for example:
    EMBEDDING_SERVER_ORIGIN_AZURE=xx.xx.xx.xx.xx
    EMBEDDING_SERVER_ORIGIN_OPENAI=xx.xx.xx.xx.xx
    EMBEDDING_SERVER_ORIGIN_OLLAMA=xx.xx.xx.xx.xx
    EMBEDDING_SERVER_ORIGIN_CUSTOM=xx.xx.xx.xx.xx
  2. there is one variable left, which can be voluntarily assigned
    EMBEDDING_SERVER_ORIGIN=xx.xx.xx.xx.xx/v1/....

The current way is weak in my opinion, because during implementation you constantly have to look into the code and tweak and re-build it, which sometimes can be problematic or simply too long. I myself currently have it this way and find it convenient.
SPARSE_SERVER_QUERY_ORIGIN="http://192.168.1.146:9202/embed_sparse"
SPARSE_SERVER_DOC_ORIGIN="http://192.168.1.146:9201/embed_sparse"
EMBEDDING_SERVER_ORIGIN="http://192.168.1.146:8000/embeddings"
EMBEDDING_SERVER_ORIGIN_BGEM3="http://192.168.1.146:8000/embeddings"
RERANKER_SERVER_ORIGIN="http://192.168.1.146:9203/rerank"

@skeptrunedev skeptrunedev closed this as not planned Won't fix, can't repro, duplicate, stale Jul 2, 2024
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

When branches are created from issues, their pull requests are automatically linked.

4 participants