Fix tool forward args with defaults but no type hint
This commit is contained in:
		
							parent
							
								
									9863155a94
								
							
						
					
					
						commit
						df89388147
					
				|  | @ -112,4 +112,4 @@ This is illustrated on the figure below, taken from [Executable Code Actions Eli | |||
| 
 | ||||
| <img src="https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformers/code_vs_json_actions.png"> | ||||
| 
 | ||||
| This is why we put emphasis on proposing code agents, in this case python agents, which meant putting higher effort on building secure python interpreters. | ||||
| This is why we put emphasis on proposing code agents, in this case python agents, which meant building secure python interpreters. | ||||
|  | @ -19,7 +19,7 @@ rendered properly in your Markdown viewer. | |||
| 
 | ||||
| In this tutorial, we’ll see how to implement an agent that leverages SQL using `smolagents`. | ||||
| 
 | ||||
| > Let's start with the goldnen question: why not keep it simple and use a standard text-to-SQL pipeline? | ||||
| > Let's start with the golden question: why not keep it simple and use a standard text-to-SQL pipeline? | ||||
| 
 | ||||
| A standard text-to-sql pipeline is brittle, since the generated SQL query can be incorrect. Even worse, the query could be incorrect, but not raise an error, instead giving some incorrect/useless outputs without raising an alarm. | ||||
| 
 | ||||
|  | @ -27,7 +27,7 @@ A standard text-to-sql pipeline is brittle, since the generated SQL query can be | |||
| 
 | ||||
| Let’s build this agent! 💪 | ||||
| 
 | ||||
| ### Setup text to SQL | ||||
| First, we setup the SQL environment: | ||||
| ```py | ||||
| from sqlalchemy import ( | ||||
|     create_engine, | ||||
|  | @ -73,7 +73,7 @@ for row in rows: | |||
| 
 | ||||
| Now let’s make our SQL table retrievable by a tool. | ||||
| 
 | ||||
| The tool’s description attribute will be embedded in the LLM’s prompt by the agent system: it gives the LLM information about how to use the tool. So that is where we want to describe the SQL table. | ||||
| The tool’s description attribute will be embedded in the LLM’s prompt by the agent system: it gives the LLM information about how to use the tool. This is where we want to describe the SQL table. | ||||
| 
 | ||||
| ```py | ||||
| inspector = inspect(engine) | ||||
|  |  | |||
|  | @ -19,6 +19,7 @@ dependencies = [ | |||
|     "pandas>=2.2.3", | ||||
|     "jinja2>=3.1.4", | ||||
|     "pillow>=11.0.0", | ||||
|     "llama-cpp-python>=0.3.4", | ||||
|     "markdownify>=0.14.1", | ||||
|     "gradio>=5.8.0", | ||||
|     "duckduckgo-search>=6.3.7", | ||||
|  |  | |||
|  | @ -117,6 +117,10 @@ def _convert_type_hints_to_json_schema(func: Callable) -> Dict: | |||
|             properties[param_name] = _parse_type_hint(param_type) | ||||
|             if signature.parameters[param_name].default != inspect.Parameter.empty: | ||||
|                 properties[param_name]["nullable"] = True | ||||
|     for param_name in signature.parameters.keys(): | ||||
|         if signature.parameters[param_name].default != inspect.Parameter.empty: | ||||
|             if param_name not in properties: # this can happen if the param has no type hint but a default value | ||||
|                 properties[param_name] = {"nullable": True} | ||||
|     return properties | ||||
| 
 | ||||
| AUTHORIZED_TYPES = [ | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue