[功能请求]: 每个呼叫的提供商上下文 - 没有支持将请求范围的数据附加到查询的 LLM、嵌入或重排呼叫中

是否需要提交功能请求？ - [x] 我已经搜索了现有的功能请求，此功能请求尚未提交。 - [x] 我认为这是一个合法的功能请求，而不仅仅是一个问题或错误。 ### 功能请求描述 没有支持的方式可以将请求范围的数据附加到出站提供者调用中，以触发单个查询。一个常见的需求是将呼叫者范围的身份（例如，头部值）转发到这些调用中，以便下游代理/可观测性层可以将它们归类为正确的最终用户。一个查询可以进行三种类型的出站提供者调用 - LLM 完成，嵌入（用于向查询文本本身进行向量搜索，并在本地/全局/混合/混合模式中进行关键字搜索），以及在启用时，重新排序调用。自然的方法 - 在调用 aquery/aquery_llm 之前设置 contextvars.ContextVar，在自定义 llm_model_func/embedding_func/rerank_model_func 中读取它 - 与 LightRAG 如何调度这些调用无关。每个都被 priority_limit_async_func_call (lightrag/utils.py) 封装一次，在一个小的、固定池中持久的 asyncio.Task 工作中，在首次使用时创建，并且在每次调用时都不会重新创建。一个调用被交给一个工作作为一个简单的元组，放在一个 asyncio.PriorityQueue 上；工作在 其自己的 任务上下文中执行，捕获在工作任务首次创建时 - 远远在任何特定请求存在之前。来自调用者自己的任务所做的 ContextVar.set() 在该工作任务中是不可见的。这是正确的、标准的 asyncio 行为（contextvars 通过任务/协程链传播，或者在 asyncio.create_task() 时复制 - 从来不通过独立的队列传递），而不是队列本身的一个错误，但这确实意味着目前没有一个干净的方法来在每次调用中将数据传递到这些调用中，而不需要在调用者端重新实现队列自己的并发限制和超时处理。建议：在 QueryParam 中添加字段，以便调用者可以为该查询的提供者调用附加额外的关键字参数 - 在每个调用点合并为普通数据，因此它们在队列中完全像其他已有的关键字参数（system_prompt、stream 等）一样，而不需要绕过队列的并发限制或超时处理。每种调用的一个字段（LLM / 嵌入 / 重新排序），因为这些是具有不同签名的不同可调用对象，通常是完全不同的提供者 - 迫使一个来自调用者的字典适用于所有三种调用有可能与另一个冲突，或者被另一个默默拒绝。考虑过的替代方案：扩展 RoleLLMConfig (lightrag/llm_roles.py)。被拒绝 - 该配置是故意针对每个角色的，并且在角色处理的每个调用中都是静态的，而此处需要在每个单独调用中提供新值，而只有针对每个查询的字段才能表达这一点。我已经为此编写了一个工作的补丁，并将在不久的将来开启一个 PR。 ### 额外上下文 问题的总体形状与其他几个开放项目相同，…