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

[BUG]: Differences in Behavior Between Threads API and Workspace in AnythingLLM #2526

Open
Peterson047 opened this issue Oct 23, 2024 · 2 comments
Labels
possible bug Bug was reported but is not confirmed or is unable to be replicated. question Further information is requested

Comments

@Peterson047
Copy link

How are you running AnythingLLM?

Docker (remote machine)

What happened?

Hello everyone,

I have been implementing a system over the past few months and noticed some peculiarities in the API's behavior. The main issue is that the API does not respond exactly the same way as it does within the workspace on the platform, even when using the threads API. It seems the handling is different.

Specifically, I believe the difference may be related to not considering document checks with embeddings. My system is a chat accessed externally via API. Initially, I used the workspace API (/chat), but I realized that all users were communicating in the same conversation. I solved this by creating a separate thread for each user.

However, the behavior is still not the same as inside AnythingLLM. My workspace is configured in query mode and contains documents in RAG. Another point is that the API returns too many emojis in conversations, which doesn't happen within the system.

My main question is: does the API actually handle things differently? Initially, I thought using the threads API would result in the exact same behavior, but it seems that's not the case.

Thanks in advance for any help or clarification.

Are there known steps to reproduce?

a thread in workspace with file embedded, a app calling the workspace api threads. same question, different answers.

@Peterson047 Peterson047 added the possible bug Bug was reported but is not confirmed or is unable to be replicated. label Oct 23, 2024
@timothycarambat
Copy link
Member

timothycarambat commented Oct 24, 2024

Do you know what image (and hash if possible) you are on? We made some edits recently to this functionality that may be able to explain the discrepancy.

@timothycarambat timothycarambat added the question Further information is requested label Oct 24, 2024
@Peterson047
Copy link
Author

Sorry, I'm using a version of the master tag from 7 weeks ago, since the last one is from 3 weeks ago, I thought the production server was with this version. I saw that a new version came out yesterday, I will test it in an environment and return with the feedback.

"Id": "sha256:984ed5766441e000a91fe61019204a814a83542836dc7ee76d78a39ebeac6276", "RepoTags": [ "mintplexlabs/anythingllm:master" ], "RepoDigests": [ "mintplexlabs/anythingllm@sha256:6bc0b731a15a9d933d52d7f575cc61aa6e1b7e0b77a2d9e1b0f7fc36285ac355", "mintplexlabs/anythingllm@sha256:d1a25203ac2b4af5d5ff691c304f17281cd6fd864c44c30f5ba531c7f134dbbf" ], "Parent": "", "Comment": "buildkit.dockerfile.v0", "Created": "2024-08-30T22:24:24.336182248Z",

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
possible bug Bug was reported but is not confirmed or is unable to be replicated. question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants