DEV-14675 - LLM 'filter-search/' API endpoint

[gregrholden]

Description:

DEV-14675 This is the initial implementation for the /api/v2/llm/filter-search/ endpoint.
NOTES:

• This is not ready to be merged until the BE team has reviewed/tested it and agrees with the assumptions listed under Technical Details.
• Most of the heavy lifting for the LLM interaction is handled by another branch that is currently in PR (filter_search_assistant).
• This PR contains 2 other branches that are in PR and so needs to be handled in the appropriate order.

Technical Details:

Branch is based off dev-14679-implement-search-assistant (currently in PR).
Branch ftr/DEV-15167-implement-recipient-lookup-tool was merged into this branch for additional tooling (that branch is also currently in PR).

Code Updates:

• llm/v2/urls.py was updated with the route for the endpoint.
• llm/v2/views/filter_search.py was created, defining the endpoint’s baseline behavior.
• llm/v2/views/llm_base.py was updated with high-level methods that can be shared by future LLM views.
• llm/tests/integration/test_filter_search.py was created to provide test coverage for the endpoint’s baseline behaviors.
• llm/fixtures/prompts.yaml had a typo fixed (line 7: “additonal” to “additional”).
• llm/assistants/filter_search.py was updated to provide more robust error handling, logging, and performance.

Assumptions:

• LLMAPIKeyHandler.require_api_key is complete and ready for use as a decorator on the post() method of the endpoint.
• Using the LLMBase class to provide shareable functions is an acceptable update to the codebase on this task.
• The default LLM model is “nova micro”, set on an LLMBase variable that can be overridden by an env variable.
• The user query should be validated against TinyShield, as was done in agency_base.py (line 76), before proceeding with prompting the LLM.
• CHECK: The return of a 422 error on TinyShield validation failure is acceptable, despite the API Contract specifying all errors should return a 403.
• The filter_search_assistant.py formulation is as complete as needed for this endpoint’s initial behavior with the LLM/tools.

Requirements for PR Merge:

1. Unit & integration tests updated
2. API documentation updated (examples listed below)
   1. API Contracts
   2. API UI
   3. Comments
3. Data validation completed (examples listed below)
   1. Does this work well with the current frontend? Or is the frontend aware of a needed change?
   2. Is performance impacted in the changes (e.g., API, pipeline, downloads, etc.)?
   3. Is the expected data returned with the expected format?
4. Appropriate Operations ticket(s) created
5. Jira Ticket(s)
   1. DEV-0

Explain N/A in above checklist:

[zachflanders-frb]

This is looking good, I especially like the improvements around getting the text messages from response content. I have a few comments for consideration: