Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Inference] create the @kbn/inference-common package #193464

Merged
merged 24 commits into from
Nov 1, 2024

Conversation

pgayvallet
Copy link
Contributor

@pgayvallet pgayvallet commented Sep 19, 2024

Summary

At the moment, all inference API related types and utilities (chatComplete, output and more) are living inside the inference plugin's common folder.

This is somewhat problematic because it forces any consumers of those types to explicitly depends on the inference plugin (via plugin dep or ts ref), which could lead to any kind of cyclic dependency issues, in addition to being overall a bad design pattern.

This also makes it more complicated that it should to try to split the inference logic / task framework / task implementation into distinct packages or plugins, due to some (concrete) utilities living in the inference plugin's code.

It's also a bad experience for consumers, as it's quite difficult to easily resolve imports they need (we're mixing internal and public exports atm, plus not all types are exported from a single entry point, making it very tedious to find the right path for each individual import we need to consume the inference APIs)

This PR addresses most of those points, by introducing a new @kbn/inference-common package and moving all the low level types and utilities to it, while exposing all of them from the package's entrypoint.

@pgayvallet pgayvallet added the Team:AI Infra AppEx AI Infrastructure Team label Sep 19, 2024
@pgayvallet pgayvallet changed the title [NL-to-ESQL] Improve workflow [Inference] create the @kbn/inference-common package Oct 30, 2024
@pgayvallet pgayvallet added release_note:skip Skip the PR/issue when compiling release notes backport:prev-minor Backport to (8.x) the previous minor version (i.e. one version back from main) v8.17.0 labels Oct 30, 2024
@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet
Copy link
Contributor Author

/ci

@pgayvallet pgayvallet marked this pull request as ready for review October 30, 2024 15:11
Copy link
Member

@legrego legrego left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few minor comments. Additionally, I'd like to see us improve the docs for our exposed types in a followup.

Larry Gregory 2024-10-30 at 14 11 22@2x

message: string = i18n.translate('xpack.inference.internalError', {
defaultMessage: 'An internal error occurred',
}),
message = 'An internal error occurred',
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: why did we un-internationalize this string?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We never i18n-ize technical errors. ES doesn't, Kibana doesn't.

@@ -15,3 +15,7 @@ export type ChatCompleteRequestBody = {
messages: Message[];
functionCalling?: FunctionCallingMode;
} & ToolOptions;

export interface GetConnectorsResponseBody {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these types not extracted to the inference-common package? Is it because they aren't used outside of the inference plugin?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, those are the types for the response payloads of the http APIs, it's only used internally by the plugin.

export function createToolNotFoundError(name: string): ChatCompletionToolNotFoundError {
return new InferenceTaskError(
ChatCompletionErrorCode.ToolNotFoundError,
`Tool ${name} called but was not available`,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need i18n?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as #193464 (comment) - I'd say no (fwiw this was only moved, not introduced by the PR)


export const generateEsqlTask = <TToolOptions extends ToolOptions>({
chatCompleteApi,
export const generateEsqlTaskFn = <TToolOptions extends ToolOptions>({
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in the nl_to_esql directory appear to be more substantial than (& unrelated to?) type/utility extraction. Can you help me understand the context for these changes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, I realized I did not mention anything on that part, sorry...

There are two things:

  1. I refactored the flow of the task to use a shared output observable instead of chaining observable calls (which was a nightmare to follow and to evolve, it's way easier to add steps and flow now)
  2. I introduced a summarizing pre-step, to see the effect on generation efficiency, but the step is disabled by default and there's no way to enable it from production usages atm (it's only for testing via evaluation)
    (3. I apparently also tweaked a few prompts, from evaluation tuning I did a while ago - the PR root is old)

That refactor is definitely something I want to merge, but tell me if we're not comfortable mixings things in that PR, I can extract those changes elsewhere.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if it's not too much, maybe it's good to pull the changes to the ES|QL task out and into a separate PR, and then we can run the evaluation suites on both sides against it?

Copy link
Contributor Author

@pgayvallet pgayvallet Oct 31, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I actually forgot I used that other PR as base for those changes... I will revert that part from there

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note for future me: kbx-xxx-nl-to-esql-refactor-2

* Run the query through the kibana
* @param query
*/
export const validateQueryAst = async (query: string): Promise<QuerySyntaxError[]> => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps out of scope or premature, but this feels like something that should exist within an es|ql package.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I want to take a closer look at the ESQL task later, as I'd like to even extract it from the inference plugin (this is a task, not part of the inference plugin/framework), but I was planning on doing it on a distinct PR as it's still not totally clear to me how exactly we should restructure.

(but fwiw, not sure it would benefit from living into an esql package rather than with the task esql, the function already mostly depend on low-level ESQL directives)

import { isToolValidationError } from '../../common/chat_complete/errors';
import { ToolChoiceType } from '../../common/chat_complete/tools';
import { ToolChoiceType } from '@kbn/inference-common';
import { isToolValidationError } from '@kbn/inference-common/src/chat_complete/errors';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: should we be reaching this far into the inference-common package for the import?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pgayvallet
Copy link
Contributor Author

@legrego

I'd like to see us improve the docs for our exposed types in a followup

Agreed, we absolutely need to do that

@pgayvallet pgayvallet requested a review from legrego October 31, 2024 10:08
@pgayvallet
Copy link
Contributor Author

@elasticmachine merge upstream

@pgayvallet pgayvallet enabled auto-merge (squash) November 1, 2024 07:00
@elasticmachine
Copy link
Contributor

⏳ Build in-progress

  • Buildkite Build
  • Commit: 8ec8ecb
  • Kibana Serverless Image: docker.elastic.co/kibana-ci/kibana-serverless:pr-193464-8ec8ecbe464f

History

@pgayvallet pgayvallet merged commit 631ccb0 into elastic:main Nov 1, 2024
50 checks passed
@kibanamachine
Copy link
Contributor

Starting backport for target branches: 8.x

https://github.com/elastic/kibana/actions/runs/11627031976

@kibanamachine
Copy link
Contributor

💔 All backports failed

Status Branch Result
8.x Backport failed because of merge conflicts

Manual backport

To create the backport manually run:

node scripts/backport --pr 193464

Questions ?

Please refer to the Backport tool documentation

nreese pushed a commit to nreese/kibana that referenced this pull request Nov 1, 2024
## Summary

At the moment, all inference API related types and utilities
(`chatComplete`, `output` and more) are living inside the `inference`
plugin's common folder.

This is somewhat problematic because it forces any consumers of those
types to explicitly depends on the `inference` plugin (via plugin dep or
ts ref), which could lead to any kind of cyclic dependency issues, in
addition to being overall a bad design pattern.

This also makes it more complicated that it should to try to split the
inference logic / task framework / task implementation into distinct
packages or plugins, due to some (concrete) utilities living in the
inference plugin's code.

It's also a bad experience for consumers, as it's quite difficult to
easily resolve imports they need (we're mixing internal and public
exports atm, plus not all types are exported from a single entry point,
making it very tedious to find the right path for each individual import
we need to consume the inference APIs)

This PR addresses most of those points, by introducing a new
`@kbn/inference-common` package and moving all the low level types and
utilities to it, while exposing all of them from the package's
entrypoint.

---------

Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Elastic Machine <[email protected]>
@kibanamachine
Copy link
Contributor

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 193464 locally

@kibanamachine kibanamachine added the backport missing Added to PRs automatically when the are determined to be missing a backport. label Nov 4, 2024
@kibanamachine
Copy link
Contributor

Friendly reminder: Looks like this PR hasn’t been backported yet.
To create automatically backports add a backport:* label or prevent reminders by adding the backport:skip label.
You can also create backports manually by running node scripts/backport --pr 193464 locally

pgayvallet added a commit to pgayvallet/kibana that referenced this pull request Nov 5, 2024
## Summary

At the moment, all inference API related types and utilities
(`chatComplete`, `output` and more) are living inside the `inference`
plugin's common folder.

This is somewhat problematic because it forces any consumers of those
types to explicitly depends on the `inference` plugin (via plugin dep or
ts ref), which could lead to any kind of cyclic dependency issues, in
addition to being overall a bad design pattern.

This also makes it more complicated that it should to try to split the
inference logic / task framework / task implementation into distinct
packages or plugins, due to some (concrete) utilities living in the
inference plugin's code.

It's also a bad experience for consumers, as it's quite difficult to
easily resolve imports they need (we're mixing internal and public
exports atm, plus not all types are exported from a single entry point,
making it very tedious to find the right path for each individual import
we need to consume the inference APIs)

This PR addresses most of those points, by introducing a new
`@kbn/inference-common` package and moving all the low level types and
utilities to it, while exposing all of them from the package's
entrypoint.

---------

Co-authored-by: kibanamachine <[email protected]>
Co-authored-by: Elastic Machine <[email protected]>
(cherry picked from commit 631ccb0)

# Conflicts:
#	.github/CODEOWNERS
jbudz pushed a commit that referenced this pull request Nov 5, 2024
#199002)

# Backport

This will backport the following commits from `main` to `8.x`:
- [Inference] create the `@kbn/inference-common` package (#193464)
(631ccb0)

<!--- Backport version: 8.9.8 -->

### Questions ?
Please refer to the [Backport tool
documentation](https://github.com/sqren/backport)

<!--BACKPORT [{"author":{"name":"Pierre
Gayvallet","email":"[email protected]"},"sourceCommit":{"committedDate":"2024-11-01T09:08:44Z","message":"[Inference]
create the `@kbn/inference-common` package (#193464)\n\n##
Summary\r\n\r\nAt the moment, all inference API related types and
utilities\r\n(`chatComplete`, `output` and more) are living inside the
`inference`\r\nplugin's common folder.\r\n\r\nThis is somewhat
problematic because it forces any consumers of those\r\ntypes to
explicitly depends on the `inference` plugin (via plugin dep or\r\nts
ref), which could lead to any kind of cyclic dependency issues,
in\r\naddition to being overall a bad design pattern.\r\n\r\nThis also
makes it more complicated that it should to try to split
the\r\ninference logic / task framework / task implementation into
distinct\r\npackages or plugins, due to some (concrete) utilities living
in the\r\ninference plugin's code.\r\n\r\nIt's also a bad experience for
consumers, as it's quite difficult to\r\neasily resolve imports they
need (we're mixing internal and public\r\nexports atm, plus not all
types are exported from a single entry point,\r\nmaking it very tedious
to find the right path for each individual import\r\nwe need to consume
the inference APIs)\r\n\r\nThis PR addresses most of those points, by
introducing a new\r\n`@kbn/inference-common` package and moving all the
low level types and\r\nutilities to it, while exposing all of them from
the package's\r\nentrypoint.\r\n\r\n---------\r\n\r\nCo-authored-by:
kibanamachine
<[email protected]>\r\nCo-authored-by:
Elastic Machine
<[email protected]>","sha":"631ccb031ca59d51b5db0939cf6327e36e5a34b3"},"sourceBranch":"main","suggestedTargetBranches":[],"targetPullRequestStates":[]}]
BACKPORT-->
@kibanamachine kibanamachine removed the backport missing Added to PRs automatically when the are determined to be missing a backport. label Nov 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:prev-minor Backport to (8.x) the previous minor version (i.e. one version back from main) ci:project-deploy-observability Create an Observability project release_note:skip Skip the PR/issue when compiling release notes Team:AI Infra AppEx AI Infrastructure Team Team:Obs AI Assistant Observability AI Assistant v8.17.0 v9.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants