Skip to content

Add tool calling to the LLM base class, implement in OpenAI #322

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

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

oskarhane
Copy link
Member

Description

Note

This PR adds tool calling functionality to the LLM base class with OpenAI implementation, enabling structured parameter extraction and function calling. The implementation includes both synchronous and asynchronous methods for tool invocation, with proper type hints and error handling. An example has been added to demonstrate how to use this new functionality.

Type of Change

  • New feature
  • Bug fix
  • Breaking change
  • Documentation update
  • Project configuration change

Complexity

Note

The implementation adds a new feature to the existing LLM interface but follows established patterns. It required careful handling of the OpenAI API's tool invocation parameters and proper type definitions.

Complexity: Medium

How Has This Been Tested?

  • Unit tests
  • E2E tests
  • Manual tests

Checklist

The following requirements should have been met (depending on the changes in the branch):

  • Documentation has been updated
  • Unit tests have been updated
  • E2E tests have been updated
  • Examples have been updated
  • New files have copyright header
  • CLA (https://neo4j.com/developer/cla/)) has been signed
  • CHANGELOG.md updated if appropriate

@oskarhane oskarhane requested a review from a team as a code owner April 4, 2025 09:16
@oskarhane oskarhane force-pushed the feature/llm-tool-invocation branch from cd47dc2 to 882915f Compare April 4, 2025 09:19
@oskarhane oskarhane force-pushed the feature/llm-tool-invocation branch from fc2f734 to 7f9bb39 Compare April 4, 2025 09:52
**params,
)

message = response.choices[0].message
Copy link
Contributor

Choose a reason for hiding this comment

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

Not for now because this is also the case in the already existing methods, but we should probably try to reduce code duplication between the sync and async calls.

@oskarhane oskarhane requested a review from stellasia April 4, 2025 13:43
@oskarhane oskarhane force-pushed the feature/llm-tool-invocation branch from 913c8be to b769242 Compare April 4, 2025 14:46
if not response.tool_calls:
raise ValueError("No tool calls found in response")

tool_call = response.tool_calls[0]
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there a reason to print only the first tool?

Copy link
Member Author

Choose a reason for hiding this comment

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

No, def not. Fixed in latest push.

model="gpt",
)
# Use assert_called_once() instead of assert_called_once_with() to avoid issues with overloaded functions
cast(Any, llm.client.chat.completions.create).assert_called_once()
Copy link
Contributor

Choose a reason for hiding this comment

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

I thought these cast(Any...) were fixed?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, me too. Removed and added mypy ignores in test file

@oskarhane oskarhane force-pushed the feature/llm-tool-invocation branch 2 times, most recently from 59bbb6a to 9ae73cb Compare April 14, 2025 15:29
return {"type": ParameterType.BOOLEAN, "description": self.description}


class ObjectParameter(ToolParameter):
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice! It's maybe a bit verbose, would be great if users could provide tool definition as dict, wdyt? I think converting the *Parameter to Pydantic model would make this easily possible (and we could also get rid of the to_dict methods).

Copy link
Member Author

Choose a reason for hiding this comment

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

Great idea!

Copy link
Member Author

Choose a reason for hiding this comment

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

Pushed this change now

@stellasia stellasia mentioned this pull request Apr 15, 2025
15 tasks
@oskarhane oskarhane force-pushed the feature/llm-tool-invocation branch from 107d670 to 61a0e46 Compare April 15, 2025 15:21

def model_dump_tool(self) -> Dict[str, Any]:
"""Convert the parameter to a dictionary format for tool usage."""
result = {"type": self.type, "description": self.description}
Copy link
Contributor

Choose a reason for hiding this comment

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

We do not need required here?

minimum: Optional[int] = None
maximum: Optional[int] = None

def model_dump_tool(self) -> Dict[str, Any]:
Copy link
Contributor

Choose a reason for hiding this comment

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

Is model_dump_tool only used to discard null values? If so, there is an option in model_dump for this (exclude_none=True by memory)

Copy link
Contributor

Choose a reason for hiding this comment

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

I know I'm a bit nitpicking here, but I've started to work on the implementation for Vertex AI, and some parameters need to be excluded, so if we can rely on Pydantic for this instead of manually re-implementing it, that would be great :) but if it's not possible, it's not possible.

raise ValueError("Parameter type is required")

# Find the appropriate class based on the type
param_classes = {
Copy link
Contributor

Choose a reason for hiding this comment

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

I feel like we could get rid of many of these by using either a field discriminator or some union, but I won't be strict on this point, experiments can be left for a cool down period.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants