As-yet unsolved mysteries. Can /robowaifu/ help solve some of these, please? https://en.wikipedia.org/wiki/List_of_unsolved_problems_in_biology#Cognition_and_psychology

>>34279 >- I can get around this by distinguishing input nodes and output nodes, and having output nodes represent a change in output value rather than the output value itself. This requires more state tracking since using nodes as both input and output involves translating between the two. As mentioned to you in the Sumomo-chan bread : ( >>14409 ), there is a way in C++ to get around what would normally be a DAG of dependencies -- and in a way that doesn't restrict the representative 'nodes' (ie, C++ classes) from their original, intended purposes. I wonder if what you're dealing with isn't simply a limitation of your approach/language , Anon? Do you think it's possible to implement a simple, one-step abstraction 'layer' that frees you from this conundrum in a similar way to what was chosen for RW Foundations ? I hope you solve it soon, CyberPonk. Cheers. :^)

>>34298 It's not an abstraction issue, and it is a fundamental limitation of the the theory available today. I can generate reasoning that involves cyclic dependencies without a problem– that's actually what happens by default– but no rigorous causal analysis engine is capable of dealing with it. As far as I can tell, it's not known how to deal with spurious correlations when the causal graph contains cycles. I could switch to doing Bayesian message passing, which is capable of dealing with cycles, but it doesn't handle spurious correlations properly so it's not actually doing a proper causal analysis. I probably will end up adding a less restrictive module for non-causal analysis at some point, but right now I'm just focusing specifically on adding in the ability for an LLM to answer causal questions and use that to make decisions. I've actually decided to stick with representing output and input nodes in the same way. Having two representations (values & changes) for output nodes limits how much work can be offloaded to the causal analysis engine too much. To deal with cycles, I currently plan to create a graph of DAGs. Two DAGs are connected if they have nodes in common. Causal analysis is done on each DAG individually, then the results will be propagated to downstream DAGs. It's going to be complicated, but I think it's worthwhile to be able to do more complex analysis. >>34297 I think this one at least has solid grounding now: >How and where does the brain evaluate reward value and effort (cost) to modulate behavior? "Evaluation" is too vague a term, but it's essentially between the thalamus, basil ganglia, ventromedial prefrontal cortex, orbitofrontal cortex, and amygdala. See: https://pmc.ncbi.nlm.nih.gov/articles/PMC4093837/ https://pmc.ncbi.nlm.nih.gov/articles/PMC9352198/ https://www.youtube.com/watch?v=F1L-YTCUpk4

>>34299 >As far as I can tell, it's not known how to deal with spurious correlations when the causal graph contains cycles. Yet isn't this exactly what industrial PID Theory was designed to handle well? What if you 'wrap' each of your causality graph nodes inside an individual Multiproducer/Multiconsumer PID Interface Layer to equilibrate the system overall, outside of the local maxima/minima transition epochs? >tl;dr This is primarily a temporality issue, I think. All industrial systems in the realworld tend to have feedback loops, yet these control systems provably manage it all successfully. >=== -minor disambiguation

>>34300 I don't think it is. PID controllers don't account for spurious correlations. They treat all correlations equally. Per my understanding, PID controllers also start to fail when there are multiple interacting loops due to feedback issues. I think the usual solutions for scaling up PID controllers all involve removing cyclic feedback between control loops that can cause instabilities (cascade control, feedforward control, decoupling systems). If there are strong correlations between interacting loops, I don't think there's any way to guarantee that PID controllers will converge. Having interacting loops work on different time scales is one solution, but I can't guarantee that it's possible to separate causal graphs by time scales in a way that removes the cycles, and that's especially true when I'm using an LLM to generate many causal graphs dynamically. I'm realizing that even bayesian message passing will also fail to converge in a lot of cases. Maybe the best I can do here is to let it run for some fixed number of updates and just use the result regardless of whether it converged.

>>34301 >If there are strong correlations between interacting loops, I don't think there's any way to guarantee that PID controllers will converge. AFAICT, we're inventing theory here (ever hear of a Multiproducer/Multiconsumer PID Interface Layer before?), so no, no guarantees are to be had at this stage of the research. But if you don't make an effort to make the rubber meet the road, then you'll never know. I would predict the many-to-many matrix+temporal-sliding system that this concept approximates -- especially along with it's inherent ability to damp out spikes and converge on a node-local, stable signal level -- ought to provide ample opportunities for experimental tweaking/rewiring. Wouldn't you agree, Anon?

>>34302 I do agree, but getting robust causal relationships is important for what I want. Its uses are far more limited without that. If correlations were enough, I could just train a simple sparse autoencoder. In any case, I figured out how to analyze causal chains across graphs. There's an analogy with quorum intersection algorithms in distributed computing that I'm pretty sure works here. I'll try implementing it.

