this aspect of honcho is focused on the best way to make use of the user representation. it’s primarily product-focused. this is what we’ll have to help clients with. there will likely be best practices that we can put forth through our usage, but i’m sure implementations will vary greatly. gets even more complex when we network applications and security + user controls become important
Post Raise Summer ‘24
In exploring this vector-based approach, Claude has suggested ways for us to enable people to use these single vector based representations:
In this sense, a user could send an index-range of messages that we could run ToM prediction on, and we potentially use the user-vector + some “temperature” value to act as a gauge for how wacky the thought is. this is exciting to me because it gives the user some knobs to play with i.r.t. the social cognition their app displays. this could be a really interesting product appeal.
if we’re to generate the response as well, then we have a direct impact on the wackiness. in the scenario above, the application can just choose not to listen to us or sample again. there would be some implementation challenges due to all the different types of models people could be using. could probably just support a specific subset of popular ones, but we should also know which ones these vectors work well with.
Historical Recap
Up and to this point (2024-07-15), the way we’ve been using the user representation has been by retrieving over it. we’ve built a RAG agent that sits on top of per-user vector stores and fields queries via our dialectic API endpoint.