Hello, and some notes on making Ossie models cheaper to feed to LLMs

[abolfazlmadanii]

Hi everyone,

I'm Abolfazl (@abolfazlmadanii), a data engineer mostly working on streaming data. I've been reading through Ossie over the past few days and wanted to say hello and share what I'm planning.

I'm starting an open-source tool (Apache-2.0) that builds on Ossie. The idea is pretty simple: point it at a database and a BI tool with read-only access, let it look at the schema and some sample data, and have it generate an Ossie model. Then it checks that model against the actual data, so the joins and metrics are verified rather than guessed. Once a model is verified, it becomes the context an LLM uses to write SQL or build charts. It will live in its own repo and only read and write standard Ossie YAML, so I'm not asking for any of it to go into Ossie itself.

While going through the spec, I got curious about how expensive Ossie models are to hand to an LLM, so I counted tokens on the example models (cl100k tokenizer). A few things stood out:

• Most expressions repeat the same single-dialect wrapper. A shorthand for that case (I think this is close to what Allow a default dialect at the semantic model level #294 is about) made the flights example about 46% smaller and TPC-DS about 16% smaller.
• A compact "LLM view" in the Python SDK that leaves out custom_extensions shrank the converter fixtures by 20 to 59%.
• Some ai_context synonyms just repeat the field name, so a simple lint check could help keep that context useful (related to does ai_context really nessary? Strengthen description and name to reduce reliance on ai_context #234).

I'm happy to share the scripts I used. I'd also like to contribute the parts that make sense for Ossie, probably starting with the ai_context lint and a few small docs fixes I noticed along the way.

Would any of this be welcome? And if someone is already working on these, I'd rather help there than duplicate the effort.

Thanks for building this in the open.

Abolfazl

[flyrain]

Thanks for looking into this. ai_context is already optional, so synonyms that simply repeat the field name can be removed, and the entire field omitted when it adds no useful information. Would cleaning up the examples and clarifying this guidance address the issue? I can see an optional lint helping with generated models, but I’d like to understand the recurring use case before adding it to Ossie’s tooling.

[christianeu-db]

@abolfazlmadanii welcome to the Ossie community!

I'd be curious to learn more about your script and methodology. Some of your findings seem useful for measuring the portability of exported models.

To your specific points:

1. Repeating dialects: I put together feat(core-spec): decouple core spec from specific vendors #617 to promote the portable expression to a top-level field in the spec. For a fully portable model, this would eliminate the need for dialect lists or keys.
2. Shrinking file size by removing custom extensions: To clarify, are you saying that custom extensions account for 20–60% of some exported fixtures? At the high end, that would mean 60% of the file is vendor-specific state rather than portable semantics. That's a valuable metric to track across converters, especially alongside dialect usage (which I suspect would bring these numbers even higher). We should measure this and work to reduce it over time, whether by improving converters or addressing gaps in the core spec.
3. ai_extensions: I'll defer to [Yufei's thread above.

On contributing, small documentation fixes sound like great starter tasks. I'd also be excited to see whether you could generalize your custom extension findings into a portability metric for converters. That would help us identify where to focus improvements and, in turn, make models easier for other consumers, including LLMs, to understand by reducing the vendor-specific surface area.

[jbonofre]

Welcome aboard!

I suggest you to subscribe to the dev mailing list: it's where we are discussing and making decisions.

https://ossie.apache.org/community/

[abolfazlmadanii]

Thanks, everyone, for such a warm welcome. I really appreciate you all taking the time.

@flyrain, that's fair. I agree a lint rule is premature until we see the same problem come up again. I'll start with what you suggested: clean up the redundant synonyms in the examples and make the ai_context guidance a bit clearer. I'll keep that PR small and easy to review.

@christianeu-db, thanks for opening #617. I'll read it properly and leave comments this week. To answer your question: yes, roughly. The share of a file taken up by custom extensions varies a lot between converters. In the Holistics ecommerce fixture they're about 60% of the tokens, in the Salesforce one about 47%, and in the ThoughtSpot TPC-DS one about 33%. When I project the files down to a lean view for an LLM (no extensions, short expressions), Holistics drops from 5758 to 2335 tokens, ThoughtSpot TPC-DS from 4757 to 3220, and plain TPC-DS from 3484 to 2787. I'd be glad to take on the portability metric. My plan is to run it across all the converters and come back with a short proposal and real numbers, so we can decide together whether it's useful.

The scripts and method are here: https://gist.github.com/abolfazlmadanii/98ac53a8bb4a2396d45dc4a57dc304e1. They're short, and I'm happy to clean them up if any of it is worth keeping in the repo.

@jbonofre, thanks for the pointer. I'm subscribing to the dev list today and will keep the bigger questions there.

Abolfazl