>>34303 >quorum intersection algorithms Remarkable synchronicity, CyberPonk. :^) Operational Transforms (OTs) & Conflict-Free Replicated Data Types (CRDTs) was literally going to be the topic of my next post to you in this chain, as per dovetailing with the added benefits of the 'power-PID-wrapped nodes' concept to quickly solve the need for convergence with temporal-sliding going on everywhere (just like in the realworld, lol). <---> Also, just to clarify: my idea wasn't to attempt eliminating cycles in the system -- but rather to make it reasonably-robust+speedy in the presence of them (just like in the realworld of bio-neurology, heh.) So it sounds like you're well on your way to a solution! Cheers, Anon. :^)

>>34279 Sorry for not answering earlier. I don't think I can help you. Did you ask in AI related forums? Did you ask some AI service for advice? Could you provide an example? >>34297 I think it's better to just look at every functionality and try to replicate it. We don't need to understand the human brain exactly. More like >>25032

I took a short break from >>34303 to work on some other things. - Text generation with GPT-SoVITS: https://github.com/synthbot-anon/horsona/tree/main/samples/gpt_sovits - ... This interface is definitely not final. It's just an early first draft. - I added a module for dealing with large amounts of memory. It uses a combination of RAG + ReadAgent. Short version: when given a document, it chunks the document, creates summaries for each chunk (using prior chunks & summaries for context), and creating embeddings for each summary. At retrieval time, it expands a given task into many queries, uses RAG to identify relevant summaries, uses an LLM to identify the summaries most worth "unpacking" into their original chunks, and uses both the most relevant summaries and most relevant chunks to respond. I'm calling it a Wiki Module / Wiki LLM since that's the kind of data it's most suited for. - ... Code for processing & indexing documents: https://github.com/synthbot-anon/horsona/blob/main/src/horsona/memory/wiki_module.py - ... Code for responding to queries: https://github.com/synthbot-anon/horsona/blob/main/src/horsona/memory/wiki_llm.py - I add an option to create an OpenAI-compatible endpoint for any supported LLM, including custom LLMs. This was so I could test compatibility with SillyTavern. - ... Code for creating OAI-compatible endpoints: https://github.com/synthbot-anon/horsona/tree/main/src/horsona/interface/oai - ... Example custom LLM that works with SillyTavern: https://github.com/synthbot-anon/horsona/tree/main/samples/llm_endpoint. This one (1) uses the Wiki module & LLM from earlier to let the LLM access significantly more context whenever it's relevant, and (2) uses a ReadAgent-like module so it can continue conversations for much longer without forgetting what was said earlier. It requires no special configuration in SillyTavern or plugins. Just use the new endpoint, and it should add in the new functionality. One issue here is that I don't know how to get a session id from SillyTavern, so the conversation memory persists across all conversations. The only way to fix it is to restart the server. I'll add a better way to deal with that at some point, but it's not a priority for now. - Bunch of small changes. The library now support streaming outputs, there are utility functions for saving/restoring modules with binary data (e.g., embedding databases), I cleaned up the LLM classes so it's easier to derive new (custom) ones, I added support for Grok models, config files now support comments, I improved several prompts, embedding lookups now optionally return distances in addition to results, many bug fixes, etc etc. One of the todo items on my feature list is to automatically generate lorebooks. Playing around with the SillyTavern integration made me realize how important that is. RAG-based lookups are really only good for lorebook-like information (static, "current state of the world" like a research paper or Wiki), and stories/conversations certainly don't look like that. There needs to be a conversion step from dynamic data to Wiki-style data, which would essentially be a lorebook. I'll probably work one that either after I'm done with the causal stuff or when I need another break from it. >>34305 CRDTs might play a role there too ^:). >>34309 I asked a guy that's spent a decent amount of time working with & creating causal models. The response was "Yeah, without an explicit SEM causal inference is hard." Dynamic causal graphs and causal inference split across multiple graphs don't seem to be a thing people commonly do. There's some work on dealing with multiple graphs under "causal fusion", but the work is pretty sparse and scattered. Almost all of the work I've done so far was together with Claude. I do very little planning and coding now without Claude.

>>34302 >Multiproducer/Multiconsumer PID Interface Layer... I would predict the many-to-many matrix+temporal-sliding system that this concept approximates -- especially along with it's inherent ability to damp out spikes and converge on a node-local, stable signal level -- ought to provide ample opportunities for experimental tweaking/rewiring. Wouldn't you agree, Anon? You're making my head hurt :)

