Doctoral researcher in adaptive LLMs at the Institute of Robotics, Bulgarian Academy of Sciences. Also a backend engineer with 20+ years in production. MSc in AI & Data Processing.
Good question, and honestly the harder one. "Did the conversation work" is close to unmeasurable in any clean way, so I don't think that's where a kill gate belongs for a social robot. The dark side, as I see it starting this PhD, is continual learning: a robot that interacts over weeks or months keeps trying to pick up new parameters (new faces, new routines, new preferences) without that update quietly wrecking something it already knew. That's where a kill gate actually has a number to sit on: does updating on today's interaction preserve yesterday's behavior within some threshold, not whether today's conversation felt good.
I've only tested that question on a toy problem so far, not a robot: a registered EWC vs flat L2 comparison on Permuted MNIST. Same retention on the old task, reached at wildly different cost to learning the new one. That gap, retention per unit of plasticity spent, is the axis I'd want a kill gate on for anything that keeps learning in the wild. Translating it to a system juggling many different interaction parameters at once, instead of two sequential tasks, is the open problem in front of me right now. No answer yet.
One thing I'm already fairly sure of: that threshold has to come from the science itself, never from whatever a product roadmap decides to call success. The moment an external target gets to define "retained enough", the architecture quietly bends toward hitting that number instead of answering the real question. Same discipline your tool applies to "fixed", just one level up.
Bite is a sharp idea, by the way. Reverting the claimed fix and making the change prove itself under a real test is exactly the kind of check that should exist for every "fixed" commit. Starred it.
Thank you for the star, that's Bite's very first one! 🙌
Your point about the number coming from the science and not the roadmap really landed. It's the same trap with "fixed": if the commit gets to decide what counts as fixed, it will always pass. And a robot quietly forgetting yesterday's behavior sounds a lot like a fix that quietly breaks something old.
Good luck with the open problem. I'd read that post when you write it.
Reverting the claimed fix and making the change prove itself under a real test is exactly the kind of check that should exist for every ‘fixed’ commit.
Mind if I quote that on Bite's README, credited to you by name?
Doctoral researcher in adaptive LLMs at the Institute of Robotics, Bulgarian Academy of Sciences. Also a backend engineer with 20+ years in production. MSc in AI & Data Processing.
Go for it, quote away. A link back to zdravkov.info would be nice if it fits naturally in the README, but that's your call, don't force it in. Good luck with Bite.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Good question, and honestly the harder one. "Did the conversation work" is close to unmeasurable in any clean way, so I don't think that's where a kill gate belongs for a social robot. The dark side, as I see it starting this PhD, is continual learning: a robot that interacts over weeks or months keeps trying to pick up new parameters (new faces, new routines, new preferences) without that update quietly wrecking something it already knew. That's where a kill gate actually has a number to sit on: does updating on today's interaction preserve yesterday's behavior within some threshold, not whether today's conversation felt good.
I've only tested that question on a toy problem so far, not a robot: a registered EWC vs flat L2 comparison on Permuted MNIST. Same retention on the old task, reached at wildly different cost to learning the new one. That gap, retention per unit of plasticity spent, is the axis I'd want a kill gate on for anything that keeps learning in the wild. Translating it to a system juggling many different interaction parameters at once, instead of two sequential tasks, is the open problem in front of me right now. No answer yet.
One thing I'm already fairly sure of: that threshold has to come from the science itself, never from whatever a product roadmap decides to call success. The moment an external target gets to define "retained enough", the architecture quietly bends toward hitting that number instead of answering the real question. Same discipline your tool applies to "fixed", just one level up.
Bite is a sharp idea, by the way. Reverting the claimed fix and making the change prove itself under a real test is exactly the kind of check that should exist for every "fixed" commit. Starred it.
Thank you for the star, that's Bite's very first one! 🙌
Your point about the number coming from the science and not the roadmap really landed. It's the same trap with "fixed": if the commit gets to decide what counts as fixed, it will always pass. And a robot quietly forgetting yesterday's behavior sounds a lot like a fix that quietly breaks something old.
Good luck with the open problem. I'd read that post when you write it.
Mind if I quote that on Bite's README, credited to you by name?
Go for it, quote away. A link back to zdravkov.info would be nice if it fits naturally in the README, but that's your call, don't force it in. Good luck with Bite.