forked from phoenix-oss/llama-stack-mirror
1a7490470a
See https://github.com/meta-llama/llama-stack/issues/827 for the broader design. Third part: - we need to make `tool_runtime.rag_tool.query_context()` and `tool_runtime.rag_tool.insert_documents()` methods work smoothly with complete type safety. To that end, we introduce a sub-resource path `tool-runtime/rag-tool/` and make changes to the resolver to make things work. - the PR updates the agents implementation to directly call these typed APIs for memory accesses rather than going through the complex, untyped "invoke_tool" API. the code looks much nicer and simpler (expectedly.) - there are a number of hacks in the server resolver implementation still, we will live with some and fix some Note that we must make sure the client SDKs are able to handle this subresource complexity also. Stainless has support for subresources, so this should be possible but beware. ## Test Plan Our RAG test is sad (doesn't actually test for actual RAG output) but I verified that the implementation works. I will work on fixing the RAG test afterwards. ```bash pytest -s -v tests/agents/test_agents.py -k "rag and together" --safety-shield=meta-llama/Llama-Guard-3-8B ``` |
||
|---|---|---|
| .. | ||
| agents | ||
| batch_inference | ||
| common | ||
| datasetio | ||
| datasets | ||
| eval | ||
| eval_tasks | ||
| inference | ||
| inspect | ||
| models | ||
| post_training | ||
| safety | ||
| scoring | ||
| scoring_functions | ||
| shields | ||
| synthetic_data_generation | ||
| telemetry | ||
| tools | ||
| vector_dbs | ||
| vector_io | ||
| __init__.py | ||
| datatypes.py | ||
| resource.py | ||
| version.py | ||