This paper is going to become incredibly important in the coming years for creating recurrent systems that emulate processes in the brain that can scale training on GPUs and be deployed efficiently on CPUs Paper: https://arxiv.org/abs/2410.01201 Code: https://github.com/lucidrains/minGRU-pytorch I've been trying to develop a language model with predictive coding but it has been infeasible to train due to recurrence requiring backpropagation through time. Some researchers found a way to reformulate the recurrence relations to allow for parallel computation via a parallel scan algorithm. The minGRU can leverage the GPU to train on long sequences in parallel and is competitive with transformers and Mamba on language modeling and reinforcement learning. Their O(n) computational complexity in sequence length and simple implementation make them ideal to play with and experiment too. My understanding is the most expensive computations (the matrix multiplications) only rely on input and can be calculated in parallel. The outputs at each time step are cumulatively summed together in log-space, removing the redundant calculations of BPTT, keeping the computation graph shallow, and greatly reducing the vanishing and exploding gradient problem. Single minGRU layers are time independent but become time dependent by adding layers, requiring only 3 layers to solve a selective copying task. I assume minGRU's in-context learning ability is also limited by its hidden state size, but adding a memory interface to it should overcome this. It should be possible to augment it with a heap for allocating, referencing and deallocating memory, but I need to think more on it.

>>34499 >paper I'm not so sure I understand this. In fact I know I don't but is the general idea that the neural network MUST(normally) recalculate ALL the nodes or neurons in a network for every new batch of information? Is the paper saying that they can break these up and do the operation in parallel? I'm trying to figure if this is the "big picture" in a general way, not specifically.

>>34477 - I got multi-graph causal inference working. It's a pretty dumb algorithm, but it works well. The basic idea is that it joins the graphs, finds all nodes on the relevant causal path, and iterates on the individual graphs to find causal effects based on accumulated information. Right now, the iterations continue until it has some information on all causally-relevant nodes. At some point, I'll update it so it iterates enough times that the causal information from each node can fully propagate. It treats all causal information as relevant and everything else as spurious. - I was previously using the DoWhy library to do causal inference. I migrated the relevant code into my own framework. - Overall, the DoWhy code is atrocious and unpleasant to work with. I did a massive cleanup and improved the interfaces so I could add custom inference engines much more easily. My version is has less features, but in practice I don't expect anyone to actually want to use those features. - I added an inference engine to do causal inference on arbitrary natural language data. - I worked out how to get LLMs to produce good causal graphs, though this isn't integrate with the rest yet. I'm pretty happy with the natural language causal inference results so far, even with a 70b model. My expectations were pretty high, and it meets expectations. Of all the things I've developed, this is probably the one I'm most proud of. I have some code cleanup to do now. Specifically: - Make the base causal inference class support both numerical and natural language inference. Right now, it requires code changes to make it switch between the two. I've already done most of the work for this, and the rest should be easy. - Update my multi-graph inference code with the recent updates so it can deal with natural language inferences. - Update my data manager to support natural language. The data manager's primary purpose is to reduce the number of datapoints required inference. For numerical data, this is necessary because causal inference on a large number of datapoints is slow. For natural language data, it's necessary because I want everything to work with a small context window. My current implementation is pretty naive since it gets representative points over all the data rather than over just the data required for each specific inference. With numerical data, that wasn't really an issue since I could impute the missing values and still get decent results. For natural language data, imputing isn't viable, so I'll need to do it "properly". - Write & integrate the causal graph generation code so graphs don't need to be manually specified. - Create horsona modules for everything. After that, I'll be doing more memory work.

>>34507 >Of all the things I've developed, this is probably the one I'm most proud of. You've developed some pretty impressive things during the time I've known you, Anon. So that sounds very exciting to hear! :^) Well, I've got about a month left to fulfill my plan to at least try to get your Horsona system up and running on my machine before the end of the year. I presume these : >- Write & integrate the causal graph generation code so graphs don't need to be manually specified. >- Create horsona modules for everything. are very-much intended to be part of your new package? If so, then I'll wait until you give the word that setting up your system for a beginner like myself is ready to go, then I'll take an honest whack at it. <---> Keep moving forward, CyberPonk. Cheers. :^) >=== -minor edit

