Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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): Condensation events to reconstruct contexts added to event stream #7353
(fix): Condensation events to reconstruct contexts added to event stream #7353
Changes from 44 commits
f6f2a71
5ceaeaa
e07f57a
4eb73ae
345cd44
6588e35
1da4e8d
ea280a2
a6102eb
7ab7feb
f9561f9
5ec4e58
46c5d3b
1eed189
d85a423
e0d9781
facb4e7
e04ea81
2f5e104
6092fce
1bb75d2
894adca
e6fd3e1
7fd10c5
2d9e790
119c6bb
5750bfe
e9d054d
c28bc63
4ee94f3
0d1e9e4
d1ff924
397cc47
ecfbb4c
1d37b8b
b7c0a1c
307ea48
88a9d35
1be62b0
a411d2f
5f04259
f4039cb
f3812e7
1a1424a
0d9e7ed
00f4f17
eb12df8
d10137b
7f6f31a
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Reading this class again, do we actually need these two code paths? Couldn't we just do the first one and the functionality would be a superset of the second one? Sure it'd be a little bit less efficient memory-wise, but storing a list of ints is not really a big deal I think.
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.
The first path is a functional super-set of the second, yes. Engel expressed concerns about the size of the messages so I added the suggested range representation as an optimization. I don't have numbers on how much it saves but I think the overall memory impact is minor either way (maybe ~0.1% of the data in the whole trajectory?).
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.
Yes, I'm sorry, it may be just me and my inefficiency hate: they're consecutive, so unnecessary and they would be saved/read in every condensation action. 🥹 They would also be sent via websocket.
Our usual case is the summarizer, where they're consecutive. In fact, all of them, except for
llm_attention
, specify, at most, a range: fromstart
toend
.IMHO a way to represent these would be with polymorphism and discriminated union. But the event stream is "flat". When we represented this kind of case before, we made a flattened representation with an enum as discriminator for serialization and some validation, and an umbrella class for the necessary fields. Calvin doesn't like that, quite understandably - and here they would be more than two. 😅
This is an umbrella class, but with just minimal options, which is two. It's a middle-ground I'm happy with, but maybe it's bad?
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.
Yeah, personally I think code complexity is worse than small amounts of inefficiency. But it's not a hill that I'll die on :)
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.
Ah, yes, I also noticed again while rebuilding lists that this is completely reasonable, but for the condense actions themselves. They will be in the stream/history interweaved with the last big list to be forgotten.
This isn't just an assumption, it's by definition. We can define the start id and end id to be the range between which most condensers (the exception being attention) have their forgotten events in that step.
In fact, whether we need the other condense actions is a question for the condenser implementation. Outside the condensers, if we want to send them to the agent LLM, we can pick them up. They're in the stream, so they're in history, so we don't, strictly speaking, need the condensers to also provide those, we can pick them up if we want.
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.
Just to confirm so we can resolve this comment -- all event IDs are ordered monotonically increasing as they get added to the event stream? So if
event_i
is added to the event stream, thenevent_j
is added, it will always be the case thatevent_i.id < event_j.id
?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.
Yes. The stream itself assigns ids in ascending order, in the
add_event
method, which is the only way to do it, and the_id
field is otherwise never set.