sublayerapp / sublayer Goto Github PK

A model-agnostic Ruby Generative AI DSL and framework. Provides base classes for building Generators, Actions, Tasks, and Agents that can be used to build AI powered applications in Ruby.

Home Page: https://docs.sublayer.com

License: MIT License

Ruby 99.60% Shell 0.40%

ai dsl ruby agents ai-agents ai-agents-framework

sublayer's People

Contributors

Stargazers

Watchers

Forkers

drnic

sublayer's Issues

Create a new built in output_adapter for :object that can take some arbitrary nesting of attributes

Create a new default output_adapter for :array_of_strings

I think here we can use the CategoriesFromCodeGenerator: https://github.com/sublayerapp/blueprints/blob/main/lib/sublayer/generators/categories_from_code_generator.rb as an example that would use :array_of_strings

Create a new built in output_adapter for :integer

Create a new built in output_adapter for :image

Create a new built in output_adapter that returns multiple named strings in an object

Create a new built in output_adapter for :enum

Update output_adapter interface and implementation to be easier to create new versions

Take inspiration from what we were chatting about here #7 (comment)

Create a new built in output_adapter for :array_of_objects

The current pattern for Sublayer::Task doesn't generate well with Blueprints

Blueprints is very effective at generating Sublayer::Generators and Sublayer::Actions but the pattern I've been exploring with Sublayer::Tasks doesn't seem to work very well.

I tried to create a blueprint of the MakeRspecTestsPassTask here and generate a few variations, but it didn't jump to using and chaining actions and generators together.

Working to brainstorm ways to get it to reliably create new tasks and hallucinate the Sublayer::Actions and Sublayer::Generators it would need to complete the task...

Supporting native claude tools

https://docs.anthropic.com/claude/docs/tool-use

Claude now has native tools/functions. Theoretically we could rip out the Providers::Claude implementation and rewrite it to look similarly to the ::OpenAi provider.

Except the schema of claude3 tools looks different to openai functions.

Suggestion: OutputProviders rename to_hash to to_openai_hash; and then we add to_claude3_hash to be used for Claude provider? Fingers crossed there isn't a distinct tool/function OutputProvider schema for every LLM. My suggestion won't last the test of time.

Mechanism to use a different model from the same provider

For example, being able to optionally choose between using gpt-3.5 for something, using gpt-4-turbo for others, or between using claude-haiku for some and claude-opus for others if you want, but for the majority of cases being able to mostly rely on the defaults.

Multi-model providers break the universal function calling expectation inside providers

For model providers like Groq, Local, OpenRouter, etc, each different model you might want to use inside these different services could have different function calling/tool calling mechanism and quirks: Specifically I just tried generating something with Groq+llama3 and the xml response came back in a different format.

For now, going to move away from providing direct solutions for things like Groq and make it similar to what we're doing with output_adapters where you can specify a custom AI provider in your code to use and implement the specific quirks of that model. Over time we'll find patterns that work with things like Llama3 or Mistral or Hermes2 that we can provide as bases.