“Summarize into doc”:
Paul:
I built a Daniel Pink LLM machine in less than an hour. Daniel Pink says that to really get at the core problem, ask someone what the problem is, then ask “why?” 5 times. I did the exercise manually a few times, here’s a sample: 5 Whys of Software Components (I couldn’t stop myself at only 5 iterations :-).
The dpink LLM is just 2 LLMs mutually feeding each other with a counter in between. The first LLM is prompted to generate an answer to a question. The second LLM is prompted to extract the main point from the answer, and to rephrase the main point with “Why …” in front of it. This rephrased question gets fed back into the first LLM. Repeat 5 times. The result on my 1 test was surprisingly good.
I am about to write up, in detail, my ‘kinopio2md’ tool. It uses Prolog because I’m lazy. I’ve got a Prolog-written-in-Javascript lying around here somewhere. If it interests you, I would be glad to share the kinopio2md stuff, or the jsprolog stuff, with you (or anyone else who’s interested) - early drafts, or, finished version, or, several Zoom (Jitsi, Facetime, Descript 2-person podcasts) calls, whatever.
[Actually, I’m also “about to write up” in detail the dpink LLM machine, too].
[+] Learn from Apple (!). LLMs are cool and have a zillion possibilities. Too many choices === confusion and deer-caught-in-the-headlights mode. Apple Intelligence gives you 3 choices out of the box (generate “friendly”, generate “professional”, generate “concise”). I “just used it” several times before I even figured out that I was using Apple Intelligence. When trying to appeal to non-programmers, HCI is more important than walls-of-features.
I’ve done some tests on the side and this looks not too bad although I probably won’t target special file formats for scope. Plain text/md can be pasted into anything.
One wrinkle is that, by necessity , summarizing a space will require sending that space data to a Ilm company (most likely anthropic). How important is that to communicate explicitly? (eg how non obvious is that?)
Actually, I was blurring 2 different things. Converting a Kinopio JSON file to markdown can be done completely locally without using an LLM. Summarizing and doing the 5-why drill is something you can do with an LLM /after/ the Kinopio space has been converted to markdown.
1 Like
There’s already a way to export a text list of cards but my impression is that the part that’s potentially valuable in people’s irl workflows is the ability to use kinopio and get something that looks more like a doc they could paste and edit in their company wiki, etc?
My particular use-case is that I use Kinopio as a brainstorming tool / thought organizer.
Connections between boxes are parent-child relationships in this use-case.
For example, if I’m remembering correctly, this example space:
is manually exported to JSON, then the k2md tool converts it to properly indented markdown, like:
# How to Implement Software LEGO® Blocks
- rt kernel
- py
- js
- cl
- in browser?
Which, I think, is different from just a text dump, although, I haven’t tried dumping text recently.
From my perspective, the interesting bit is the tech used in k2md. I resorted to using Prolog and wrote a few rules that figured out the parent-child relationships, recursively. Prolog ain’t special, the same can be done with nested loops. Prolog just makes it easier to experiment with. All of this runs locally, assuming that you’ve installed SWIPL (a free Prolog) on your machine. If I became serious, I would consider resurrecting a previous experiment which implements enough of Prolog in Javascript - i.e. no SWIPL would be required.
how would you represent a multi-parent tree like this?
because kinopio is more freeform than an outliner you can get some very non-traditional structures
The answer is: I wouldn’t do that with k2md. My view is that customization is preferred over generalization. My k2md stuff is meant to show how easy it is to customize. In certain cases, I create a Kinopio space with a certain approach in mind. In that - very specific - case, I know what I want the connections to mean. In that - very specific - case, I can throw together a quickie interpretation of a JSON export of my Kinopio use-case. For that very specific case - and only for that specific use-case. It’s so cheap to do, that I don’t care that it doesn’t cover every other possible use-case. We have all the technology to do this, but, we don’t have the mindset to allow us to think outside of the box of over-generalization. Pond’ring aloud: If Kinopio were to use AI, it should allow the user to give meaning to the connection types, then tell AI to sort it all out and to unwind each space in some coherent manner. On a per-space basis - not in a generalized way. My experimental approach: convert the exported JSON to a big, flat lump of facts (a factbase). Then, write Prolog/Datalog/miniKanren rules to walk through the database and apply “rules” to generate what-the-user-wants. I guess that I’m suggesting that Kinopio needs a “declarative” way for users to say what a ‘space’ means. For me, as a programming-generalist, the obvious choice is something like Prolog. For non-programmers, the obvious choice is probably AI, which allows for a more loosey-goosey description as to what the cards and connections in a space mean. Most non-programmers wouldn’t want to think so deeply about the computer / Kinopio, aspects. They would probably opt to buy-in meaning-interpreters as plug-ins from other people (akin to receptionists using dental office programs devised by domain experts).
1 Like