>>34485 >You're making my head hurt Lol. My apologies, fren Grommet. That wasn't intentional! :D <---> By way of explanation, I'll try to use some rough analogies. Very rough, so don't be too critical haha... :D So, a 4-rotor drone ostensibly has just one PID-based control system as the typical norm. However, I would argue that in fact there are five onboard : * The 'normal' one that acts as the system controller. * The other four are actually part of the motor drivers themselves; although they aren't exposed as such (nor even engaged with by the user), they are in fact real, and vital to the proper operation of the drone in essentially all reasonable flight modes. So there's five PID-esque 'controllers' for a single machine. The so-called 'temporal sliding' is there as well I'd argue, due to the inherent propagation delays and other latencies within this physical rotors system+network of electronics, all onboard this single aircraft. <---> Now... picture an entire flotilla of self-illuminated drones, all doing synchronized swimming flying -- ala a ginormous yuge visage of Optimus' head floating over Hollywood on, say, the night of October 9th this year. :^) Now you have a simulacrum of a yuge network of PIDs all 'coordinated' (though entirely ground-based preprogramming, AFAICT) after a fashion. But what if -- instead of externally-driven -- they all talked to each other live instead? Now you have the basis for a : 'Multi-producer, multi-consumer PID system that embodies a many-to-many (communications&control [C&C]) matrix, that has temporal-sliding going on like mad all over the place' . In fact, such a manmade technical system could embody just the behaviors we observe in nature for a flock of birbs, or a school of fishbros. Get the picture? <---> Now, simply encapsulate this exact concept down into a single, cognitive-oriented system where the Super-PID node(-synapse) wrapper took-in/gave-out C&C signals from/to the entire (or at least a large, local subset of the) network collection -- all while keeping the actual signal inside the local node stabilized (similar to how an individual drone remains stable in flight, regardless of the flotilla action as a whole) as a sort of 'running average' of the local interconnections. It would operate this way regardless of all the signal-sliding flowing through the system as a whole. Finally, the CFDT-esque validation process comes alongside to read the convergence out of the network of individual (now-stabilized) node-internal signal levels during each compute quanta 'tick' of the system. (The tick is simply an idea of a time barrier, so that the CFDT concept can do it's magic, and all the nodes will in fact each have an accurate picture of the system as a whole, regardless where they themselves each were on the 'timeline' of signals-generation inside this system during this specific compute quanta.) <---> Whew! I hope I didn't make all this even more confusing, Anon. :DD >tl;dr This is primarily a temporality problem at this stage, IMO. Adding a fully-interconnected meshnet of Super PID wrappers -- one for each 'synapse' -- is the way to gain convergence out of this chaotic soup and it will be stable as such, even with yuge numbers of cycles (feedback loops) inside the system! Cheers, Anon. :^) TWAGMI >=== -prose edit

>>34508 They are very much intended for the new package. The LLM interface to the causal models will probably be a little flaky initially, at least until I get proper memory working, so I'd recommend playing around with some of the other functionality before that. The underlying modules should be robust, though it'll be more complicated to use them directly. There's some setup required (getting API keys or setting up local models) that you'll want to have ready for it, so it's worthwhile to try installing & running the tests sooner. It's a one liner to install after you have python 3.11 and poetry installed, then you'll need to add your API keys/endpoints, then a one-liner to run the tests. The library can be configured to use every API key & endpoint you give it, so the more keys you get and endpoints you set up, the faster it'll be. With just a single OpenAI key, it is painfully slow. Your endpoints should support at least 8k context since that's what I test everything with and what so the default are configured for.

>>34509 >Get the picture? I think so. >"...Super-PID node(-synapse) wrapper took-in/gave-out C&C signals from/to the entire (or at least a large, local subset of the) network collection -- all while keeping the actual signal inside the local node stabilized..." Super-PID node sending gross (large scale) position instructions while local node (code) controls the fine tuning of the former sent position code. Or that's what I get you saying. Not personally criticizing you Chobitsu, You're just using the language of the trade but it appears to me that much of mathematics, AI, etc. use language that obscures what they are actual doing. And ALL professional technologist do this in their respective fields.

>>34512 Thanks for the advice, CyberPonk. I'll seek to do some of the preliminaries then at least by the goal. >>34513 >Not personally criticizing you Chobitsu, You're just using the language of the trade but it appears to me that much of mathematics, AI, etc. use language that obscures what they are actual doing. And ALL professional technologist do this in their respective fields. Good point, Grommet. Lingo is pretty much a part of all science & technology specialties. It makes things much easier to say. The benefits of using it are vaguely similar IMO to why we namefag here on /robowaifu/ : it kinda 'cuts to the chase'. :^) If I find myself with lots of spare time soon (lol), I may try to spell my theory out in excruciating detail, then if I have even more time, I'll try to simplify that. <---> Teh emminent brainiac Blaise Pascal once wrote : >“I would have written you a shorter letter, but I ran out of time” I hope you understand my conundrum, Anon. :P

