Replies: 1 comment 2 replies
-
Oh AMDN...so either a single token captures a bunch of actions, or it doesn't. If it does, then we need to modify it so that the token creation takes those multiple steps. Given that the tokenization has to happen at a higher level anyway (trace level and not on the individual steps), perhaps this is ok? Only other option would be for the observation token to be associated with a single action, and have the extra info in the observation that indicates what parallel action it's a part of. Less-than-ideal I reckon... |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi there,
My question concerns
Observation
tokens - all of them take aStep
as a parameter, and this is even expected in functions like thetokenize
function inTrace
(which ideally should be able to convert the steps in a trace to any type ofObservation
Token). This makes sense and so far has also allowed for some nice inheritance structures between theObservation
classes.The problem arises with the AMDN tokens, which I'm currently constructing. These can't take a
Step
as a parameter becauseStep
doesn't have the capacity to hold the information the tokens need (in this case, sets of actions instead of a single action). Obviously modifying the ground truthStep
is out of the question (I also imagine this problem could also arise again in the future as the extraction techniques continue to get more complex and the tokens require different things, so it would also only be a temporary hack).I don't think we want to sacrifice having
Step
as a unified parameter forObservation
token types, because:But that leaves the question of what to do about AMDN tokens.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions