1 Punkte von GN⁺ 4 시간 전 | 1 Kommentare | Auf WhatsApp teilen
  • RubyLLM ermöglicht es, AI-Workflows wie Chatbots, AI-Agenten, RAG und Content-Erstellung in Ruby-Apps mit einem einzigen Framework umzusetzen
  • GPT, Claude und lokales Ollama lassen sich über dieselbe Schnittstelle ansprechen; die Abhängigkeiten sind auf Faraday, Zeitwerk und Marcel beschränkt
  • Es deckt nicht nur Chat ab, sondern auch Bild- und Videoanalyse, Audio-Transkription, Dokumentverarbeitung, Bildgenerierung, Embeddings, Moderation, Tool-Aufrufe, strukturierte Ausgabe und Streaming
  • In Rails bietet es acts_as_chat, Modell-Laden und einen optionalen Generator für eine Chat-UI und kann sofort eine einsatzbereite Chat-Oberfläche öffnen
  • Unterstützt werden OpenAI, xAI, Anthropic, Gemini, VertexAI, Bedrock, DeepSeek, Mistral, Ollama, OpenRouter, Perplexity, GPUStack und OpenAI-kompatible APIs

Ein einziges AI-Framework für Ruby

  • RubyLLM ist ein Werkzeug, um wichtige AI-Anbieter in einem einzigen Ruby-Framework zu nutzen
  • Gedacht für den Bau von Chatbots, AI-Agenten, RAG-Anwendungen, Content-Generatoren und weiteren AI-Workflows
  • Wird produktiv bei Chat with Work eingesetzt

Eine Schnittstelle, die API-Unterschiede zwischen Anbietern verbirgt

  • Der Fokus liegt darauf, Probleme zu verringern, die dadurch entstehen, dass sich Client, API, Antwortformat und Konventionen je nach AI-Anbieter unterscheiden
  • Mit derselben Schnittstelle können GPT, Claude und lokales Ollama verwendet werden
  • Als Abhängigkeiten werden nur Faraday, Zeitwerk und Marcel genutzt

Grundlegende Nutzung

  • Für einfache Fragen wird mit RubyLLM.chat ein Chat-Objekt erstellt und mit chat.ask ausgeführt
    • Beispiel: chat.ask "What's the best way to learn Ruby?"
  • Für Dateianalyse werden Dateien über die Option with: übergeben
    • Bild: ruby_conf.jpg
    • Video: video.mp4
    • Audio: meeting.wav
    • PDF: contract.pdf
    • Code: app.rb
  • Mehrere Dateien können als Array übergeben und in einem Schritt analysiert werden
    • Beispiel: with: ["diagram.png", "report.pdf", "notes.txt"]
  • Streaming-Antworten verarbeiten chunk.content, indem ein Block übergeben wird

Umfang der AI-Funktionen

  • Mit RubyLLM.paint wird Bildgenerierung ausgeführt
  • Mit RubyLLM.embed werden Text-Embeddings erzeugt
  • Mit RubyLLM.transcribe wird Audio in Text transkribiert
  • Mit RubyLLM.moderate wird die Sicherheit von Inhalten geprüft
  • Mit Klassen, die von RubyLLM::Tool erben, kann die AI Ruby-Methoden aufrufen
    • Das Beispiel-Tool Weather nimmt Breiten- und Längengrad entgegen und holt aktuelle Wetterdaten von der Open-Meteo-API
  • Mit RubyLLM::Agent lassen sich wiederverwendbare Agenten mit Instruktionen und Tools definieren
    • Das Beispiel WeatherAssistant verwendet das Modell gpt-5-nano, eine Anweisung für knappe Antworten und das Tool Weather
  • Mit RubyLLM::Schema lassen sich Schemata für strukturierte Ausgabe definieren
    • Das Beispiel ProductSchema definiert die Felder name, price und features

