71–80 of 149 posts
There’s an emerging pattern in agentic systems and this project is a great example. A deterministic layer like a compiler or generator of code with some kind of IR that the LLM generates and feeds it with. I feel we will be seeing this more and more in the near future.
This is a valuable method of closing the gap in making LLM results available in a good visual form. The idea of viewing the charting process as the last step—where the AI deals only with high-level semantic specifications as opposed to all the low-level visual details—makes so much sense. I'm interested to know what the layout optimization engine does: can the developers inject the desired limitations for some cases,…
We use a fun elastic algorithm to decide dimension etc within the developer's constraint.
Earlier quoted context omitted.
I'm sorry, but as someone who creates data visualisation as a big part of my job, I wouldn't say the charts on the website look good. Most aren't awful either, but by no means are they an improvement over what I'd get by telling any coding agent to make a chart with Vega-Lite or Observable Plot, and probably worse than if I had some decent instructions/skills. I don't quite get what the goal of this is other than abs…
Some composite charts are quite annoying to be generated well (like bullet, waterfall etc), their Vega-Lite equivalent can be quite long if just starting from scratch. The intention here is that Flint is a simpler abstraction to get basic setups right and any followup edits can be done on top of the first compiled outputs (thus not limiting expressiveness). It also makes it easier for user to manipulate (like swappin…
The paper's line of reasoning seems to continue the endless subjective loop of assuming your viz framework has the right abstractions & defaults , which the next person will rightfully disagree with for their slightly different eval set
We found in practice:
- LLM's generate charts fine
- LLM's tweak charts fine
- LLM's take user feedback to tweak them fine
In that sense, going higher-level for abstractions, as is being argued for here, is strictly worse: it's better to give controls so the LLM can go deep and customize
In practice, we found the choice of json config language X vs json config language Y to be pretty equivalent across different charting systems (vega, plotly, perspective, etc), LLM's do them all fine
The harder parts were deciding what a good chart is (model, reasoning, context), and opposite of this approach, giving lower-level facility for doing user change requests on tweaks, interactivity, and tricky in practice, when they have a lot of data on it.
Earlier quoted context omitted.
But why be exclusive? Why not "Chart language for computer programs to generate"? I don't want to use an agent at all, but i wouldn't mind generating some charts with an easy-to-generate markup language...
But for that we already have mermaid.js (and its precursor Graphviz/dot). The only reason to use this instead of existing, mature ones designed for humans is if you are an AI agent.
"For AI agents". I understand why everything needs to be marketed in this way, but it's just ... an easy-to-generate language for expressing charts. That's impressive! That's useful.
Earlier quoted context omitted.
But why be exclusive? Why not "Chart language for computer programs to generate"? I don't want to use an agent at all, but i wouldn't mind generating some charts with an easy-to-generate markup language...
Because these are completely different requirements.
"For AI agents". I understand why everything needs to be marketed in this way, but it's just ... an easy-to-generate language for expressing charts. That's impressive! That's useful.
also worth noting that Vega-Lite is literally just fucking that and AI already does good job with producing JSONs for it
Earlier quoted context omitted.
Some composite charts are quite annoying to be generated well (like bullet, waterfall etc), their Vega-Lite equivalent can be quite long if just starting from scratch. The intention here is that Flint is a simpler abstraction to get basic setups right and any followup edits can be done on top of the first compiled outputs (thus not limiting expressiveness). It also makes it easier for user to manipulate (like swappin…
I strongly disagree ;-) The paper's line of reasoning seems to continue the endless subjective loop of assuming your viz framework has the right abstractions & defaults , which the next person will rightfully disagree with for their slightly different eval set We found in practice: - LLM's generate charts fine - LLM's tweak charts fine - LLM's take user feedback to tweak them fine In that sense, going higher-level fo…
This is exactly why this is an intermediate language designed to get 95% stuff right easily (for expressiveness and reliability purpose), while 5% of more advanced case where the agents need to revise chart for other purpose can be done easily on top of the compiled low-level spec (low in terms of Vega-Lite etc, not SVG). We are not really designing a higher abstraction to replace existing ones.
In the past, the split is like 50% good at first run for some common stuff, all other stuff requires agent-loop or user involvement.
Our goal is to make it easy for most case, not everything needs a full multi-round trip agentic workflow to solve. :)
We are kinda all advanced users in fact, for a lot of users, they are easily get confused with the first time result if that is not as good, and the interactivity cost / multi-round isn't an option.
The charts are very nice, and I think the visualisation layer for LLMs is a very interesting problem. I’ve been building https://smalldocs.org for this exact reason. It’s an office suite for AI agents - but my main use case is giving a cli based LLM the canvas to express itself - charts, mermaid diagrams, etc. I’ve extended it a bit further to be a format for all types of work so the agent can embed slides and spread…
Can you please stop? You're crossing the line into spamming HN and we're getting complaints. It sounds like cool work, but you shouldn't be using HN in this way. Linking to your project occasionally in a relevant context is fine, but this should be a (small) minority of what you post to HN. From https://news.ycombinator.com/newsguidelines.html : "Please don't use HN primarily for promotion. It's ok to post your own s…