[AI-3] Store the model catalogue and capability verdicts - #24882
[AI-3] Store the model catalogue and capability verdicts#24882tangopium wants to merge 1 commit into
Conversation
|
Caution The provided work package version does not match the core version Details:
Please make sure that:
|
|
Caution The Enterprise plan field is not set on the work package Details:
Please make sure that:
|
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c176e37fd0
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
c176e37 to
2eda2e5
Compare
2eda2e5 to
69ec8da
Compare
|
Warning Flaky specs
🤖 Ask Copilot to investigateCopy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer. |
69ec8da to
028a030
Compare
… capabilities Persists the models a connection offers as LlmModel records, refreshed by LlmConnections::SyncModelsService after every credential change and on demand through the new Refresh models action. Models the server stops offering are deactivated rather than deleted, so anything pointing at one still has something to name. What is known about each model is stored as LlmCapabilityVerdict rows in three states: supported, unsupported and unknown, because the OpenAI model list carries no capability information and the honest answer is very often that we cannot tell. Verdicts are seeded from the ruby_llm registry where the model id is catalogued, survive re-detection when an administrator asserted them, and are discarded wholesale when the credentials point at a different deployment. No UI beyond the refresh action yet; the model list and manual entries follow in later parts. Part 4 of the AI-3 stack. https://community.openproject.org/work_packages/66020
|
Warning Flaky specs
🤖 Ask Copilot to investigateCopy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer. |
028a030 to
281818a
Compare
|
Warning Flaky specs
🤖 Ask Copilot to investigateCopy the prompt below into a new comment on this PR to delegate the investigation to GitHub Copilot. It will look into the flakiness and open a separate pull request with you as reviewer. |
| # -- an LLM server that has not finished starting. | ||
| class SyncModelsJob < ApplicationJob | ||
| def perform | ||
| connection = LlmConnection.first |
There was a problem hiding this comment.
I don't see a reason to implement that single-connection constraint here in addition to the model. We can just iterate the whole table to reduce friction later.
|
|
||
| cards.each do |card| | ||
| model = connection.models.find_or_initialize_by(external_id: card.fetch(:id)) | ||
| model.update!(display_name: card[:display_name], |
There was a problem hiding this comment.
Shouldn't we want to also retain the original name if we got nothing from the server? Something like:
| model.update!(display_name: card[:display_name], | |
| model.update!(display_name: card[:display_name].presence || model.display_name), |
| states = relevant.index_with { |capability| published.include?(capability) ? :supported : :unsupported } | ||
| states.merge(embeddings: embedding ? :supported : :unsupported) |
There was a problem hiding this comment.
Aren't we missing the edge case of unknown here?
Ticket
AI-3
What are you trying to accomplish?
PR 4 of 11 in the AI-3 stack. Persists what the server offers and what is known about it:
LlmModelrows synced from the catalogue after every credential change and on demand via the Refresh models action, andLlmCapabilityVerdictrows in three states (supported, unsupported, unknown), because the OpenAI model list carries no capability information and "we cannot tell" is the honest answer. Verdicts are seeded from the ruby_llm registry where the model id is catalogued, administrator assertions survive re-detection, and everything is discarded when the credentials point at a different deployment. Models the server stops offering are deactivated rather than deleted, so anything referencing one still has something to name. No UI beyond the refresh action; the list follows in PR 5.Merge checklist
llm_connectionfeature flagStacked on #24881.