Funktionsliste und Anbieter-Support

  • Die wichtigsten Funktionen sind:
    • Chat: Konversationelle AI auf Basis von RubyLLM.chat
    • Vision: Bild- und Videoanalyse
    • Audio: Sprachtranskription und -verständnis auf Basis von RubyLLM.transcribe
    • Documents: Extraktion aus Dateitypen wie PDF, CSV und JSON
    • Image generation: Bildgenerierung auf Basis von RubyLLM.paint
    • Embeddings: Erzeugung von Embeddings auf Basis von RubyLLM.embed
    • Moderation: Prüfung der Inhaltssicherheit auf Basis von RubyLLM.moderate
    • Tools: Die AI kann Ruby-Methoden aufrufen
    • Agents: Wiederverwendbare Assistenten auf Basis von RubyLLM::Agent
    • Structured output: Strukturierte Ausgabe auf Basis von JSON-Schema
    • Streaming: Echtzeitantworten auf Block-Basis
    • Rails: ActiveRecord-Integration auf Basis von acts_as_chat
    • Async: Fiber-basierte Parallelität
    • Model registry: Mehr als 800 Modelle mit Feature-Erkennung und Preisinformationen
    • Extended thinking: Steuerung, Anzeige und Speicherung des Denkprozesses von Modellen
  • Unterstützte Anbieter sind OpenAI, xAI, Anthropic, Gemini, VertexAI, Bedrock, DeepSeek, Mistral, Ollama, OpenRouter, Perplexity, GPUStack und OpenAI-kompatible APIs

Installation und Rails-Integration

  • Für die Installation wird gem 'ruby_llm' zur Gemfile hinzugefügt und danach bundle install ausgeführt
  • API-Schlüssel werden in config/initializers/ruby_llm.rb gesetzt
    • Beispiel: config.openai_api_key = ENV['OPENAI_API_KEY']
  • Die Rails-Integration wird mit den folgenden Befehlen installiert
    • bin/rails generate ruby_llm:install
    • bin/rails db:migrate
    • bin/rails ruby_llm:load_models # v1.13+
  • Optional kann eine Chat-UI hinzugefügt werden
    • bin/rails generate ruby_llm:chat_ui
  • Wenn im Rails-Modell acts_as_chat deklariert wird, kann ein ActiveRecord-basierter Chat verwendet werden
    • Das Beispielmodell deklariert acts_as_chat in Chat < ApplicationRecord
    • Mit Chat.create! model: "claude-sonnet-4" kann ein Chat erstellt und mit übergebenen Dateien eine Frage gestellt werden
  • Die vorbereitete Chat-Oberfläche ist unter http://localhost:3000/chats erreichbar

