You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A design goal that I never really wrote down or achieved is that Feedback Objects should be JSON serializable. This was to be important for data analysis, since we could dump a list of the considered feedback and process it later. But currently, non-serializable python objects are getting dumped too, and sometimes recursive data structures end up in there, and generally it just isn't reliable right now.
This is a problem for the newly proposed alchemy resolver, which might be planning to send all of the Report to a backend in order to hand it off to GPT or some other LLM. We'll need to be able to reliably (and compactly?) send the entire Report, or at least all the good bits.
The first step will be to review all of the existing feedback functions and inventory them to see who is offending and who is not. I assume there will not be a simple solution, but I expect that we can implement a kind of "data allowlist" for the fields of FFs. Basically, we mark what fields ARE safe to send and use that list to do the serialization instead of just assuming we can bundle up everything. It's possible that this can be done safely automatically, but I suspect in practice we need to be intentional in some places.
The text was updated successfully, but these errors were encountered:
A design goal that I never really wrote down or achieved is that Feedback Objects should be JSON serializable. This was to be important for data analysis, since we could dump a list of the considered feedback and process it later. But currently, non-serializable python objects are getting dumped too, and sometimes recursive data structures end up in there, and generally it just isn't reliable right now.
This is a problem for the newly proposed
alchemy
resolver, which might be planning to send all of theReport
to a backend in order to hand it off toGPT
or some other LLM. We'll need to be able to reliably (and compactly?) send the entireReport
, or at least all the good bits.The first step will be to review all of the existing feedback functions and inventory them to see who is offending and who is not. I assume there will not be a simple solution, but I expect that we can implement a kind of "data allowlist" for the fields of FFs. Basically, we mark what fields ARE safe to send and use that list to do the serialization instead of just assuming we can bundle up everything. It's possible that this can be done safely automatically, but I suspect in practice we need to be intentional in some places.
The text was updated successfully, but these errors were encountered: