feat: add graceful prompt-based fallback for local LLMs without tool calling support

[androemeda]

Closes #45

---

Summary

Modifies the backend to gracefully handle local LLM models (like deepseek-r1) that do not natively support tool/function calling. Instead of crashing with a 400 Bad Request, the backend now falls back to a prompt-based tool selection approach.

Also updates SETUP.md to clarify model recommendations.

---

Explanation of Implementation

Try-Catch Fallback (llms_service.py)

get_response_with_tools now attempts to use the native tool calling API first.

If a 400 error occurs (specifically catching "does not support tools"), a warning is logged and the workflow shifts to _get_response_with_prompt_tools.

---

Prompt-Based Tool Execution

The fallback uses a two-step approach:

1. Ask the LLM to output a JSON object specifying which tool to call.
2. Execute the selected tool.
3. Ask the LLM to generate the final response using the tool's output.

---

Decoupled Prompts (tool_selection_prompt.py)

Moved the new TOOL_SELECTION_PROMPT into:

app/utils/tool_selection_prompt.py

This maintains the existing pattern of separating prompts from service logic.

---

Documentation Update (SETUP.md)

Updated the guide to recommend tool-calling capable models (e.g., llama3.1:8b) as the primary choice for the best experience.

deepseek-r1 models remain listed as alternatives with a note explaining the fallback limitations.

---

Screenshots

Before (Crash)

After (Graceful Fallback)

---

Testing

Native Path Verification

Set:

AZURE_DEPLOYMENT_NAME=llama3.1:8b

Successfully triggered native tool calling (e.g., "List all calcium models") with no errors.

---

Fallback Path Verification

Set:

AZURE_DEPLOYMENT_NAME=deepseek-r1:1.5b

Confirmed that sending a query:

• triggers the ValueError
• logs the fallback warning
• parses the prompt-based JSON response
• returns a successful reply to the frontend

---