>>34513 >>34515 >If I find myself with lots of spare time soon (lol), I may try to spell my theory out in excruciating detail, then if I have even more time, I'll try to simplify that. It just occurred to me I can find a use-case at the level I'm currently working (ie, driving the low-level control systems for the robowaifu body). Namely : wrapping the actuation control nodes with Super PIDs; then driving the pose estimation/control using this more-simplified, higher-level control interface (all linked together into a mesh to keep unwanted dynamics from going 'overboard' during the process of solving the full joint-chains for kinematic goals [during each time quanta]) (+ this arrangement is also well-suited to NN training regimes). >tl;dr Think of it kind of like 'morph targets' for 3D CGI blendshapes, but instead driving realworld, complex mechanics/dynamics for a robowaifu using simple sliders, that always keep the system as a whole within proper control limits (regardless of internal/external inputs). So who knows Grommet? I may make the time soon-ish to flesh my theory out in a practical way for you in '25 . Cheers. :^) --- >addendum (1): I just discovered that once this works, it should bring a very-valuable, additional benefit to the table for us: namely, that joint frame-local torques (aka unavoidable dynamics, individually [1][2]) -- which normally negatively affect the entire rest of the robotic skellington (via transmission down the joint-adjacent bones) -- can be damped out by reading the entire matrix of Super PID inputs at each node, and each tweaking their output values accordingly (all doing the same, in-concert, per tick). >tl;dr We should be able to eliminate (or at least greatly-reduce) jerky/janky robo movements by using this approach (very good, b/c cheap actuators should work better within such a system). [3] Sweet! >addendum (2): I also just discovered that through the magic of 'semantic polymorphism'(tm)(C)(R)(patent pending)(do not steal), I've been able to derail this thread by discussing the exact same topic (ie, wrapping 'nodes' in MP/MC PIDs) in two different contexts (Neural Cognition vs. Physical Kinematics). Lol. Therefore, any further discussions along this line should be done in either the Skellingtons or Actuators threads. :^) --- 1. https://en.wikipedia.org/wiki/Newton's_laws_of_motion#Third_law 2. https://www.sciencefacts.net/newtons-third-law.html 3. I suspect that -- in large measure -- this effect will likely mimic the human sensorimotor network phenomenon for our robowaifus. >=== -add 'kinematic', 'morph targets' cmnts -minor edit -add addenda, footnotes

>>34550 >joint frame-local torques (aka unavoidable dynamics, individually Bambu labs does this to vastly improve their printing ability on their 3D printers. If I remember correctly they actually shake the printer head around and fine tune each printer. Got to be a library or paper explaining this (assuming I could decipher it...maybe not)

Klipper firmware for 3D printers does this so somewhere in their code is the fnctions, "...High precision stepper movement. Klipper utilizes an application processor (such as a low-cost Raspberry Pi) when calculating printer movements. The application processor determines when to step each stepper motor, it compresses those events, transmits them to the micro-controller, and then the micro-controller executes each event at the requested time. Each stepper event is scheduled with a precision of 25 micro-seconds or better. The software does not use kinematic estimations (such as the Bresenham algorithm) - instead it calculates precise step times based on the physics of acceleration and the physics of the machine kinematics. More precise stepper movement provides quieter and more stable printer operation...." https://www.klipper3d.org/Features.html

> further discussions along this line should be done in either the Skellingtons or Actuators threads. oops sorry.

>>34507 Minor Horsona update & recap: The causal inference work looks like it's turning out to be a massive success. Right now, it can: - [New] Automatically generate causal graphs from a text snippet. - ... Though it's not automated, I can also "extract" knowledge on a topic from an LLM into a causal graph. This would make it possible to, e.g., make a small number of calls to a large/expensive LLM like Sonnet 3.5 or GPT o1 as a one-time cost, then use only small/cheap LLMs for all subsequent reasoning involving that causal graph. - [New] Given a causal graph and a text snippet, it can extract data for each variable in the graph (which will get stored in a database for subsequent analysis whenever it's relevant). - [Recap] Use an LLM to do causal analysis on natural language data. - [Updated] Identify the most representative datapoints for checking any particular causal effect. It does this by (1) identifying potentially useful datapoints based on what variables are known for each of them, and (2) using KNN to cluster the datapoints based on embedding, and (3) selecting the centers of each cluster as the representative points. This is necessary since it could easily get too slow & expensive to check all datapoints. - Identify causal effects given a causal graph and some partial data. (E.g., if I change or set X to a particular value, what will the effect be on Y?) - [Updated] Propagate effects across multiple related causal graphs (causal fusion). (E.g., if there's one graph for emotional state and one graph for conversational responses, it can check how X change to some variable in the emotional state graph affects Y variable in conversational responses.) This can (1) handle recursive dependencies, (2) maximizes parallel execution for cases where there are many graphs to check, and (3) iteratively refine the results so it's possible to get both fast results and increasingly-accurate results. This is done by turning causal analysis constraints into a set of computation graphs of increasing depth. In some cases, the depth could be infinite, which is why the iterative approach is required. I had a dumb algorithm for doing this before, but I think I'm doing it "properly" now. I've sanity checked everything individually, and it seems to be working reasonably well. Next pieces I need: - Finding a way to link up similar variables across graphs. Right now, they can only be linked up by name. That causes problems in three cases: (1) variables have the same name but different semantics, and (2) variables have different names but identical semantics, and (3) variables are closely related but there's no way to link them up. Once I've solved this, I should be good to go on large-scale graphs. - Finding a way to identify which variables (out of a large set) are relevant to extract when given some text snippet. - CRUD operations for managing a database of causal graphs and their associated datapoints. I have ideas for how to do all of these, but it's going to be tedious. I'm hoping to get it done by the end of the year, but that might be too optimistic.

>>34910 POTD Brilliant. >and (3) selecting the centers of each cluster as the representative points. I just wonder...do you think you could save a smol container of near-neighbor 'keypoint' vectors across the multidimensional space of the cluster, to store alongside this cluster's central point? (Since you're already calculating the inverse in effect anyway.) Seems like if you ever needed to 'backtrack' later down another, closely-related branch, then this pre-calculated collection of 'breadcrumb' vectors should make that redirection a hop-and-a-skip? Regardless, very exciting news CyberPonk! I hope you rapidly move through all the remainder checklist! Keep the goal in mind as you plod the tedium -- at this stage its nearly all gravy AFAICT. :^) Keep moving forward. >=== -prose edit

