Add Schema builder for Structured Outputs

[danielfriis]

Suggesting an approach similar to how RubyLLM::Tool is implemented, allowing for this:

class MySchema < RubyLLM::StructuredOutput::Schema
  string :name
  number :age

  object :address do
    string :street
    string :city
  end

  array :tags, :string

  array :contacts do
    object do
      string :email
      string :phone
    end
  end

  any_of :status do
    string enum: ["active", "pending"]
    null
  end
end

And then allowing to call .json_schema on the class as input for using structured outputs.

[kieranklaassen]

Nice! I started some implementation in #65 as well, but it is very overlapping. My approach is that people can either use a RubyLLM::StructuredOutput::Schema or bring their own.

Let me know if you want to join forces on this.

[danielfriis]

Hey @kieranklaassen! I did see your PR, but noticed that it included the parser concept too, and in all honesty, it felt a bit overwhelming to dive into, so I wanted to suggest a simple approach for structured outputs only (initially). I'm game to join efforts — yours or mine — but let's maybe have @crmne's perspective on the direction before we spend too much time?

[kieranklaassen]

Yes! For sure! I'm trying to build something I can actually use in production so kind of need that too but we can simplify. I love to keep things simple. Let's wait for @crmne to give his perspective and we can divide and conquer together

[danielfriis]

@kieranklaassen feel free to take a look and see if I've missed anything and if it aligns with your expectations!

[jayelkaake]

@danielfriis I like your code, but on a high level I'm kind of against adding DSL to JSON Schema because IMO it's already it's own DSL. Then you're having to learn a DSL for a DSL.

This SDK core value is it abstracts the LLM-specific code with a simple interface. Since JSON schema is already abstracted, we don't need to add another abstraction layer on that, ya know?

That's just my opinion ... and that being said, your DSL here is quite simple and lovely - so good work!

[danielfriis]

@danielfriis I like your code, but on a high level I'm kind of against adding DSL to JSON Schema because IMO it's already it's own DSL. Then you're having to learn a DSL for a DSL.

This SDK core value is it abstracts the LLM-specific code with a simple interface. Since JSON schema is already abstracted, we don't need to add another abstraction layer on that, ya know?

That's just my opinion ... and that being said, your DSL here is quite simple and lovely - so good work!

I hear you! To me, the JSON structure is not intuitive though. Not unlike how tools are also covered by the gem.

But it's not a hill I will die on :) The gem works fine with just your new PR and I can run this next to the gem.

[jayelkaake]

To me, the JSON structure is not intuitive though. Not unlike how tools are also covered by the gem.

I agree that the schema language itself isn't super intuitive. I think that's the value a DSL like yours brings.

But it's not a hill I will die on :)

Same :).

I guess tools like Copilot now make me now lean towards not needing DSL since they autocomplete schema definitions anyways. (prob leaned the other way just last year!)

[crmne]

Thanks for your work @danielfriis!

Had a quick skim and I like the code.

However, isn't there any library that is already a great DSL for JSON Schemas? The core philosophy of RubyLLM is to not have to rely on any library for the core AI functionality because of how fast things change in that world, but for JSON Schemas I'm sure we can settle on a DSL made by someone else and actively maintained instead of maintaining our own

[danielfriis]

Thanks for your work @danielfriis!

Had a quick skim and I like the code.

However, isn't there any library that is already a great DSL for JSON Schemas? The core philosophy of RubyLLM is to not have to rely on any library for the core AI functionality because of how fast things change in that world, but for JSON Schemas I'm sure we can settle on a DSL made by someone else and actively maintained instead of maintaining our own

Thanks a lot @crmne !

There are gems covering this (also specifically for LLMs).

Personally, I just don't like to rely on other libraries for core concepts — especially if the implementation is simple.

My initial thought was to make it part of a Structured Output / JSON mode PR ( #131 ).

To me, they go together as the current tool implementation has both a tool definition side, and a execution side.