Socratic Dialogue

[TomLucidor]

Some criteria for Socratic Dialogue:

• Having chatbots of opposite sides read media with their own bias/preference using document RAGs and web-crawling tools
• Making a third moderator agent that prevents self-contradiction or incoherence by either side
• Converging conversation such that compromise can be reached, or all arguments have been exhausted
• Recording major arguments into PKM tools such that they can be recapped
• Goalpost-moving and concession-making should be an optional feature

Possible reference:

• https://github.com/RunzheYang/SocraticAI
• https://github.com/GiovanniGatti/socratic-llm

[rmusser01]

Thank you for the suggestion, this sounds good.

I think the best way to implement it would be through the chat workflows functionality, as it allows for a structured dialogue, turn-by-turn, and with a little tweaking could be extended to support answering by an LLM, so that a user may select a customized workflow, user enters a topic/question, and then the question/topic is discussed by the LLM with the user or with another LLM. It should also be possible to specify in the workflow configuration file that a third party LLM is used after every discussion round for moderation.

The question of 'enough' is a little harder though.

Moving chats into a PKM would line up with aforementioned syncing with Obsidian.

Goalposts and concessions could be handled through the moderator's instructions in the workflow configuration.

[TomLucidor]

True, when it comes to the idea of "enough" I think of two scenarios:

• both sides accepting of reality and facts, agree to disagree on grounds principle differences
• stalemate on inability to converge on definitions interpreting facts, or refusal to share observational reality

Probably prompt engineering requires a different features ala AutoPrompt and such

[rmusser01]

This is now being tracked under issue #498

[TomLucidor]

I kinda wanted to use the discussion pages to dissect the hell outta each of the major component of the ideal second brain, which is I tend to try and avoid the issues pages. There are not enough descriptions/summarizes or derivative thoughts/questions for each link being brought in. Issues doing feature improvement should be broken down at a component level rather than an architectural level?

[rmusser01]

Yea, I would agree usually that issues should be built around component changes as opposed to wide sweeping architectural changes, but at this point in the development, it is faster for me to do so, since the priority is to reach a certain level of features, and then to unify them all through an API -> Build an intuitive UX.
Once I hit the level of feature complete or API stability, I feel that at that point it will be easier to make component level issues as opposed to footnotes in them.

[TomLucidor]

I don't think it is just an API-side issue (e.g. external BASB/PKM/RAG) or feature level (e.g. agent stability, downloaders), but also an issue at the conceptual framework level (e.g. organizing what criteria to check/include/benchmark, which specific tool to include/reference/cluster). There will be a lot of questions to dig down and tease out... and I am also looking forward to trying Perplexica