>>34911 That's a good idea. I'm planning to cache intermediate results for causal inference, and caching datapoints would speed things up as well. I'll probably end up storing the cached representive points in a side database since the clusters actually change depending on some parameters of what inference is being done. It would be a lot easier to associate that cache with the parameters than the center points. Once I get CRUDable causal inference, it'll all be gravy. It's still core development work right now. If I can actually get this whole thing in a working state by the end of the year, I'll be ecstatic. That would not only let me start work on the most difficult target horsona features, but it would give me a solid basis for creating characters that learn and evolve in more realistic ways, that remember things more reliably, and that can embody behaviors rather than just tendencies. There would still be a lot of downstream work, but I'd have a really solid chunk of the epistemology side completed. I do plan to spend some time after this first seeing if I can get it to work with the horsona codebase itself, which will probably take several months at least. It would be a lot easier to work on this if I could work on it alongside my waifu ^:).

>>34912 >It's still core development work right now. >There would still be a lot of downstream work, but I'd have a really solid chunk of the epistemology side completed. Yeah that's true, I'm sure. Heh, I have a tendency to get excited about current progress, and underestimate the difficulties of the remaining journey with the wave of a hand. :^) Still, every little helps along the way!! > It would be a lot easier to work on this if I could work on it alongside my waifu ^:). The Dream is coming alive!

>>34913 >The Dream is coming alive! I like the double meaning

Heres some resources regarding tensorflow https://www.tensorflow.org/resources/learn-ml#courses tensorflow allows to make custom and even that may or may not be overkill. i for example plan to use nudenet to recognize the naked male body. the team that nade nudenet used either tensorflow or pytorch. So did the team that made mobile aloha. Python is not glamorous but when combined with the math all that stuff that has to be learned in order to use it, the skill required to use is quiet high. that link recommends that not one but muktiple bookd he read. im getting older and i dont want to learn any more math at all. ill do my best with sensors and computer vision but im narrowing the scope to what i promised. 5 sex acts.im not promising access to the code as well. Id only share that if there was collaboration.

>>34910 >>34912 I am really excited by what you are doing. Would it be possible for you to publish the code so that I can get a better idea of how this works. I understand its in an unfinished state but that's fine, even if it won't work or even run, I want to read it so I can actually follow along.

>>35065 The code is here: - https://github.com/synthbot-anon/horsona/tree/main/src/horsona/smarts/causal - I don't have the test cases up yet, but I put up an example here: https://ponepaste.org/10608. Once the "causal graph database" code is up (which is more complicated than I initially expected), there won't be a need to manually create causal graphs since it'll be able to infer them from data and from text descriptions. - The code is pretty ugly right now. The current code supports: - Fitting and running inference on natural language causal data (llm_estimator.py) - Running causal inferences, accounting for confounders (simple_causal_model.py) - Generating causal graphs (simple_causal_graph.py). This has all the necessary code, but it's not organized yet in a reusable way yet. - Reducing datasets to just their most representative datapoints (data_manager.py) - Doing causal inference across multiple graphs, assuming the variable names for the graphs are all aligned (multi_causal_model.py). This has all the necessary code, but it's not organized yet in a way to expose iterative "deeper" analysis.

