-
Notifications
You must be signed in to change notification settings - Fork 4.1k
Fix Mem0 OSS #2604
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
Fix Mem0 OSS #2604
Conversation
if not hasattr(self.memory, "llm"): | ||
params["output_format"] = "v1.1" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
qq, double checking..
If the memory does not support llm, you set output_format
, right? But I noticed there’s another logic at line 121 in the search method over there, you’re doing: “if memory has llm, delete parameters”
That feels a bit confusing. Can you confirm if that’s expected behavior, or if we might need to align those two cases?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@lucasgomide, I think what's happening in here is a class comparision, whether the memory object belongs to Memory or Memory Client
Basically MemoryClient does not have any llm attribute to it, so the first check is to make sure that if self.memory
is not a MemoryClient class object, we need to have a parameter called output_format
. and in the second case check I believe they are checking whether it's a object of Memory class, and if yes then we do not need this parameter.
Bit confusing how mem0
is configured.
Still author can confirm more on this.
One suggestion from my side would be if I am right about class comparision, would be to that there are better way to check whether a object belongs to a particular class, like isinstance
, I think better to use this for better code visibility. Lucas can surely add more context on this part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Vidit-Ostwal I also prefer class comparison, but even after changing it, the question remains… I’m asking because the test didn’t confirm that.
From reading this line, I expected that when running with Memory, the output_format shouldn’t be included in the add()
parameters - but is not happing (on test at least)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Dev-Khant can you help with that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @lucasgomide,
output_format="v1.1"
-> {"results": }
output_format="v1.0"
-> []
We’ve now fully deprecated the output_format
parameter from the OSS version, though it’s still in the process of being removed from the Platform. To maintain consistency in output format, I’ve added output_format="v1.1"
on line 92.
On line 121, there's a check to determine if the call is targeting OSS. If so, it removes the output_format
parameter since it's deprecated in OSS but still required for the Platform or Mem0 client.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Dev-Khant that is the point..
It's a bit tricky because in your tests
both implementation are propagating output_format
, but by reading your code it should be sent ONLY when the memory does not has llm
.
This is the last touchable point that isnot clear to me
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @lucasgomide Then can you please help with the test?
Hi @Dev-Khant, I have made some changes and raised a PR for the same, can you merge those changes, so that they reflect here as well. |
Where exactly have you raised it? |
|
Hey @Vidit-Ostwal Thanks a lot for making the changes. @lucasgomide Can you please review it now and let us know if any more changes are needed? Thanks! |
Happy to collaborate. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thank your for your collaboration @Dev-Khant and @Vidit-Ostwal
The tests are now more intuitive.
Thanks @lucasgomide for approving. Also can we get this merged soon as many users have reported to face this issue. |
Heading to merge it tomorrow by the morning |
@Dev-Khant we just cut a new version, do you mind sync your branch again? I can’t sync.. otherwise I won’t be allowed to merge |
Hey @lucasgomide I have fixed the lock file. |
Closes #2599