[ot][spam][crazy][corporate[ makingeasy useful tools/behabior/agi?
basic part: combining relevent information with a task {mostly due to model ctxs staying small} make everything a docqa. use relevant information for every task
relevance is super nice for me to see in front of me and puzzle about because i have severe issues with it cognitively. some days ago i made a summary of steps of connecting relevance that made helpful analogue part between cognition and prompts another idea is an equivalence between trained models and prompted models: when you run a relevance strategy by prompting pretrained models, this can of course be transformed into a larger architecture where each prompt is a component of a model, and the same could be transformed back. holding this equivalence helps show different relevence structures and things like parallelism, order, and feedback. for retrieval a basic idea is to run over (or process in parallel) likely candidates looking for relevant summaries, then to run over them again with the new information is context to pick up anything that wasn’t clearly relevant before, until nothing new is added. additionally each prompt or node could include reports on how to move forward: whether or not to look again for example (misplaced some of these ideas maybe near the top of this paragraph or end of the previous one) for storing memories, a system could go over an existing store and judge if each part is a good place for new summarized information, or alternatively judge that a new part should be made, and then use normal retrieval. in general i think it would be very nice to make a general relevance library, agnostic to strategy or whether it uses prompted pretrained models or model training or some other approach. :)
here are part of the relevance notes from the 3rd. leaving these open on a terminal was likely one of the things that helped me rebuild the ability to think of it.
i’d like to describe the baby computer relevance pattern we engaged recently. 1. information is converted to embeddings and stored in a vector cloud. 2. when a task is performed, the task is also converted to embeddings, and nearby points retrieved from the vector cloud 3. each retrieved information is paired with the task, and a tiny summary is made of what is relevant to the task. 4. the tiny summaries are collected together with the task, and it is performed in context with them.
something i am adding today is that if there is a feedback loop around 3 then it seems much more reasonable to make the system consistent and flexible and correct. after i made the above vectordb notes i learned that langchain also has many non-vectordb approaches that basically involve manually processing each chunk. one could describe a vectordb as a heuristic for what regions to consider, analogous to a heuristic that formed tiny summaries of the regions for purpose of considering them, and then selected from among those summaries, with optional hierarchy. something else that it turns out langchain has is a pluggable and composable interface for memory, so you can add memory strategies in and transparently treat short context models as if they are long context, or as if they have access to external data. it all of course takes dev work. [it seems a valuable concept for things that effectively accelerate such too.]
participants (1)
-
Undescribed Horrific Abuse, One Victim & Survivor of Many