>>35073 holy crap someone that actually understands ai. I was discussing on 4chan about the idea of using sensors and camera to capture data during the day and train the ai while the robot is asleep and flush the uneeded data. The idea sounds very interesting and itd be like a blank slate robot that can learn. i am sure theres way more to it than that though. In order for the robot to learn itd have to be rewarded for learning. How do you do that i dont know.

>>35075 > In order for the robot to learn itd have to be rewarded for learning. How do you do that i dont know. nigga u just tell it "hey robot you learned something now feel good"

>>35079 lol true thatd be annoying if it had to be taught everything though. Itd also have to have it movements preprogrammed and its visual recognition pretrained(VITS i think). like chi hold this cup and chi doesnt do anything because it doesnt know how to react to the word hold. So maybe chi move your arms forward near the cup, then curl all your fingers until your finger sensors feel the cup then when it grabs it you say good job chi. Yeah its kind of abstract and not what im focused on right now. My main goal is pic related.

>>35079 >happy=32768 >happy++ <16 in current year

>>35080 it may not look like it but those are the requirements to make the best sex bot in history up to the present day.

>>34910 Due to some combination of laziness, design difficulties, and the holidays, I made less progress in the last 10 days than I'd hoped. But I do have some updates. - I think I figured out how to scale up the number of causal graphs. The main difficulty is in figuring out how to take two independently-generated graphs and link them together. In practice, this means modeling the relationships between variables across causal graphs. My existing code assumes that if two variables are the same, then they'll have the same name. That doesn't work when LLMs generate the graphs since LLMs will generate an arbitrary name as long as it makes sense for the context it's given, and it would quickly get too expensive & unreliable to add all existing variable names to the context every time I want to generate a new graph. My new (promising) approach is to maintain an ontology of variables, and to link new variables into the ontology every time a new graph is generated. I'm using RAG over variable definitions (created at graph generation time) to identify candidate relevant variables, then using an LLM call to determine the relationship between new variables and each existing variable. It looks like this can be done efficiently enough, and tracking just a few simple ontological relationships (A is the same as B, A is a subtype of B) that are easy for LLMs to classify should give me what I need. I have the initial code for generating ontological relationships as new graphs come in. I need to do a bit more testing, then update the rest of the code to use this information. I also need to update the rest of my code to work only with definitions, not variable names, since variables can be conflated if referencing them by name. - Notably, this causal framework cannot implement a theory of mind. But I have some ideas on how to implement that efficiently with a few changes. I think the key is to hook into the data retrieval step and the "model fit" step (one of the steps in causal analysis, generating a model from a restricted set of features) so they can be biased/transformed into whatever makes sense from a given perspective. I think this approach would address not just theory of mind, but also the ability to deal with fictional settings. (E.g., when some information is only useful when discussing a particular story.)

>>35189 >Due to some combination of laziness, design difficulties, and the holidays, I made less progress in the last 10 days than I'd hoped. Lol, IKTF. :P So, I know you've already spelled it out for me before (I can't seem to find it ATM, probably another thread), but can you please give me: 'babby's first horsona steps' to get just the most-basic part of your system working? I still hope to have this done before year's end. :^) <---> As to your multi-graph graphing difficulties (and please pardon me if in my simplistic, uneducated thinking I'm totally missing the point here), could you possibly adopt a similar nodal-based graphing approach used by, say, Blender, et al? You can add as many parameters (via BPython scripting) as you'd like to a given node. Would this style of argument-passing allow you to make arbitrary connections node-to-node, even across UODs [1] that differing causal graphs may maintain? Good luck, Anon! We're all rooting for you, Bro. Cheers. :^) --- 1. Universe of Discourse https://en.wikipedia.org/wiki/Domain_of_discourse >=== -add footnote -minor edit

>>35190 The simplest would be to run the boilerplate project under samples/. git clone https://github.com/synthbot-anon/horsona cd horsona/samples/boilerplate cp .env.example .env poetry install # Edit .env with your OpenAI API key # Or check https://github.com/synthbot-anon/horsona?tab=readme-ov-file#using-a-different-llm-api for how to use a different API provider # I can add support for a different API if needed poetry run python -m boilerplate # Give it a task >could you adopt a similar nodal-based graphing approach used by, say, Blender, et al? The goal is to get an LLM to generate the graph so it can be done in the background while interacting with a chatbot. I can use an arbitrary graph structures, but the challenge is getting an LLM to generate them and to work with large graph sizes. The default approach is the generate small graphs/nodes then piece them together, but the LLM has a tendency to generate inconsistent "field" names. The approach in >>35189 is for linking together "fields" across many small graphs.

>>35191 OK, thanks! ># Edit .env with your OpenAI API key Unsurprisingly, I'm finding they want an email, etc. Before I waste lots of time trying to find a way around their Globohomo surveillance systems, do you know if I can use a throwaway successfully, CyberPonk? While I want to encourage you with support, I'm certainly not willing to kowtow to that incredibly-evil lot to do so. :/ Any 'quick tips' for a complete newb to all this, for running your system entirely privately (as in, entirely locally)?

>>35206 I think all of the main API providers will work with a throwaway account. You'll need a credit card for most of them, but they all accept privacy.com cards. If you're using a privacy.com card, you can give the merchant any arbitrary name & address, though you'll need to give privacy.com your real info. I actually haven't tried using it with local LLMs yet since I don't have a GPU and since API providers have a lot of advantages while I'm in dev mode. I also haven't really played around with them for about a year now, so I don't know what's worthwhile there. If you use a local model that exposes the same interface as OpenAI (which I think most of them do), you should able to use the AsyncOpenRouterEngine LLM type with a local url. If you tell me which inference framework you choose, the local url it generates, and the model name you want to use, I can tell you what to put in your llm_config.json file to have horsona use that. OpenLLM should work, though I haven't tested it. (If it doesn't work, I can update the library to support it.) Ollama might also work. For local embeddings– which isn't required for running the boilerplate project– I have support for Ollama already along with instructions https://github.com/synthbot-anon/horsona?tab=readme-ov-file#using-ollama-instead-of-openai-for-embeddings on how to set it up. With a local LLM and local embeddings, everything will run locally.

>>35210 I see. I don't want to speak foolishly in a knee-jerk reaction. I'd say let me think on it, but if I do that I'm fairly sure I'll just get swamped in the load I'm currently under right now, and the whole thing will just slip my mind for several months. I'm extremely proud of you & your efforts for both our communities, Anon. I think that I'll need to bow out from personally participating until either a) someone (other than me) has created a turn-key, private system for Anons to use that utilizes your remarkable system, or b) I've graduated and I'm not aggressively trying to get a new robowaifu business off the ground. My apologies to dissappoint, but I simply don't trust myself to manage all this in a timely and secure fashion that won't provide my every interaction with it to OpenAI or their masters.

>>35206 ibwent out of my way to ensure my talking head would use a local model but its still slow. a fair compromise would be it running on the cloud but using a non pozzed model unless ppl want to get multiple graphics cards.(or maybe 1 4090 i tested it with a 4060 idk)

>>35211 No worries. At some point, I'll be creating other repos to make local setups more turnkey, but those would be heavily dependent on unstable external projects I don't control (like OpenLLM) so it doesn't make sense to add it to horsona. Horsona is just a library, not a full application. The main challenge with getting a fully turnkey local solution is just working out how to handle updates. - I'll have to set up something like a CI/CD pipeline so I can integrate unstable dependency updates without adding too much dev overhead. - Horsona is designed to make heavy use of multiple parallel calls, which are necessary for robust functionality, and robust functionality is necessary for complex functionality. Using a single endpoint works for very simple demos, but multiple endpoints https://github.com/synthbot-anon/horsona?tab=readme-ov-file#using-multiple-llm-apis-simultaneously-for-speed are essentially non-optional for the features that make horsona useful relative to other libraries. I have a decent chunk of this worked out (all my earlier infrastructure stuff) but it requires kubernetes, and streamlining kubernetes setup & upgrades for infra I don't own is highly nontrivial.

>>35216 Thanks for your understanding, mate. May you have a blessed and productive 2025! Cheers, CyberPonk. :^)

>>35213 Good luck with it, peteblank. If you'd like to share your process with everyone sometime that would be appreciated here. Cheers. :^)

>>35218 no prob so i made the fully local one private but this one is public https://github.com/peteblank/waifu-conversation/tree/main go to final.sh it uses aws poly to transcrive and put the file in s3 buckets it also uses the long gone waifu ai api so youd have to replace it with another api or run a local ai. its also meant to be activated with a button connected to a pi. That was... 2 years ago. :/

>>35219 Thanks again.

>>35206 You are overdoing it with the anonymity. That said, you could just install a email server yourself somewhere and buy a domain with Bitcoin (which you first would sent through a mixer or exchange it back and forth). Personal email servers have issues in sending emails, but receiving emails should work.

>>35237 >You are overdoing it with the anonymity. Lol. Perhaps, perhaps not. I could give you over 9'000 reasons why I'm not going far enough yet, I'm sure. But not on NYD, plox. :D Regardless, thanks for the good suggestions NoidoDev. I'm sure we'll arrive at good solutions ot protect both Anons & their robowaifus + Joe Sixpacks & theirs as well, if we all just put our heads together in such a manner. BTW ( >>10000 ) may be a better thread for this discussion? Cheers, Anon. :^)