1 Kommentare

 
GN⁺ 4 시간 전
Hacker-News-Kommentare
  • RubyLLM war überraschend gut und liegt bei der Nutzbarkeit eher nahe an Vercels AI-Framework
    Es versucht, ein Gleichgewicht zwischen sofort nutzbarem Komfort und Flexibilität zu finden, was entsprechend schwierig ist, aber insgesamt war es gut
    Das größte tatsächliche Ärgernis war, dass das Caching nicht immer funktioniert. xAI unterstützt zum Beispiel nur die Completions API, und die thought signature wird fehlerhaft zurückgegeben, was Probleme verursacht

  • Es gibt das Open-Source-Gem Raix, das auf der Abstraktion von RubyLLM aufbaut, und es wird ziemlich häufig verwendet
    https://github.com/OlympiaAI/raix

  • Ich nutze RubyLLM in Produktion und bin sehr zufrieden damit. Es ist ein hervorragendes und leicht zu nutzendes Framework
    Dass die Responses API nicht standardmäßig unterstützt wurde, war wie andere schon sagten frustrierend und wirkte wie eine große Lücke. Es gibt zwar einen von einem anderen Entwickler gebauten Connector, aber der hat Bugs und ist qualitativ nicht auf dem Niveau des Haupt-Gems
    Ich freue mich auf die weitere Entwicklung, besonders auf 2.0. Wenn die Responses API jetzt nativ enthalten ist, werde ich sie mir auf jeden Fall ansehen

    • Der Grund, warum die Responses API in RubyLLM 1.x nicht implementiert war, lag darin, dass intern faktisch angenommen wurde, Provider und Protokoll entsprächen sich 1:1
      OpenAI hat zwei Protokolle mit unterschiedlichen Fähigkeiten, und um auf alle Modelle von VertexAI zugreifen zu können, muss man mehrere Protokolle unter einem einzigen Provider unterstützen, sodass diese Annahme nicht mehr stimmte
      Deshalb war ein großes Refactoring nötig, bei dem Protocols und Providers getrennt werden und selbst unter demselben Provider je nach Modell transparent an unterschiedliche Protocols geroutet wird. Diese Arbeit soll in RubyLLM 2.0 enthalten sein
      Falls es interessant ist, hier zwei relevante Commits: https://github.com/crmne/ruby_llm/commit/d398354da493570b050...
      https://github.com/crmne/ruby_llm/commit/0875ce2dfeae9d28a3a...
  • RubyLLM ist sehr leicht zu verwenden. Ich habe es letztes Jahr in einem Projekt intensiv eingesetzt
    Der Nachteil war, dass es schwer für echte Tracing-Observability zu instrumentieren war, und bei Retries gab es ein Muster, bei dem interne Modelle gelöscht wurden. Dadurch wirkte die sichtbare Historie sauber, aber die tatsächliche Reihenfolge der API-Aufrufe ließ sich nicht besonders genau nachvollziehen

  • Ich baue gerade etwas, das sich nur auf Claude konzentriert, und habe nicht vor, das Anthropic-Ökosystem zu verlassen. Mich würde interessieren, ob RubyLLM in so einem Fall trotzdem Vorteile gegenüber der direkten Nutzung des Ruby-SDKs von Anthropic hat
    Anders gesagt: Ist diese Entscheidung eher wie die Wahl zwischen Fog und aws-sdk-s3 oder eher wie die Wahl zwischen Active Storage und aws-sdk-s3?

    • Ich würde sagen, es ist eher wie die Beziehung zwischen Active Storage und aws-sdk-s3
      Das Gute an RubyLLM ist die an ActiveRecord erinnernde DSL mit Method Chaining, die Struktur zum Organisieren von Agents, Tools und Prompts und die Portabilität, durch die man leicht zwischen Anthropic und DeepSeek testen und wechseln konnte, was die Kosten um mehr als 90 % gesenkt hat
      Auch die ActiveRecord-Integration ist gut, mit der sich per bin/rails generate ruby_llm:install jeder Chat in der Datenbank speichern lässt. Es war außerdem sehr hilfreich, den gespeicherten Chat-Verlauf regelmäßig herunterzuladen, ihn an claude code zu geben und damit die Agent-Anweisungen nachschärfen zu lassen
    • Wenn es ein Tool gibt, mit dem man später jeden beliebigen Provider wählen kann, sehe ich keinen Grund, absichtlich eine Abhängigkeit von nur einem Provider einzubauen
      Schon allein mit Blick auf Ausfälle sollte man sich fragen, was man tut, wenn ausgerechnet an dem Tag, an dem man den Dienst unbedingt braucht, die Anthropic API ausfällt
  • Ich nutze RubyLLM in einem Side-Project, und es ist großartig
    Interessant ist, dass Dinge, die letztes Jahr in den Fragen und Kommentaren auf der SF Ruby conf auftauchten, inzwischen bereits als Funktionen des Ökosystems erschienen sind: https://youtu.be/y535u1EWqAg?si=rbyv52T035apKwQk

  • Ich habe RubyLLM vor ein paar Monaten ziemlich tiefgehend genutzt, und Design und Implementierung waren sehr gut
    Ich habe eigene LLM-Clients in mehreren Lisp-Sprachen und habe sogar darüber nachgedacht, Teile des Designs von RubyLLM zu übernehmen. Nachahmung ist ein Lob

  • Danke, dass ihr Ruby in die AI-Community bringt und Open Source daran arbeitet
    Eine gute Sprache sollte stärker erforscht werden und mehr Aufmerksamkeit bekommen

    • Mir gefällt, dass Hacker News bei Gesprächen über Ruby eine MINASWAN-Stimmung bekommt
  • Für Laravel gibt es ebenfalls eine ähnliche Bibliothek
    https://laravel.com/docs/13.x/ai-sdk

  • Ich nutze RubyLLM ebenfalls in Produktion, und es ist die eleganteste Bibliothek in diesem Bereich, die ich bisher gesehen habe
    Auch die Art, wie der Issue-Tracker geführt wird, hat mir gefallen. Wenn man „Feature Request“ auswählt, muss man erklären, welche Workarounds man schon gesucht hat und warum es ausgerechnet in RubyLLM aufgenommen werden sollte, was verhindert, dass der Umfang endlos anwächst