851 lines
75 KiB
Markdown
851 lines
75 KiB
Markdown
## FunctionDef wrap_done(fn, event)
|
||
**wrap_done**: 此函数的功能是将一个可等待对象（Awaitable）与一个事件（Event）包装起来，以便在可等待对象完成或抛出异常时通知事件。
|
||
|
||
**参数**:
|
||
- `fn`: 一个可等待对象（Awaitable），通常是一个异步函数或任务。
|
||
- `event`: 一个`asyncio.Event`事件，用于在`fn`完成或抛出异常时进行通知。
|
||
|
||
**代码描述**:
|
||
`wrap_done`函数设计用于异步编程环境中，它接受一个可等待对象和一个事件作为参数。函数内部首先尝试等待可等待对象`fn`的完成。如果在等待过程中`fn`执行成功，则直接进入`finally`块；如果`fn`执行过程中抛出异常，则会被`except`块捕获。在异常捕获块中，首先通过`logging.exception`记录异常信息，然后构造一个包含异常信息的消息，并使用`logger.error`记录错误信息，其中是否记录详细的异常信息取决于`log_verbose`变量的值。无论`fn`的执行结果如何，最终都会执行`finally`块，在这里通过调用`event.set()`方法来通知事件，表示`fn`的执行已经完成或发生了异常。
|
||
|
||
在项目中，`wrap_done`函数被多个模块调用，主要用于处理异步任务的执行并在任务完成或发生异常时进行通知。例如，在`agent_chat_iterator`、`chat_iterator`、`completion_iterator`、`knowledge_base_chat_iterator`和`search_engine_chat_iterator`等异步迭代器中，`wrap_done`被用来包装异步调用链，以便在异步任务完成时通过事件通知机制更新状态或处理结果。这种模式允许项目中的异步流程能够更加灵活地处理异步任务的完成情况，特别是在需要根据异步任务的执行结果进行后续操作时。
|
||
|
||
**注意**:
|
||
- 使用`wrap_done`函数时，需要确保传入的`fn`是一个正确的可等待对象，例如异步函数调用或`asyncio`任务。
|
||
- `event`参数应该是一个`asyncio.Event`实例，它用于在`fn`完成或发生异常时进行通知。
|
||
- 在异常处理中，根据`log_verbose`变量的设置决定是否记录详细的异常信息，这需要根据实际的日志记录需求来配置。
|
||
- `wrap_done`函数的使用场景主要集中在需要异步执行并在完成时进行通知的情况，因此在设计异步流程时应考虑如何合理利用此函数以优化异步任务的处理逻辑。
|
||
## FunctionDef get_ChatOpenAI(model_name, temperature, max_tokens, streaming, callbacks, verbose)
|
||
**get_ChatOpenAI**: 此函数的功能是初始化并返回一个ChatOpenAI实例。
|
||
|
||
**参数**:
|
||
- model_name: 字符串类型，指定要使用的模型名称。
|
||
- temperature: 浮点数，用于控制生成文本的多样性。
|
||
- max_tokens: 整型或None，默认为None，指定生成文本的最大token数量。
|
||
- streaming: 布尔类型，默认为True，指定是否以流式传输模式运行模型。
|
||
- callbacks: 回调函数列表，默认为空列表，用于处理模型生成的文本。
|
||
- verbose: 布尔类型，默认为True，指定是否在控制台输出详细信息。
|
||
- **kwargs: 接受任意额外的关键字参数。
|
||
|
||
**代码描述**:
|
||
函数首先调用`get_model_worker_config`函数，根据提供的`model_name`获取模型的配置信息。如果`model_name`为"openai-api"，则会根据配置中的`model_name`更新变量`model_name`。接着，函数设置`ChatOpenAI`类的`_get_encoding_model`方法为`MinxChatOpenAI`类的`get_encoding_model`方法，这是为了确保`ChatOpenAI`实例能够获取正确的编码模型。之后，使用提供的参数和配置信息初始化`ChatOpenAI`实例。最终，函数返回这个初始化好的`ChatOpenAI`实例。
|
||
|
||
**注意**:
|
||
- 在使用此函数之前，请确保已经正确配置了模型的相关信息，包括API密钥和基础URL等。
|
||
- 如果`model_name`指定的模型不支持或配置有误，可能会导致初始化失败。
|
||
- `callbacks`参数允许用户传入自定义的回调函数，这些函数可以在模型生成文本时被调用，用于处理生成的文本或执行其他自定义逻辑。
|
||
|
||
**输出示例**:
|
||
调用`get_ChatOpenAI`函数可能返回的示例输出为：
|
||
```python
|
||
ChatOpenAI(streaming=True, verbose=True, callbacks=[], openai_api_key="YOUR_API_KEY", openai_api_base="https://api.example.com", model_name="gpt-3.5-turbo", temperature=0.7, max_tokens=1024, openai_proxy=None)
|
||
```
|
||
这表示函数返回了一个配置好的`ChatOpenAI`实例，该实例使用了"gpt-3.5-turbo"模型，温度设置为0.7，最大token数量为1024，且启用了流式传输和详细输出。
|
||
## FunctionDef get_OpenAI(model_name, temperature, max_tokens, streaming, echo, callbacks, verbose)
|
||
**get_OpenAI**: 此函数的功能是初始化并返回一个配置好的OpenAI模型实例。
|
||
|
||
**参数**:
|
||
- model_name: 字符串类型，指定使用的模型名称。
|
||
- temperature: 浮点数，控制生成文本的创造性。
|
||
- max_tokens: 整型或None，默认为None，指定生成文本的最大令牌数。
|
||
- streaming: 布尔类型，默认为True，指示是否启用流式传输。
|
||
- echo: 布尔类型，默认为True，指示是否回显输入。
|
||
- callbacks: 回调函数列表，默认为空列表，用于处理模型的输出。
|
||
- verbose: 布尔类型，默认为True，控制是否输出详细信息。
|
||
- **kwargs: 接受任意额外的关键字参数。
|
||
|
||
**代码描述**:
|
||
`get_OpenAI` 函数首先通过调用`get_model_worker_config`函数获取指定模型的配置信息。如果模型名称为"openai-api"，则会根据配置信息中的"model_name"更新模型名称。接着，函数创建一个`OpenAI`实例，配置包括是否启用流式传输、是否输出详细信息、回调函数列表、OpenAI API密钥、OpenAI API基础URL、模型名称、温度、最大令牌数、OpenAI代理以及是否回显输入等。最后，函数返回配置好的`OpenAI`模型实例。
|
||
|
||
**注意**:
|
||
- 确保在调用此函数之前，已经正确配置了OpenAI API密钥和基础URL。
|
||
- 如果提供的模型名称为"openai-api"，则会根据配置自动更新模型名称，因此需要确保相关配置正确。
|
||
- 回调函数列表允许用户自定义处理模型输出的逻辑，根据需要添加回调函数。
|
||
|
||
**输出示例**:
|
||
由于`get_OpenAI`函数返回的是一个`OpenAI`实例，因此输出示例将依赖于`OpenAI`类的实现。假设`OpenAI`类的实例化结果如下：
|
||
```python
|
||
OpenAI(
|
||
streaming=True,
|
||
verbose=True,
|
||
callbacks=[],
|
||
openai_api_key="YOUR_API_KEY",
|
||
openai_api_base="https://api.openai.com",
|
||
model_name="text-davinci-003",
|
||
temperature=0.7,
|
||
max_tokens=100,
|
||
openai_proxy=None,
|
||
echo=True
|
||
)
|
||
```
|
||
此示例展示了一个配置了流式传输、详细输出、无回调函数、指定API密钥和基础URL、使用"text-davinci-003"模型、温度为0.7、最大令牌数为100、无代理、并启用输入回显的`OpenAI`模型实例。
|
||
## ClassDef BaseResponse
|
||
**BaseResponse**: BaseResponse 类是用于构建统一的 API 响应格式。
|
||
|
||
**属性**:
|
||
- `code`: API 状态码，用于表示请求处理的结果，如200表示成功。
|
||
- `msg`: API 状态消息，用于提供更详细的处理结果信息，如"success"表示操作成功。
|
||
- `data`: API 数据，用于存放请求返回的数据，可以是任意类型。
|
||
|
||
**代码描述**:
|
||
BaseResponse 类继承自 BaseModel，利用 Pydantic 库进行数据验证和序列化。它定义了三个主要字段：`code`、`msg`和`data`，分别用于表示 API 的状态码、状态消息和返回的数据内容。此外，通过 Pydantic 的 Field 函数，为每个字段提供了默认值和描述信息，以便于生成 OpenAPI 文档时提供更丰富的信息。例如，`code`字段默认值为200，`msg`字段默认值为"success"，而`data`字段默认为None，表示没有数据返回。
|
||
|
||
BaseResponse 类还定义了一个内部类 Config，其中`schema_extra`属性用于提供示例数据，这有助于在自动生成的 API 文档中展示如何使用该响应格式。
|
||
|
||
在项目中，BaseResponse 类被广泛用于各个 API 接口的响应模型。例如，在`mount_app_routes`函数中，通过`response_model=BaseResponse`参数，指定了根路由("/")的响应模型为 BaseResponse，这意味着该路由的响应将遵循 BaseResponse 定义的格式。同样，在其他如`chat_feedback`、`upload_temp_docs`、`file_chat`等多个 API 接口中，也使用了 BaseResponse 作为响应模型，确保了 API 响应的一致性和标准化。
|
||
|
||
**注意**:
|
||
- 使用 BaseResponse 作为响应模型时，应根据实际情况填充`code`、`msg`和`data`字段，以确保返回给客户端的信息准确无误。
|
||
- 在定义 API 接口时，通过指定`response_model=BaseResponse`参数，可以让 FastAPI 自动将函数的返回值转换为 BaseResponse 指定的格式，这有助于减少重复代码并提高开发效率。
|
||
- 在实际使用中，可以根据需要对 BaseResponse 进行扩展，添加额外的字段或方法，以满足特定的业务需求。
|
||
### ClassDef Config
|
||
**Config**: Config 类的功能是定义一个配置信息的结构和示例。
|
||
|
||
**属性**:
|
||
- `schema_extra`: 用于定义配置信息的额外模式示例。
|
||
|
||
**代码描述**:
|
||
Config 类中定义了一个名为 `schema_extra` 的类属性。这个属性是一个字典，用于提供配置信息的示例。在这个示例中，包含了两个键值对："code" 和 "msg"。"code" 的值设置为 200，表示一个成功的状态码；"msg" 的值设置为 "success"，表示操作成功的消息。这个结构通常用于API响应的标准格式，帮助开发者理解预期的响应结构和内容。
|
||
|
||
**注意**:
|
||
- `schema_extra` 属性主要用于文档和测试中，为开发者提供一个关于如何使用该配置的具体示例。它不会直接影响代码的逻辑功能，但是对于理解代码的结构和预期行为非常有帮助。
|
||
- 修改 `schema_extra` 中的值时，需要确保它们与实际应用中的配置信息保持一致，以避免混淆。
|
||
- 这个类可以根据实际需求扩展更多的配置项和示例，以适应不同的场景和需求。
|
||
***
|
||
## ClassDef ListResponse
|
||
**ListResponse**: ListResponse 类用于封装返回给客户端的列表数据响应。
|
||
|
||
**属性**:
|
||
- `data`: 存放名字列表的属性，类型为字符串列表。
|
||
|
||
**代码描述**: ListResponse 类继承自 BaseResponse 类，专门用于处理那些需要返回列表数据的API响应。通过使用 Pydantic 的 Field 函数，`data` 属性被定义为必须提供的字段，并附带了描述信息"List of names"，说明这个字段用于存放名字列表。此外，ListResponse 类通过内部类 Config 定义了一个示例，展示了如何使用这个类来构造一个包含状态码、状态消息和数据列表的响应体。示例中的数据包括一个成功的状态码200、一个成功消息"success"和一个包含三个文档名的列表。
|
||
|
||
在项目中，ListResponse 类被用于那些需要返回文件名列表或其他字符串列表的API接口。例如，在知识库管理功能中，获取知识库列表和知识库内文件列表的API接口就使用了ListResponse作为响应模型。这样做不仅保证了API响应格式的一致性，也使得API的使用者能够清晰地了解到响应中将包含哪些数据。
|
||
|
||
**注意**:
|
||
- 在使用 ListResponse 类时，需要确保`data`属性中填充的是正确的列表数据。虽然 ListResponse 类提供了数据类型和结构的基本验证，但是填充数据的准确性和相关性需要开发者自行保证。
|
||
- ListResponse 类继承自 BaseResponse 类，因此它自动拥有了`code`和`msg`两个属性，分别用于表示API响应的状态码和状态消息。在实际使用中，开发者应根据实际情况设置这两个属性的值，以确保响应信息的准确性和有用性。
|
||
- 通过在 Config 类中定义`schema_extra`属性，ListResponse 类为自动生成的API文档提供了丰富的示例，有助于开发者和API的使用者更好地理解如何使用该响应格式。开发者在扩展或修改ListResponse类时，应考虑更新这些示例数据，以保持文档的准确性和实用性。
|
||
### ClassDef Config
|
||
**Config**: Config 类的功能是定义模式额外信息。
|
||
|
||
**属性**:
|
||
- `schema_extra`: 用于定义额外的模式信息。
|
||
|
||
**代码描述**:
|
||
Config 类是一个简单的配置类，其主要作用是通过 `schema_extra` 属性提供一个示例配置。这个示例配置是一个字典，包含了 `code`、`msg` 和 `data` 三个键。`code` 键对应的值是一个整数，表示状态码；`msg` 键对应的值是一个字符串，表示消息内容；`data` 错对应的值是一个字符串列表，表示数据内容。此配置主要用于文档或API响应示例中，帮助开发者理解预期的响应格式。
|
||
|
||
在这个示例中，`code` 设置为 200，表示请求成功；`msg` 设置为 "success"，表示操作成功的消息；`data` 包含了三个字符串，分别是 "doc1.docx"、"doc2.pdf" 和 "doc3.txt"，模拟了一个文件列表的返回数据。
|
||
|
||
**注意**:
|
||
- `schema_extra` 在这里是作为一个类属性存在的，这意味着它是与类相关联而不是与类的实例相关联的。因此，对 `schema_extra` 的任何修改都会影响到所有使用这个类的地方。
|
||
- 这个类主要用于提供API响应的示例配置，以便在自动生成文档或进行API测试时使用。开发者应根据实际需求调整 `schema_extra` 中的内容，以确保它正确反映了API的预期响应。
|
||
***
|
||
## ClassDef ChatMessage
|
||
**ChatMessage**: ChatMessage 的功能是定义聊天消息的数据结构。
|
||
|
||
**属性**:
|
||
- `question`: 问题文本。
|
||
- `response`: 响应文本。
|
||
- `history`: 历史文本列表，每个元素也是一个包含字符串的列表，代表一次对话的问答。
|
||
- `source_documents`: 来源文档列表，包含相关文档及其得分的信息。
|
||
|
||
**代码描述**:
|
||
ChatMessage 类继承自 BaseModel，用于表示聊天中的一条消息。该类通过 Pydantic 库定义，确保数据有效性和类型安全。每个属性都使用了 Pydantic 的 Field 方法进行详细定义，包括类型信息和描述文本。
|
||
|
||
- `question` 属性定义了提问的文本内容，是一个字符串类型。
|
||
- `response` 属性定义了对提问的回答，同样是一个字符串类型。
|
||
- `history` 属性记录了与当前消息相关的历史对话，是一个列表，其中每个元素也是一个列表，包含了一系列的问答对。
|
||
- `source_documents` 属性提供了生成回答时参考的源文档列表。这些文档可能是从外部数据库、文件或其他信息源中检索到的，用于支持回答的生成。
|
||
|
||
此外，ChatMessage 类中定义了一个 Config 子类，其中的 `schema_extra` 字段提供了一个示例，展示了如何填充 ChatMessage 类的实例。这个示例包括了一个典型的问题、相应的回答、相关的历史对话以及参考的源文档。
|
||
|
||
**注意**:
|
||
- 使用 ChatMessage 类时，需要确保所有字段都符合定义的类型和结构要求。特别是 `history` 和 `source_documents` 属性，它们都是列表类型，需要正确地构造列表元素。
|
||
- `schema_extra` 中的示例仅用于说明如何使用 ChatMessage 类，并不意味着实际应用中的数据必须与示例完全一致。开发者应根据实际情况填充这些字段。
|
||
- 由于 ChatMessage 类使用了 Pydantic 库，可以利用 Pydantic 提供的数据验证功能来确保数据的正确性和完整性。在实际应用中，可以通过定义更多的验证规则来进一步增强数据的安全性和可靠性。
|
||
### ClassDef Config
|
||
**Config**: Config 类的功能是提供一个示例配置，用于说明如何处理和响应工伤保险相关的查询。
|
||
|
||
**属性**:
|
||
- `schema_extra`: 一个字典，包含了一个示例配置，用于展示如何回答有关工伤保险的问题。
|
||
|
||
**代码描述**:
|
||
Config 类定义了一个名为 `schema_extra` 的类属性，该属性是一个字典。这个字典内嵌套了一个名为 "example" 的键，其值也是一个字典，用于提供一个具体的示例，展示如何回答关于工伤保险的问题。这个示例包含了问题（"question"）、回答（"response"）、历史问答（"history"）和来源文件（"source_documents"）四个部分。
|
||
|
||
- "question" 键对应的值是一个字符串，表示提出的问题。
|
||
- "response" 键对应的值是一个字符串，详细描述了对问题的回答，包括工伤保险的办理流程和待遇。
|
||
- "history" 键对应的值是一个列表，每个元素也是一个列表，表示之前相关的问答。
|
||
- "source_documents" 键对应的值是一个列表，包含了回答依据的文档来源，每个元素是一个字符串，描述了文档的出处和相关内容。
|
||
|
||
**注意**:
|
||
- Config 类主要用于提供示例配置，帮助开发者理解如何构建和使用类似的配置结构。
|
||
- 在实际应用中，开发者可以根据具体需求修改或扩展 `schema_extra` 中的内容，以适应不同的场景和需求。
|
||
- 示例中的问题、回答、历史问答和来源文件仅用于演示，开发者应根据实际情况填充相应的内容。
|
||
***
|
||
## FunctionDef torch_gc
|
||
**torch_gc**: 此函数的功能是清理PyTorch在CUDA或MPS后端上的缓存内存。
|
||
|
||
**参数**: 此函数不接受任何参数。
|
||
|
||
**代码描述**: `torch_gc`函数首先尝试导入PyTorch库。如果成功，它会检查CUDA是否可用。如果CUDA可用，该函数会调用`torch.cuda.empty_cache()`和`torch.cuda.ipc_collect()`来清空CUDA的缓存内存，以及收集跨进程分配的共享内存。这有助于在使用CUDA进行大量计算时释放未使用的内存，从而避免内存溢出或性能下降的问题。
|
||
|
||
如果CUDA不可用，函数会检查MPS（Apple Metal Performance Shaders）是否可用，这是针对macOS系统的。如果MPS可用，它会尝试从`torch.mps`模块导入并调用`empty_cache()`函数来清理MPS的缓存内存。如果在尝试导入或调用过程中出现任何异常，函数会捕获这些异常并记录一条错误消息，建议用户将PyTorch版本升级到2.0.0或更高版本以获得更好的内存管理支持。
|
||
|
||
在项目中，`torch_gc`函数被`FaissKBService`类的`do_add_doc`方法调用。在`do_add_doc`方法中，`torch_gc`被用于在添加文档到知识库并更新向量存储后，清理PyTorch的缓存内存。这是因为在处理大量数据并使用PyTorch进行向量化操作时，可能会产生大量的内存占用。通过调用`torch_gc`，可以帮助释放这些未使用的内存，从而避免内存溢出错误，确保系统的稳定性和性能。
|
||
|
||
**注意**: 使用`torch_gc`函数时，需要确保PyTorch已正确安装，并且系统支持CUDA或MPS。此外，如果在macOS系统上使用且遇到相关的内存清理问题，应考虑将PyTorch版本升级到2.0.0或更高版本。
|
||
## FunctionDef run_async(cor)
|
||
**run_async**: 此函数的功能是在同步环境中运行异步代码。
|
||
|
||
**参数**:
|
||
- cor: 需要运行的异步协程对象。
|
||
|
||
**代码描述**:
|
||
`run_async` 函数旨在解决在同步代码环境中执行异步协程的需求。它首先尝试获取当前事件循环，如果当前没有事件循环，则会创建一个新的事件循环。此函数接受一个异步协程对象作为参数，并在获取或创建的事件循环中运行这个协程，直到该协程执行完成。通过这种方式，即使在同步代码中，也能够方便地执行异步操作。
|
||
|
||
在函数实现中，首先通过`asyncio.get_event_loop()`尝试获取当前线程的事件循环。如果当前线程没有运行的事件循环，这一步骤可能会抛出异常。为了处理这种情况，函数使用`try-except`结构捕获异常，并通过`asyncio.new_event_loop()`创建一个新的事件循环。最后，使用`loop.run_until_complete(cor)`运行传入的协程对象`cor`，并返回执行结果。
|
||
|
||
**注意**:
|
||
- 在使用此函数时，需要确保传入的`cor`参数是一个异步协程对象。
|
||
- 如果在一个已经运行的事件循环中调用此函数，可能会导致错误。因此，最好在确保没有正在运行的事件循环的情况下使用此函数。
|
||
- 在函数执行结束后，事件循环会停止，但不会关闭。如果需要在之后的代码中继续使用事件循环，可能需要手动管理事件循环的生命周期。
|
||
|
||
**输出示例**:
|
||
假设有一个异步函数`async_function`，返回值为`"Hello, Async World!"`，则使用`run_async(async_function())`的返回值可能如下：
|
||
```
|
||
"Hello, Async World!"
|
||
```
|
||
## FunctionDef iter_over_async(ait, loop)
|
||
**iter_over_async**: 将异步生成器封装成同步生成器。
|
||
|
||
**参数**：
|
||
- **ait**: 需要被封装的异步生成器。
|
||
- **loop**: 可选参数，指定事件循环。如果未提供，则尝试获取当前线程的事件循环，若获取失败，则创建一个新的事件循环。
|
||
|
||
**代码描述**：
|
||
`iter_over_async` 函数主要用于将异步生成器的迭代过程转换为同步过程，以便在不支持异步迭代的环境中使用。首先，通过调用`ait.__aiter__()`获取异步迭代器。然后定义一个异步函数`get_next`，该函数尝试通过`await ait.__anext__()`获取下一个元素，如果成功，则返回`(False, obj)`，其中`obj`是获取到的元素；如果迭代结束，捕获`StopAsyncIteration`异常，返回`(True, None)`表示迭代结束。
|
||
|
||
如果调用时没有提供事件循环（`loop`参数为`None`），函数会尝试获取当前线程的事件循环，如果失败，则创建一个新的事件循环。
|
||
|
||
接下来，函数进入一个无限循环，每次循环中通过`loop.run_until_complete(get_next())`同步地执行`get_next`函数，获取下一个元素或者迭代结束的信号。如果迭代结束，循环将中断；否则，yield返回当前获取到的元素，实现了将异步生成器的元素同步地逐个输出。
|
||
|
||
在项目中，`iter_over_async`函数被`server/model_workers/xinghuo.py/XingHuoWorker/do_chat`方法调用，用于处理异步请求的响应数据。在`do_chat`方法中，通过`iter_over_async`函数同步地处理从异步API请求返回的数据流，使得可以在一个同步函数中逐步处理异步获取的数据，提高了代码的可读性和易用性。
|
||
|
||
**注意**：
|
||
- 使用此函数时，需要确保传入的`ait`参数是一个异步生成器。
|
||
- 如果在异步环境中使用此函数，应当注意事件循环的管理，避免事件循环的冲突。
|
||
|
||
**输出示例**：
|
||
假设有一个异步生成器`async_gen`，每次异步返回一个数字，使用`iter_over_async`进行迭代时，可能的输出为：
|
||
```python
|
||
for num in iter_over_async(async_gen):
|
||
print(num)
|
||
```
|
||
输出：
|
||
```
|
||
1
|
||
2
|
||
3
|
||
...
|
||
```
|
||
### FunctionDef get_next
|
||
**get_next函数的功能**: 异步获取下一个对象。
|
||
|
||
**参数**: 此函数不接受任何外部参数。
|
||
|
||
**代码描述**: `get_next` 是一个异步函数，旨在从异步迭代器中获取下一个元素。函数首先尝试通过调用 `ait.__anext__()` 异步获取下一个元素。如果成功，函数将返回一个元组，第一个元素为 `False`，表示未到达迭代器的末尾，第二个元素为获取到的对象。如果在尝试获取下一个元素时遇到 `StopAsyncIteration` 异常，表示迭代器已经没有更多元素可以返回，此时函数将返回一个元组，第一个元素为 `True`，表示已到达迭代器的末尾，第二个元素为 `None`。
|
||
|
||
**注意**: 使用此函数时，需要确保 `ait` 是一个异步迭代器对象，并且已经被正确初始化。此外，由于这是一个异步函数，调用它时需要使用 `await` 关键字或在其他异步上下文中。
|
||
|
||
**输出示例**:
|
||
- 当迭代器中还有元素时，可能的返回值为 `(False, obj)`，其中 `obj` 是从迭代器中获取的下一个对象。
|
||
- 当迭代器中没有更多元素时，返回值为 `(True, None)`。
|
||
***
|
||
## FunctionDef MakeFastAPIOffline(app, static_dir, static_url, docs_url, redoc_url)
|
||
**MakeFastAPIOffline**: 此函数的功能是为FastAPI应用程序提供离线文档支持，使其不依赖于CDN来加载Swagger UI和ReDoc文档页面。
|
||
|
||
**参数**:
|
||
- `app`: FastAPI对象，需要被修改以支持离线文档。
|
||
- `static_dir`: 静态文件目录的路径，默认为当前文件所在目录下的"static"文件夹。
|
||
- `static_url`: 服务静态文件的URL路径，默认为"/static-offline-docs"。
|
||
- `docs_url`: Swagger UI文档的URL路径，默认为"/docs"。
|
||
- `redoc_url`: ReDoc文档的URL路径，默认为"/redoc"。
|
||
|
||
**代码描述**:
|
||
此函数首先从FastAPI和starlette模块中导入所需的类和函数。然后，它定义了一个内部函数`remove_route`，用于从FastAPI应用中移除指定的路由。接着，函数通过`app.mount`方法挂载静态文件目录，使得Swagger UI和ReDoc所需的静态文件可以从本地服务器提供，而不是通过外部CDN加载。
|
||
|
||
如果`docs_url`参数不为None，函数会移除原有的Swagger UI路由，并添加一个新的路由，该路由返回一个自定义的Swagger UI HTML页面，其中所有资源的URL都被修改为指向本地静态文件目录。
|
||
|
||
类似地，如果`redoc_url`参数不为None，函数会移除原有的ReDoc路由，并添加一个新的路由，该路由返回一个自定义的ReDoc HTML页面，其中资源的URL也被修改为指向本地静态文件目录。
|
||
|
||
此函数通过修改FastAPI应用的路由和静态文件配置，实现了一个不依赖于外部CDN的离线文档系统。
|
||
|
||
**在项目中的应用**:
|
||
在项目中，`MakeFastAPIOffline`函数被用于不同的FastAPI应用创建过程中，以确保这些应用能够在没有外部网络连接的环境下，仍然提供完整的API文档。例如，在`create_app`、`create_controller_app`、`create_model_worker_app`和`create_openai_api_app`等函数中，都调用了`MakeFastAPIOffline`来实现离线文档的功能。这表明项目中的多个组件都需要在离线环境下提供API文档，以便开发者和用户即使在没有互联网连接的情况下也能访问和了解API的使用方法。
|
||
|
||
**注意**:
|
||
- 确保`static_dir`参数指向的目录中包含了Swagger UI和ReDoc所需的所有静态文件，包括JavaScript、CSS文件和图标等。
|
||
- 修改`docs_url`和`redoc_url`参数时，需要确保这些URL不与应用中已有的路由冲突。
|
||
|
||
**输出示例**: 由于此函数没有返回值，因此没有输出示例。此函数的主要作用是修改传入的FastAPI应用对象，添加离线文档支持。
|
||
### FunctionDef remove_route(url)
|
||
**remove_route**: 此函数的功能是从应用中移除指定的路由。
|
||
|
||
**参数**:
|
||
- **url**: 需要被移除的路由的URL，类型为字符串。
|
||
|
||
**代码描述**:
|
||
`remove_route` 函数接受一个参数 `url`，其目的是从 FastAPI 应用的路由列表中移除与给定 `url` 匹配的路由。函数首先初始化一个名为 `index` 的变量，用于存储需要被移除的路由的索引位置。通过遍历 `app.routes`，即应用中所有路由的列表，函数比较每个路由对象的 `path` 属性（即路由的URL路径）与给定的 `url` 是否相同（这里的比较忽略大小写）。一旦找到匹配的路由，就将其索引赋值给 `index` 并跳出循环。
|
||
|
||
如果 `index` 是一个整数（这意味着找到了匹配的路由），函数则通过 `pop` 方法从 `app.routes` 列表中移除该索引对应的路由对象。这样，指定的路由就从应用中被成功移除。
|
||
|
||
**注意**:
|
||
- 在使用此函数时，确保传入的 `url` 参数确实对应于应用中的一个有效路由。如果传入了一个不存在的路由URL，函数将不会执行任何操作。
|
||
- 由于此函数直接修改了 `app.routes`，请谨慎使用，以避免不小心移除了不应该被移除的路由。
|
||
- 确保在调用此函数之前，`app` 对象已经被正确初始化并且包含了路由列表。此函数假定 `app` 是一个全局变量，且已经有路由被添加到了 `app.routes` 中。
|
||
***
|
||
### FunctionDef custom_swagger_ui_html(request)
|
||
**custom_swagger_ui_html函数的功能**: 生成并返回一个定制的Swagger UI HTML响应。
|
||
|
||
**参数**:
|
||
- `request`: Request对象，用于获取当前请求的信息。
|
||
|
||
**代码描述**:
|
||
`custom_swagger_ui_html`函数是一个异步函数，它接收一个`Request`对象作为参数，并返回一个`HTMLResponse`对象。该函数的主要作用是生成一个定制化的Swagger UI页面，用于API文档的展示。
|
||
|
||
函数首先从`request.scope`中获取`root_path`，这是当前应用的根路径。然后，它构造了一个favicon的URL，这是页面标签上显示的小图标的地址。
|
||
|
||
接下来，函数调用`get_swagger_ui_html`函数，传入了多个参数来定制Swagger UI页面：
|
||
- `openapi_url`：这是OpenAPI规范文件的URL，用于Swagger UI解析并展示API文档。
|
||
- `title`：页面的标题，这里通过`app.title`获取应用的标题，并附加了" - Swagger UI"。
|
||
- `oauth2_redirect_url`：OAuth2重定向URL，用于OAuth2认证流程。
|
||
- `swagger_js_url`和`swagger_css_url`：分别是Swagger UI的JavaScript和CSS文件的URL，用于页面的样式和功能。
|
||
- `swagger_favicon_url`：页面标签上显示的小图标的URL。
|
||
|
||
**注意**:
|
||
- 确保`request.scope`中包含`root_path`，否则可能导致路径解析错误。
|
||
- `get_swagger_ui_html`函数需要从外部导入，确保在使用前已正确导入。
|
||
- 该函数依赖于FastAPI的应用实例`app`和相关配置变量（如`openapi_url`、`swagger_ui_oauth2_redirect_url`等），请确保这些变量在调用函数前已正确设置。
|
||
|
||
**输出示例**:
|
||
假设应用的标题为"My API"，根路径为"/api"，则该函数可能返回的HTMLResponse内容如下（实际内容会包含完整的HTML结构，这里仅展示关键信息）：
|
||
|
||
```html
|
||
<!DOCTYPE html>
|
||
<html lang="en">
|
||
<head>
|
||
<title>My API - Swagger UI</title>
|
||
<link rel="icon" type="image/png" href="/api/static/favicon.png" sizes="32x32" />
|
||
<link href="/api/static/swagger-ui.css" rel="stylesheet" />
|
||
</head>
|
||
<body>
|
||
<div id="swagger-ui"></div>
|
||
<script src="/api/static/swagger-ui-bundle.js"> </script>
|
||
</body>
|
||
</html>
|
||
```
|
||
|
||
这个HTML页面将加载Swagger UI，自动解析`openapi_url`指向的OpenAPI规范文件，并展示API文档。
|
||
***
|
||
### FunctionDef swagger_ui_redirect
|
||
**swagger_ui_redirect**: 此函数的功能是重定向到Swagger UI的OAuth2认证页面。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `swagger_ui_redirect`函数是一个异步函数，返回一个HTMLResponse对象。该函数调用`get_swagger_ui_oauth2_redirect_html`方法，此方法负责生成并返回一个包含OAuth2认证所需信息的HTML页面。这个页面通常用于API文档中，允许用户通过OAuth2进行认证，以便在测试API时能够进行身份验证。由于这是一个异步函数，它可以在FastAPI或其他支持异步操作的Web框架中使用，以提高处理请求的效率。
|
||
|
||
**注意**: 使用此函数时，需要确保`get_swagger_ui_oauth2_redirect_html`方法可用，并且已正确配置OAuth2认证。此外，由于它返回的是HTMLResponse，调用此函数的路由应该被配置为返回HTML内容。
|
||
|
||
**输出示例**:
|
||
```html
|
||
<!DOCTYPE html>
|
||
<html>
|
||
<head>
|
||
<title>OAuth2 Redirect</title>
|
||
</head>
|
||
<body>
|
||
<script>
|
||
// JavaScript代码，用于处理OAuth2重定向逻辑
|
||
</script>
|
||
</body>
|
||
</html>
|
||
```
|
||
上述输出示例展示了一个可能的HTML页面结构，实际内容将根据`get_swagger_ui_oauth2_redirect_html`方法的实现而有所不同。这个页面包含了处理OAuth2认证重定向所需的所有信息和逻辑。
|
||
***
|
||
### FunctionDef redoc_html(request)
|
||
**redoc_html**: 此函数的功能是生成并返回一个用于展示API文档的ReDoc页面的HTML响应。
|
||
|
||
**参数**:
|
||
- `request`: Request对象，用于获取当前请求的信息。
|
||
|
||
**代码描述**:
|
||
`redoc_html`函数是一个异步函数，它接收一个FastAPI的`Request`对象作为参数。此函数的主要作用是构建并返回一个ReDoc页面的HTML响应，用于展示OpenAPI文档。
|
||
|
||
函数首先从`request.scope`中获取`root_path`，这是当前应用的根路径。然后，它构造了favicon图标的URL，这是通过将根路径、静态文件路径以及favicon文件名拼接而成的。
|
||
|
||
接下来，函数调用`get_redoc_html`函数，传入以下参数：
|
||
- `openapi_url`：OpenAPI文档的URL，通过将根路径和OpenAPI文档的路径拼接而成。
|
||
- `title`：页面标题，这里是应用的标题加上" - ReDoc"。
|
||
- `redoc_js_url`：ReDoc JavaScript库的URL，通过将根路径和静态文件路径以及ReDoc库的文件名拼接而成。
|
||
- `with_google_fonts`：一个布尔值，指示是否从Google字体服务加载字体。在此处设置为`False`，表示不从Google加载字体。
|
||
- `redoc_favicon_url`：favicon图标的URL。
|
||
|
||
最后，`get_redoc_html`函数返回一个`HTMLResponse`对象，其中包含了用于展示API文档的ReDoc页面的HTML代码。
|
||
|
||
**注意**:
|
||
- 确保在调用此函数之前，应用的根路径、OpenAPI文档的路径以及静态文件路径已经正确设置。
|
||
- 此函数依赖于`get_redoc_html`函数，确保此函数可用且能正确返回`HTMLResponse`对象。
|
||
|
||
**输出示例**:
|
||
由于此函数返回的是一个`HTMLResponse`对象，其具体内容取决于`get_redoc_html`函数的实现和传入的参数。一般而言，返回的HTML响应会包含一个完整的ReDoc页面，允许用户通过浏览器查看和交互API文档。
|
||
***
|
||
## FunctionDef list_embed_models
|
||
**list_embed_models**: 此函数的功能是获取配置的嵌入模型名称列表。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `list_embed_models` 函数通过访问全局变量 `MODEL_PATH` 中的 `"embed_model"` 键，获取所有已配置的嵌入模型的名称，并以列表形式返回这些名称。这个函数在项目中主要用于检索可用的本地嵌入模型，以便在需要进行文本向量化处理时，能够选择合适的模型进行操作。
|
||
|
||
在项目的不同部分调用了此函数，以确保在执行文本嵌入或者其他与嵌入模型相关的操作时，能够使用到正确且有效的模型。例如，在 `embed_texts` 和 `aembed_texts` 函数中，通过调用 `list_embed_models` 来验证传入的 `embed_model` 是否为一个有效的、已配置的本地模型。如果是，那么将使用该模型进行文本的向量化处理；如果不是，将尝试其他途径或返回错误信息。此外，在 `knowledge_base_page` 函数中，此函数用于提供一个嵌入模型的列表，以供用户在创建或更新知识库时选择使用哪个模型进行文本嵌入。
|
||
|
||
**注意**: 使用此函数时，需要确保 `MODEL_PATH` 全局变量已正确配置，并且包含 `"embed_model"` 键，其值应为一个字典，字典中包含了所有可用的嵌入模型名称。
|
||
|
||
**输出示例**: 假设 `MODEL_PATH["embed_model"]` 包含了两个模型 `"model1"` 和 `"model2"`，那么调用 `list_embed_models()` 将返回 `["model1", "model2"]`。
|
||
## FunctionDef list_config_llm_models
|
||
**list_config_llm_models**: 此函数的功能是获取配置的大型语言模型（LLM）的不同类型。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `list_config_llm_models` 函数旨在从系统配置中检索并返回不同类型的大型语言模型（LLM）配置信息。它首先从全局变量 `FSCHAT_MODEL_WORKERS` 中复制所有工作模型配置，并移除默认配置（如果存在）。然后，函数构造并返回一个字典，该字典包含三种类型的模型配置：本地（`local`）、在线（`online`）和工作模型（`worker`）。每种类型下的模型配置也以字典形式组织，其中键为模型名称，值为相应的配置信息。
|
||
|
||
在项目中，`list_config_llm_models` 函数被多个对象调用，说明其在项目中扮演着核心角色。例如，在 `server/llm_api.py/list_config_models` 中，此函数用于根据请求体中指定的类型（如 `local`、`online`）获取相应的模型配置，并进一步获取每个模型的详细配置信息以构建响应数据。在 `server/utils.py/list_online_embed_models` 中，此函数用于获取在线模型的配置，并进一步检查这些模型是否支持嵌入功能，以筛选出可以进行嵌入操作的模型列表。
|
||
|
||
**注意**: 在使用此函数时，需要确保相关的全局变量（如 `FSCHAT_MODEL_WORKERS`、`MODEL_PATH` 和 `ONLINE_LLM_MODEL`）已被正确初始化并包含了有效的配置信息。此外，由于此函数返回的配置信息可能会直接影响到模型的加载和使用，因此在修改配置或扩展模型类型时应格外小心。
|
||
|
||
**输出示例**:
|
||
```python
|
||
{
|
||
"local": {
|
||
"llm_model_1": {"config1": "value1", "config2": "value2"},
|
||
"llm_model_2": {"config1": "value1", "config2": "value2"}
|
||
},
|
||
"online": {
|
||
"llm_model_online_1": {"config1": "value1", "config2": "value2"},
|
||
"llm_model_online_2": {"config1": "value1", "config2": "value2"}
|
||
},
|
||
"worker": {
|
||
"llm_model_worker_1": {"config1": "value1", "config2": "value2"},
|
||
"llm_model_worker_2": {"config1": "value1", "config2": "value2"}
|
||
}
|
||
}
|
||
```
|
||
此输出示例展示了函数可能返回的配置信息结构，其中包含了三种类型的模型配置，每种类型下可能包含多个模型及其配置信息。
|
||
## FunctionDef get_model_path(model_name, type)
|
||
**get_model_path**: 该函数的功能是根据模型名称和类型获取模型的路径。
|
||
|
||
**参数**:
|
||
- model_name: 字符串类型，指定要获取路径的模型名称。
|
||
- type: 字符串类型，可选参数，默认为None，指定模型的类型。
|
||
|
||
**代码描述**:
|
||
`get_model_path` 函数主要用于在项目中根据提供的模型名称（`model_name`）和可选的模型类型（`type`）来确定模型文件的存储路径。该函数首先检查是否提供了模型类型，并尝试在预定义的模型路径字典（`MODEL_PATH`）中查找对应的路径。如果没有提供类型或者提供的类型在字典中找不到，函数会遍历字典中所有的值来构建一个包含所有路径的字典。
|
||
|
||
接下来，函数尝试从构建的路径字典中获取模型名称对应的路径字符串。如果找到路径字符串，函数会进行几个判断：
|
||
1. 如果路径字符串直接指向一个目录，则返回该目录的绝对路径。
|
||
2. 如果不是直接的目录路径，函数会尝试将`MODEL_ROOT_PATH`作为根目录，结合模型名称或路径字符串，检查是否存在对应的目录。函数会尝试以下几种组合方式来定位目录：
|
||
- 使用模型名称作为子目录名。
|
||
- 使用完整的路径字符串作为子目录路径。
|
||
- 使用路径字符串分割后的最后一部分作为子目录名。
|
||
|
||
如果以上步骤都未能定位到一个存在的目录，函数最终会返回原始的路径字符串。
|
||
|
||
在项目中，`get_model_path` 函数被用于不同场景，例如在`load_embeddings`方法中，根据模型名称获取模型的存储路径，用于加载嵌入式模型。在`get_model_worker_config`函数中，用于获取模型工作配置时确定模型路径。
|
||
|
||
**注意**:
|
||
- 确保`MODEL_PATH`和`MODEL_ROOT_PATH`变量已根据项目需求正确配置，以便函数能正确解析和返回模型路径。
|
||
- 函数返回的路径可能是一个绝对路径，也可能是相对于某个根目录的相对路径，具体取决于模型的存储方式和配置。
|
||
|
||
**输出示例**:
|
||
- 假设`MODEL_ROOT_PATH`为`/models`，`MODEL_PATH`中包含`{"type1": {"modelA": "path/to/modelA"}}`，调用`get_model_path("modelA", "type1")`可能返回`"/models/path/to/modelA"`。
|
||
## FunctionDef get_model_worker_config(model_name)
|
||
**get_model_worker_config**: 此函数的功能是加载指定模型工作配置项。
|
||
|
||
**参数**:
|
||
- model_name: 字符串类型，可选参数，默认为None，指定要加载配置的模型名称。
|
||
|
||
**代码描述**: `get_model_worker_config` 函数主要用于加载和合并指定模型的配置项。函数首先从`configs.model_config`和`configs.server_config`模块导入`ONLINE_LLM_MODEL`、`MODEL_PATH`和`FSCHAT_MODEL_WORKERS`配置。然后，函数以`FSCHAT_MODEL_WORKERS`中的"default"配置项为基础，创建一个新的配置字典`config`。接下来，函数尝试更新`config`字典，首先使用`model_name`在`ONLINE_LLM_MODEL`中查找并更新配置，然后在`FSCHAT_MODEL_WORKERS`中查找并更新配置。
|
||
|
||
如果`model_name`在`ONLINE_LLM_MODEL`中存在，函数将在`config`中设置`"online_api"`为True，并尝试从`model_workers`模块动态加载指定的`provider`类到`config`的`"worker_class"`中。如果加载过程中出现异常，函数将记录错误信息。
|
||
|
||
对于本地模型，如果`model_name`在`MODEL_PATH["llm_model"]`中存在，函数将调用`get_model_path`函数获取模型路径，并更新`config`中的`"model_path"`。如果路径存在且为目录，`config`中还将设置`"model_path_exists"`为True。最后，函数使用`llm_device`函数确定并设置模型运行的设备类型。
|
||
|
||
**注意**:
|
||
- 确保在调用此函数之前，相关的配置文件`model_config`和`server_config`已正确设置，且包含所需的模型名称和默认配置。
|
||
- 函数依赖于`model_workers`模块中定义的类，如果指定的`provider`不存在，将记录错误信息。
|
||
- 此函数同时处理在线模型和本地模型的配置加载，确保`MODEL_PATH`中包含正确的模型路径信息。
|
||
|
||
**输出示例**:
|
||
假设`FSCHAT_MODEL_WORKERS`中包含默认配置和名为"example_model"的配置，`ONLINE_LLM_MODEL`中也包含名为"example_model"的配置，调用`get_model_worker_config("example_model")`可能返回如下字典：
|
||
```python
|
||
{
|
||
"default_key": "default_value", # 来自FSCHAT_MODEL_WORKERS["default"]
|
||
"online_api": True, # 因为model_name在ONLINE_LLM_MODEL中存在
|
||
"worker_class": <class 'server.model_workers.ExampleProvider'>, # 动态加载的provider类
|
||
"model_path": "/path/to/example_model", # 通过get_model_path获取的模型路径
|
||
"model_path_exists": True, # 如果路径存在且为目录
|
||
"device": "cuda", # 通过llm_device函数确定的设备类型
|
||
... # 其他可能的配置项
|
||
}
|
||
```
|
||
此输出示例展示了函数如何合并不同来源的配置，并根据模型名称动态调整配置内容。
|
||
## FunctionDef get_all_model_worker_configs
|
||
**get_all_model_worker_configs**: 此函数的功能是获取所有模型工作配置项的字典。
|
||
|
||
**参数**: 此函数不接受任何参数。
|
||
|
||
**代码描述**: `get_all_model_worker_configs` 函数主要用于收集并返回所有模型工作配置项的详细信息。函数首先创建一个空字典`result`用于存储结果。通过`FSCHAT_MODEL_WORKERS.keys()`获取所有模型名称的集合`model_names`，然后遍历这些模型名称。对于每个模型名称，如果名称不是"default"，则调用`get_model_worker_config`函数获取该模型的配置，并将其添加到`result`字典中。这里，`get_model_worker_config`函数的作用是加载指定模型的工作配置项，它会根据模型名称动态地合并默认配置和模型特定的配置项。最终，函数返回包含所有模型配置的字典`result`。
|
||
|
||
**注意**:
|
||
- 确保`FSCHAT_MODEL_WORKERS`已经被正确初始化，包含了所有可用模型的配置信息。`FSCHAT_MODEL_WORKERS`是一个关键的全局变量，存储了默认配置以及每个模型特定的配置项。
|
||
- 此函数依赖于`get_model_worker_config`函数来获取每个模型的配置。因此，确保`get_model_worker_config`函数能够正确执行，且相关配置文件和模块已经被正确设置。
|
||
|
||
**输出示例**:
|
||
假设`FSCHAT_MODEL_WORKERS`中包含了名为"model1"和"model2"的模型配置，而"default"配置被排除，调用`get_all_model_worker_configs()`可能返回如下字典：
|
||
```python
|
||
{
|
||
"model1": {
|
||
"default_key": "default_value",
|
||
"online_api": True,
|
||
"worker_class": <class 'server.model_workers.Model1Provider'>,
|
||
"model_path": "/path/to/model1",
|
||
"model_path_exists": True,
|
||
"device": "cuda",
|
||
...
|
||
},
|
||
"model2": {
|
||
"default_key": "default_value",
|
||
"online_api": False,
|
||
"worker_class": <class 'server.model_workers.Model2Provider'>,
|
||
"model_path": "/path/to/model2",
|
||
"model_path_exists": True,
|
||
"device": "cpu",
|
||
...
|
||
}
|
||
}
|
||
```
|
||
此输出示例展示了如何为每个模型动态地收集和合并配置项，从而为后续的模型部署和使用提供详细的配置信息。
|
||
## FunctionDef fschat_controller_address
|
||
**fschat_controller_address**: 此函数的功能是获取Fastchat控制器的地址。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `fschat_controller_address` 函数首先从配置文件中导入`FSCHAT_CONTROLLER`配置，该配置包含了Fastchat控制器的主机地址和端口号。函数检查主机地址是否为`"0.0.0.0"`，如果是，则将其替换为`"127.0.0.1"`，这是因为在本地环境中，`"0.0.0.0"`表示监听所有可用网络接口，而在实际访问时需要指定为`"127.0.0.1"`。随后，函数将处理后的主机地址和端口号格式化为一个完整的URL字符串，并返回该字符串。
|
||
|
||
在项目中，`fschat_controller_address` 被多个地方调用，包括但不限于`list_running_models`、`stop_llm_model`、`change_llm_model`、`set_httpx_config`、`get_httpx_client`、`get_server_configs`、`run_model_worker`和`run_openai_api`等函数。这些调用点主要用于获取Fastchat控制器的地址，以便进行网络请求或配置网络请求客户端。例如，在`list_running_models`函数中，使用`fschat_controller_address`获取控制器地址来请求已加载模型的列表；在`set_httpx_config`函数中，使用该地址配置HTTP客户端的代理设置，以确保对Fastchat控制器的请求不会被代理拦截。
|
||
|
||
**注意**: 使用此函数时，需要确保`configs.server_config`中的`FSCHAT_CONTROLLER`配置正确，包括有效的主机地址和端口号，以保证能够成功连接到Fastchat控制器。
|
||
|
||
**输出示例**: 假设Fastchat控制器配置的主机地址为`"0.0.0.0"`，端口号为`8080`，则函数返回的字符串为`"http://127.0.0.1:8080"`。如果主机地址已经是具体的IP地址或域名，如`"192.168.1.100"`，则返回的字符串为`"http://192.168.1.100:8080"`。
|
||
## FunctionDef fschat_model_worker_address(model_name)
|
||
**fschat_model_worker_address**: 此函数的功能是获取指定模型工作器的地址。
|
||
|
||
**参数**:
|
||
- model_name: 字符串类型，指定要获取地址的模型名称，默认为LLM_MODELS列表中的第一个元素。
|
||
|
||
**代码描述**: `fschat_model_worker_address` 函数首先调用`get_model_worker_config`函数，传入模型名称以获取模型的配置信息。如果成功获取到配置信息，函数将从配置字典中提取`host`和`port`字段。如果`host`字段的值为`"0.0.0.0"`，则将其替换为`"127.0.0.1"`，这是因为在本地环境中，`"0.0.0.0"`表示监听所有可用地址，而在实际使用中通常需要指定为本地回环地址`"127.0.0.1"`。最后，函数将`host`和`port`组合成完整的URL地址，格式为`"http://{host}:{port}"`，并返回该地址。如果无法获取模型的配置信息，函数将返回空字符串。
|
||
|
||
**注意**:
|
||
- 确保在调用此函数之前，已经通过`get_model_worker_config`函数正确加载了模型的配置信息，包括模型服务的主机地址和端口号。
|
||
- 此函数主要用于内部服务之间的通信，确保服务地址的正确配置对于服务的正常运行至关重要。
|
||
|
||
**输出示例**:
|
||
调用`fschat_model_worker_address("example_model")`，假设`example_model`的配置中`host`为`"0.0.0.0"`，`port`为`8080`，则可能返回：
|
||
```
|
||
"http://127.0.0.1:8080"
|
||
```
|
||
## FunctionDef fschat_openai_api_address
|
||
**fschat_openai_api_address**: 该函数的功能是获取FastChat OpenAI API的完整地址。
|
||
|
||
**参数**: 此函数不接受任何参数。
|
||
|
||
**代码描述**: `fschat_openai_api_address` 函数首先从项目的配置文件中导入 `FSCHAT_OPENAI_API` 配置字典。然后，它从这个配置中提取 `host` 和 `port` 信息，以构建并返回一个格式化的URL字符串，该字符串指向FastChat OpenAI API的服务地址。如果配置中的 `host` 值为 `"0.0.0.0"`，则会将其替换为 `"127.0.0.1"`，这是一个指向本地主机的通用IP地址。最终，函数返回的URL格式为 `"http://{host}:{port}/v1"`，其中 `{host}` 和 `{port}` 分别被替换为实际的主机地址和端口号。
|
||
|
||
在项目中，`fschat_openai_api_address` 函数被多个对象调用，包括 `get_ChatOpenAI`、`get_OpenAI`、`set_httpx_config` 和 `get_httpx_client` 等，这些调用点主要用于配置和初始化与OpenAI API相关的服务。例如，在 `get_ChatOpenAI` 和 `get_OpenAI` 函数中，`fschat_openai_api_address` 的返回值被用作创建 `ChatOpenAI` 和 `OpenAI` 实例时指定OpenAI API基础URL的参数。这表明 `fschat_openai_api_address` 函数在项目中扮演着连接和配置OpenAI API服务的关键角色。
|
||
|
||
**注意**: 使用此函数时，确保 `FSCHAT_OPENAI_API` 配置字典已正确设置在项目的配置文件中，包括有效的 `host` 和 `port` 值。此外，考虑到网络环境的不同，如果API服务部署在远程服务器上，可能需要相应地调整 `host` 值。
|
||
|
||
**输出示例**: 假设 `FSCHAT_OPENAI_API` 配置中的 `host` 为 `"127.0.0.1"`，`port` 为 `"5000"`，则函数的返回值将是 `"http://127.0.0.1:5000/v1"`。
|
||
## FunctionDef api_address
|
||
**api_address**: 此函数的功能是生成并返回API服务器的地址。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `api_address` 函数首先从项目的配置文件中导入 `API_SERVER` 配置字典。然后，它从这个字典中提取 `host` 和 `port` 值。如果 `host` 的值为 `"0.0.0.0"`，则将其替换为 `"127.0.0.1"`，这是因为在许多情况下，`"0.0.0.0"` 表示监听所有网络接口，而在实际访问时需要指定为 `"127.0.0.1"` 或实际的IP地址。最后，函数将 `host` 和 `port` 组合成一个字符串，格式为 `"http://{host}:{port}"`，并返回这个字符串。
|
||
|
||
在项目中，`api_address` 函数被多个对象调用，包括 `get_server_configs` 函数、`dump_server_info` 函数以及 `ApiRequest` 和 `AsyncApiRequest` 类的构造函数。这些调用表明 `api_address` 函数用于提供API服务器的地址信息，以便其他部分的代码可以使用这个地址来进行网络请求或者在日志和配置信息中显示API服务器的地址。
|
||
|
||
**注意**: 使用此函数时，需要确保 `configs.server_config` 文件中已经正确配置了 `API_SERVER` 字典，包括 `host` 和 `port` 两个键值对。此外，如果API服务器的地址或端口在项目运行期间有变化，需要更新配置文件以确保 `api_address` 函数返回的地址是最新的。
|
||
|
||
**输出示例**: 假设API服务器的 `host` 配置为 `"127.0.0.1"`，`port` 配置为 `"8080"`，那么 `api_address` 函数将返回字符串 `"http://127.0.0.1:8080"`。
|
||
## FunctionDef webui_address
|
||
**webui_address**: 此函数的功能是获取Web用户界面（UI）服务器的地址。
|
||
|
||
**参数**: 此函数不接受任何参数。
|
||
|
||
**代码描述**: `webui_address`函数负责从配置文件中读取Web UI服务器的主机名和端口号，并将它们格式化为一个完整的URL地址。首先，函数从`configs.server_config`模块导入`WEBUI_SERVER`字典，该字典包含了`host`和`port`两个关键字，分别代表服务器的主机名和端口号。然后，函数通过格式化字符串`f"http://{host}:{port}"`将这两个值组合成一个完整的URL地址，并返回该地址。
|
||
|
||
在项目中，`webui_address`函数被`startup.py`模块中的`dump_server_info`函数调用。在`dump_server_info`函数中，`webui_address`的返回值被用来打印Web UI服务器的地址信息，这对于在服务器启动后验证配置和进行故障排查是非常有用的。特别是当`args.webui`参数为真时，表明用户希望获取Web UI服务器的地址信息，此时会打印出通过`webui_address`函数获取到的地址。
|
||
|
||
**注意**: 使用此函数时，需要确保`configs.server_config`模块中的`WEBUI_SERVER`字典已正确配置，包括有效的`host`和`port`值，否则函数将返回无效的地址。
|
||
|
||
**输出示例**: 假设`WEBUI_SERVER`字典中的`host`为`localhost`，`port`为`8080`，则函数的返回值将是`"http://localhost:8080"`。这个返回值可以直接用于Web浏览器中，以访问Web UI服务器。
|
||
## FunctionDef get_prompt_template(type, name)
|
||
**get_prompt_template**: 该函数用于从配置中加载指定类型和名称的模板内容。
|
||
|
||
**参数**：
|
||
- type: 字符串，指定模板的类型，可选值包括"llm_chat"、"agent_chat"、"knowledge_base_chat"、"search_engine_chat"，代表不同的聊天模式或功能。
|
||
- name: 字符串，指定模板的名称，用于从指定类型中进一步确定模板。
|
||
|
||
**代码描述**：
|
||
`get_prompt_template`函数首先从`configs`模块导入`prompt_config`配置，然后使用`importlib.reload`方法重新加载`prompt_config`，以确保获取到最新的配置信息。函数通过`type`参数从`prompt_config.PROMPT_TEMPLATES`中索引到对应类型的模板字典，然后使用`name`参数从该字典中获取具体的模板内容。如果指定的`name`在字典中不存在，则返回`None`。
|
||
|
||
在项目中，`get_prompt_template`函数被多个地方调用，以支持不同场景下的模板加载需求。例如，在`server/api.py/mount_app_routes/get_server_prompt_template`中，该函数用于根据API请求中提供的类型和名称参数，动态加载并返回相应的模板内容。在`server/chat/agent_chat.py/agent_chat/agent_chat_iterator`和其他类似的聊天处理函数中，它用于加载特定聊天模式下的提示模板，以构造与用户交互的对话内容。
|
||
|
||
**注意**：
|
||
- 在使用`get_prompt_template`函数时，需要确保`type`和`name`参数的值正确无误，且对应的模板已经在`prompt_config`中定义。
|
||
- 由于该函数依赖于外部的配置文件`prompt_config`，因此在修改配置文件后，可能需要重启服务或动态重新加载配置，以确保更改生效。
|
||
|
||
**输出示例**：
|
||
假设`prompt_config.PROMPT_TEMPLATES`中包含以下内容：
|
||
```python
|
||
PROMPT_TEMPLATES = {
|
||
"llm_chat": {
|
||
"default": "你好，请问有什么可以帮助你的？"
|
||
}
|
||
}
|
||
```
|
||
调用`get_prompt_template(type="llm_chat", name="default")`将返回字符串`"你好，请问有什么可以帮助你的？"`。
|
||
## FunctionDef set_httpx_config(timeout, proxy)
|
||
**set_httpx_config**: 此函数用于设置httpx库的默认超时时间和代理配置。
|
||
|
||
**参数**:
|
||
- timeout: 浮点数类型，指定httpx请求的默认超时时间。如果未提供，则使用HTTPX_DEFAULT_TIMEOUT作为默认值。
|
||
- proxy: 可以是字符串或字典类型，用于指定httpx请求的代理设置。如果未提供，则不使用代理。
|
||
|
||
**代码描述**:
|
||
此函数主要执行以下操作：
|
||
1. 修改httpx库的默认超时配置，包括连接超时、读取超时和写入超时，将它们统一设置为函数参数`timeout`指定的值。
|
||
2. 根据`proxy`参数的类型（字符串或字典），在进程范围内设置系统级代理。如果`proxy`是字符串，则为http、https和all协议设置相同的代理地址。如果`proxy`是字典，则根据字典中的键（http、https、all）设置相应协议的代理地址。
|
||
3. 更新系统环境变量中的`NO_PROXY`设置，以确保某些特定的主机地址（如localhost和127.0.0.1）以及通过`fschat_controller_address`、`fschat_model_worker_address`和`fschat_openai_api_address`函数获取的地址不使用代理。
|
||
4. 重写`urllib.request.getproxies`函数，使其返回当前配置的代理设置，这一步骤确保了在使用urllib库进行网络请求时，也能应用上述代理配置。
|
||
|
||
**注意**:
|
||
- 在使用此函数之前，确保已经正确设置了`HTTPX_DEFAULT_TIMEOUT`变量，以便在不指定超时时间时使用。
|
||
- 代理设置对于在需要通过代理访问外部网络资源的环境中尤为重要，但请注意，对于本地或内网资源的访问，应通过`NO_PROXY`环境变量确保直连，以避免不必要的代理延迟。
|
||
- 此函数在项目启动时被多个模块调用，包括控制器、模型工作器、OpenAI API服务和API服务器等，以统一配置网络请求的行为。
|
||
|
||
**输出示例**:
|
||
此函数没有返回值，其主要作用是对环境和httpx库进行配置，因此不具有直接的输出示例。
|
||
### FunctionDef _get_proxies
|
||
**_get_proxies**: 此函数的功能是获取代理设置。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `_get_proxies` 函数是一个简单的功能函数，旨在从其所在的作用域中获取代理设置。在当前的代码片段中，`_get_proxies` 函数直接返回名为 `proxies` 的变量。这意味着，此函数的实际作用和返回值完全依赖于 `proxies` 变量当前的值或状态。由于代码片段中没有提供 `proxies` 变量的定义或初始化过程，我们无法直接确定 `proxies` 的具体内容或格式。通常，代理设置是用于配置网络请求通过特定的代理服务器进行，以实现网络匿名、绕过地理限制或提高请求效率等目的。
|
||
|
||
**注意**: 使用此函数时，需要确保在函数被调用的作用域中已经正确定义并初始化了 `proxies` 变量。`proxies` 变量应该是一个字典类型，其中包含了代理配置的详细信息，例如代理服务器的地址和端口。如果 `proxies` 变量未被正确定义或初始化，调用此函数可能会导致错误或异常。
|
||
|
||
**输出示例**: 假设 `proxies` 被定义为 `{"http": "http://10.10.1.10:3128", "https": "https://10.10.1.11:1080"}`，那么调用 `_get_proxies` 函数将返回如下字典：
|
||
```python
|
||
{
|
||
"http": "http://10.10.1.10:3128",
|
||
"https": "https://10.10.1.11:1080"
|
||
}
|
||
```
|
||
这个返回值展示了一个典型的代理配置，其中包含了对HTTP和HTTPS请求分别使用不同代理服务器的设置。
|
||
***
|
||
## FunctionDef detect_device
|
||
**detect_device**: 此函数的功能是检测并返回当前环境可用的设备类型。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `detect_device` 函数首先尝试导入 `torch` 库，然后使用 `torch.cuda.is_available()` 方法检查CUDA设备（通常是NVIDIA GPU）是否可用。如果可用，函数返回字符串 `"cuda"`。如果CUDA设备不可用，函数接着检查是否可以使用Apple的Metal Performance Shaders (MPS) 加速，这是通过 `torch.backends.mps.is_available()` 方法实现的。如果MPS可用，函数返回字符串 `"mps"`。如果以上两种加速方式都不可用，函数将返回 `"cpu"`，表示只能使用中央处理器进行计算。此函数通过捕获所有异常来确保在任何情况下都能至少返回 `"cpu"`，保证了其健壮性。
|
||
|
||
在项目中，`detect_device` 函数被 `llm_device` 和 `embedding_device` 函数调用。这两个函数用于确定用于语言模型（LLM）和嵌入计算的设备。它们通过传入的设备参数来尝试指定计算设备，如果传入的设备参数不是 `"cuda"`、`"mps"` 或 `"cpu"` 中的任何一个，或者没有提供设备参数，它们将调用 `detect_device` 函数自动检测并选择一个可用的设备。这样的设计使得在不同的硬件环境下，用户无需手动配置，就能自动选择最优的计算设备，提高了代码的通用性和易用性。
|
||
|
||
**注意**: 在使用此函数时，需要确保 `torch` 库已正确安装，并且根据你的硬件配置（是否有NVIDIA GPU或支持MPS的Apple硬件），`torch` 库的版本应支持CUDA或MPS。
|
||
|
||
**输出示例**:
|
||
- 如果检测到NVIDIA GPU，函数将返回 `"cuda"`。
|
||
- 如果检测到支持MPS的设备，函数将返回 `"mps"`。
|
||
- 如果以上两者都不可用，函数将返回 `"cpu"`。
|
||
## FunctionDef llm_device(device)
|
||
**llm_device**: 此函数的功能是确定并返回用于语言模型计算的设备类型。
|
||
|
||
**参数**:
|
||
- `device`: 一个字符串参数，用于指定计算设备。它的默认值为 `None`。
|
||
|
||
**代码描述**: `llm_device` 函数首先检查传入的 `device` 参数是否已经指定。如果没有指定（即为 `None`），则使用全局变量 `LLM_DEVICE` 作为设备类型。接下来，函数检查 `device` 是否为 `"cuda"`、`"mps"` 或 `"cpu"` 中的一个。如果不是，函数将调用 `detect_device` 函数自动检测当前环境中可用的设备类型。`detect_device` 函数能够检测CUDA设备（如NVIDIA GPU）、Apple的Metal Performance Shaders (MPS) 加速或者回退到CPU，确保在任何环境下都能找到一个可用的计算设备。最终，`llm_device` 函数返回确定的设备类型。
|
||
|
||
**注意**:
|
||
- 在调用此函数之前，确保已经根据您的硬件配置安装了支持CUDA或MPS的 `torch` 库版本，以便正确检测设备类型。
|
||
- 此函数依赖于全局变量 `LLM_DEVICE`，确保在使用前已正确设置该变量。
|
||
- 当自动检测设备时，如果既没有检测到CUDA设备也没有检测到MPS设备，函数将默认使用CPU。
|
||
|
||
**输出示例**:
|
||
- 如果指定了 `device` 为 `"cuda"` 并且环境支持，函数将返回 `"cuda"`。
|
||
- 如果未指定 `device`，并且自动检测结果为MPS设备可用，函数将返回 `"mps"`。
|
||
- 如果既未指定 `device` 也无法使用CUDA或MPS，函数将返回 `"cpu"`。
|
||
|
||
此函数在项目中的应用场景包括确定模型工作配置中的计算设备类型，以及在服务器启动信息中显示当前使用的计算设备。这确保了在不同硬件环境下，系统能够自动选择最优的计算设备，从而提高了代码的通用性和易用性。
|
||
## FunctionDef embedding_device(device)
|
||
**embedding_device**: 此函数的功能是确定并返回用于嵌入计算的设备类型。
|
||
|
||
**参数**:
|
||
- device: 一个字符串参数，用于指定计算设备。默认值为None。
|
||
|
||
**代码描述**: `embedding_device` 函数首先检查传入的 `device` 参数是否已经指定。如果没有指定（即为None），则会使用全局变量 `EMBEDDING_DEVICE` 的值。接下来，函数检查 `device` 是否为 `"cuda"`、`"mps"` 或 `"cpu"` 中的一个。如果不是，或者 `EMBEDDING_DEVICE` 也没有提供有效的设备类型，函数将调用 `detect_device` 函数自动检测当前环境中可用的设备类型。`detect_device` 函数能够检测CUDA设备（通常是NVIDIA GPU）、Apple的Metal Performance Shaders (MPS) 加速或者回退到使用CPU。最终，`embedding_device` 函数返回确定的设备类型。
|
||
|
||
**注意**: 使用此函数时，需要确保相关的硬件和软件（如NVIDIA GPU或支持MPS的Apple硬件，以及对应的支持库）已经准备就绪。此外，`EMBEDDING_DEVICE` 全局变量需要在函数外部被正确设置，以便在没有明确指定设备类型时提供默认值。
|
||
|
||
**输出示例**:
|
||
- 如果环境中有可用的NVIDIA GPU，并且传入的 `device` 参数为 `"cuda"` 或未指定且 `EMBEDDING_DEVICE` 为 `"cuda"`，函数将返回 `"cuda"`。
|
||
- 如果环境支持MPS加速，并且传入的 `device` 参数为 `"mps"` 或未指定且 `EMBEDDING_DEVICE` 为 `"mps"`，函数将返回 `"mps"`。
|
||
- 如果以上两种情况都不满足，函数将返回 `"cpu"`，表示使用中央处理器进行计算。
|
||
## FunctionDef run_in_thread_pool(func, params)
|
||
**run_in_thread_pool**: 该函数的功能是在线程池中批量运行任务，并将运行结果以生成器的形式返回。
|
||
|
||
**参数**:
|
||
- `func`: 需要在线程池中执行的函数，该函数应接受关键字参数。
|
||
- `params`: 一个列表，包含字典，每个字典代表传递给`func`的关键字参数。默认为空列表。
|
||
|
||
**代码描述**:
|
||
`run_in_thread_pool`函数主要用于在并发环境下执行多个任务，以提高程序的执行效率。它接受一个可调用对象`func`和一个参数列表`params`。`params`中的每个元素都是一个字典，代表了需要传递给`func`的关键字参数。函数内部首先创建一个线程池`ThreadPoolExecutor`，然后遍历`params`列表，为每个参数字典创建一个线程任务，使用`pool.submit(func, **kwargs)`提交到线程池执行。这里的`**kwargs`是Python中的关键字参数展开语法，用于将字典展开为关键字参数。所有任务提交后，函数使用`as_completed`方法等待所有任务完成，并通过生成器`yield`语句返回每个任务的结果。
|
||
|
||
在项目中，`run_in_thread_pool`被用于不同的场景，如文件解析、文件保存等操作，这些操作都需要处理多个文件或数据，且各自操作可以独立并行执行，从而大大提高了处理效率。例如，在`_parse_files_in_thread`函数中，它用于并发地将上传的文件保存到指定目录，并处理文件内容；在`_save_files_in_thread`函数中，它用于并发地将文件保存到知识库目录；在`files2docs_in_thread`函数中，它用于并发地将磁盘文件转化为文档对象。这些调用场景表明`run_in_thread_pool`在处理IO密集型或CPU密集型任务时，能够有效地利用多线程提高程序的执行效率。
|
||
|
||
**注意**:
|
||
- 使用`run_in_thread_pool`时，需要确保传递给`func`的操作是线程安全的，以避免数据竞争或其他并发问题。
|
||
- 任务函数`func`应设计为接受关键字参数，以便与`params`中的字典正确匹配。
|
||
- 由于`run_in_thread_pool`返回一个生成器，调用此函数时需要通过迭代来获取所有任务的结果。
|
||
## FunctionDef get_httpx_client(use_async, proxies, timeout)
|
||
**get_httpx_client**: 该函数的功能是获取配置好的httpx客户端实例，用于执行HTTP请求。
|
||
|
||
**参数**:
|
||
- `use_async`: 布尔类型，默认为`False`。指定返回的httpx客户端是否支持异步操作。
|
||
- `proxies`: 字符串或字典类型，默认为`None`。用于设置代理。
|
||
- `timeout`: 浮点数，默认为`HTTPX_DEFAULT_TIMEOUT`。设置请求超时时间。
|
||
- `**kwargs`: 接收额外的关键字参数，这些参数将直接传递给httpx客户端实例。
|
||
|
||
**代码描述**:
|
||
此函数首先定义了一个默认的代理配置，该配置会绕过本地地址的代理设置。然后，它会获取一系列特定地址（例如Fastchat控制器地址、模型工作器地址和OpenAI API地址），并将这些地址添加到代理配置中，确保这些地址的请求不会通过代理。接下来，函数会从系统环境变量中读取代理设置，并合并到默认代理配置中。如果用户提供了`proxies`参数，该函数会将用户指定的代理设置合并到默认代理配置中。
|
||
|
||
此外，函数还支持通过`use_async`参数选择返回同步或异步的httpx客户端实例。在构造httpx客户端实例时，会将超时时间、代理配置以及任何额外的关键字参数传递给客户端构造函数。
|
||
|
||
如果启用了详细日志记录（`log_verbose`为`True`），函数会记录客户端实例的配置参数。
|
||
|
||
**注意**:
|
||
- 在使用此函数时，需要注意`proxies`参数的格式，它可以是一个字符串或字典。如果是字符串，将会被解释为所有请求的代理地址；如果是字典，可以为不同的协议指定不同的代理。
|
||
- 确保环境变量中的代理设置是正确的，否则可能会影响到httpx客户端实例的请求。
|
||
- 当需要执行异步HTTP请求时，应将`use_async`参数设置为`True`，以获取支持异步操作的httpx客户端实例。
|
||
|
||
**输出示例**:
|
||
由于此函数返回的是一个httpx客户端实例，因此输出示例取决于如何使用该实例进行HTTP请求。例如，如果使用同步客户端发起GET请求，可能会这样使用：
|
||
```python
|
||
with get_httpx_client() as client:
|
||
response = client.get('https://www.example.com')
|
||
print(response.text)
|
||
```
|
||
如果使用异步客户端发起GET请求，则可能会这样使用：
|
||
```python
|
||
async with get_httpx_client(use_async=True) as client:
|
||
response = await client.get('https://www.example.com')
|
||
print(response.text)
|
||
```
|
||
## FunctionDef get_server_configs
|
||
**get_server_configs**: 此函数的功能是获取服务器的配置信息，并以字典形式返回。
|
||
|
||
**参数**: 此函数不接受任何参数。
|
||
|
||
**代码描述**: `get_server_configs` 函数首先从多个配置文件中导入了服务器的配置项，包括知识库、搜索引擎、向量搜索类型、分块大小、重叠大小、分数阈值、向量搜索的Top K值、搜索引擎的Top K值、中文标题增强标志、文本分割器字典、文本分割器名称、大型语言模型、历史长度、温度参数以及提示模板。此外，函数还调用了`fschat_controller_address`、`fschat_openai_api_address`和`api_address`三个函数，分别获取Fastchat控制器地址、FastChat OpenAI API地址和API服务器地址，并将这些地址信息存储在一个名为`_custom`的字典中。最后，函数通过合并`locals()`中的局部变量和`_custom`字典，构造并返回一个包含所有配置信息的字典。需要注意的是，函数在返回字典时排除了以`_`开头的局部变量。
|
||
|
||
**注意**: 使用此函数时，需要确保相关配置文件中的配置项已正确设置。此外，由于函数返回的配置信息可能包含敏感数据，如API地址等，因此在将这些信息提供给前端或其他服务时应谨慎处理。
|
||
|
||
**输出示例**:
|
||
```python
|
||
{
|
||
"DEFAULT_KNOWLEDGE_BASE": "example_kb",
|
||
"DEFAULT_SEARCH_ENGINE": "google",
|
||
"DEFAULT_VS_TYPE": "example_vs_type",
|
||
"CHUNK_SIZE": 512,
|
||
"OVERLAP_SIZE": 50,
|
||
"SCORE_THRESHOLD": 0.5,
|
||
"VECTOR_SEARCH_TOP_K": 10,
|
||
"SEARCH_ENGINE_TOP_K": 5,
|
||
"ZH_TITLE_ENHANCE": True,
|
||
"TEXT_SPLITTER_NAME": "example_splitter",
|
||
"LLM_MODELS": ["model1", "model2"],
|
||
"HISTORY_LEN": 10,
|
||
"TEMPERATURE": 0.7,
|
||
"PROMPT_TEMPLATES": {"template1": "Example template."},
|
||
"controller_address": "http://127.0.0.1:8080",
|
||
"openai_api_address": "http://127.0.0.1:5000/v1",
|
||
"api_address": "http://127.0.0.1:8080"
|
||
}
|
||
```
|
||
此示例展示了函数可能返回的配置信息字典，包括各种默认配置项、模型参数、提示模板以及三个关键的API地址。实际返回的内容将根据项目配置文件中的设置而有所不同。
|
||
## FunctionDef list_online_embed_models
|
||
**list_online_embed_models**: 此函数的功能是列出所有支持嵌入功能的在线模型名称。
|
||
|
||
**参数**: 此函数没有参数。
|
||
|
||
**代码描述**: `list_online_embed_models` 函数首先从 `list_config_llm_models` 函数获取所有配置的在线大型语言模型（LLM）的信息。然后，它遍历这些模型的配置信息，检查每个模型是否有指定的提供者（provider）并且该提供者对应的类是否存在于 `model_workers` 中。如果存在，进一步检查该类是否支持嵌入功能（通过调用 `can_embedding` 方法）。只有当这些条件都满足时，该模型的名称才会被添加到返回列表中。这意味着返回的列表中包含的模型都是可以进行嵌入操作的在线模型。
|
||
|
||
**注意**: 在使用此函数时，需要确保 `model_workers` 中已经定义了相应的模型提供者类，并且这些类实现了 `can_embedding` 方法。此外，由于此函数依赖于 `list_config_llm_models` 函数提供的配置信息，因此需要确保相关的配置信息是准确和最新的。
|
||
|
||
**输出示例**:
|
||
```python
|
||
["llm_model_online_1", "llm_model_online_2"]
|
||
```
|
||
此输出示例展示了函数可能返回的在线模型名称列表，实际返回的内容将根据配置的在线模型和它们是否支持嵌入功能而有所不同。
|
||
|
||
在项目中，`list_online_embed_models` 函数被多个地方调用，包括但不限于 `embed_texts` 和 `aembed_texts` 函数，这些函数用于处理文本的向量化操作。此外，它还被 `load_kb_embeddings` 方法调用，该方法用于加载知识库的嵌入向量。这表明 `list_online_embed_models` 函数在项目中扮演着重要角色，它帮助其他组件确定哪些在线模型可以用于嵌入操作。
|
||
## FunctionDef load_local_embeddings(model, device)
|
||
**load_local_embeddings**: 此函数的功能是从缓存中加载并返回指定模型的嵌入向量对象。
|
||
|
||
**参数**:
|
||
- `model`: 字符串类型，指定要加载的嵌入模型名称。如果未提供，将使用配置文件中指定的默认嵌入模型。
|
||
- `device`: 字符串类型，指定计算设备。如果未提供，将通过`embedding_device`函数自动检测并选择合适的设备。
|
||
|
||
**代码描述**:
|
||
`load_local_embeddings`函数首先检查是否提供了`model`参数，如果没有提供，则使用配置文件中的默认嵌入模型名称。接着，函数调用`embeddings_pool`的`load_embeddings`方法，传入模型名称和设备类型，从而加载并返回嵌入向量对象。这个过程包括从缓存中检索嵌入向量对象，如果缓存中不存在，则会创建并加载新的嵌入向量对象。这个加载过程是线程安全的，可以避免在多线程环境下的竞争条件。
|
||
|
||
**注意**:
|
||
- 使用此函数时，需要确保`model`参数对应的嵌入模型已经正确配置，并且支持的设备类型（如CUDA、MPS或CPU）与运行环境相匹配。
|
||
- 此函数依赖于`embedding_device`函数来自动检测或指定计算设备，因此需要确保相关的硬件和软件环境已经准备就绪。
|
||
- 在多线程环境下使用此函数时，可以放心地进行调用，因为内部实现了线程安全的机制。
|
||
|
||
**输出示例**:
|
||
调用`load_local_embeddings(model="text-embedding-ada-002", device="cuda")`可能会返回一个已经加载了指定OpenAI嵌入模型的嵌入向量对象，该对象准备好在CUDA设备上进行嵌入向量的计算。
|
||
|
||
在项目中，`load_local_embeddings`函数被多个地方调用，包括但不限于`embed_texts`和`aembed_texts`函数，用于对文本进行向量化处理；以及在`ESKBService`类的初始化过程中，用于加载嵌入模型以支持Elasticsearch的向量搜索功能。此外，它还被`worker`函数用于在Faiss缓存中进行文本的添加、搜索和删除操作。这些调用场景表明，`load_local_embeddings`函数是处理本地嵌入向量加载的核心功能，支持了文本向量化、文本检索等多种应用场景。
|
||
## FunctionDef get_temp_dir(id)
|
||
**get_temp_dir**: 该函数用于创建一个临时目录，并返回该目录的路径和文件夹名称。
|
||
|
||
**参数**:
|
||
- **id**: 可选参数，字符串类型。如果提供，函数将尝试在基础临时目录下创建或找到一个与之对应的子目录。
|
||
|
||
**代码描述**:
|
||
`get_temp_dir` 函数首先从配置文件中导入基础临时目录的路径（`BASE_TEMP_DIR`）。如果调用时提供了`id`参数，并且该`id`对应的目录已经存在于基础临时目录下，则函数将直接返回该目录的路径和名称，不会创建新的临时目录。如果没有提供`id`参数，或者提供的`id`对应的目录不存在，则函数将使用`tempfile.mkdtemp`方法在基础临时目录下创建一个新的临时目录，并返回新目录的路径和名称。
|
||
|
||
在项目中，`get_temp_dir`函数被`upload_temp_docs`函数调用，用于在上传文件并进行处理前，创建或找到一个临时目录来存放这些文件。这个过程中，如果提供了之前的临时目录ID（`prev_id`），则会尝试复用该目录，否则会创建一个新的临时目录。这样做可以有效地管理临时文件，避免重复创建不必要的临时目录，同时也方便后续的文件处理和向量化操作。
|
||
|
||
**注意**:
|
||
- 如果在多线程或多进程环境下使用该函数，请确保对临时目录的操作（如读写文件）有适当的同步机制，以避免数据竞争或文件损坏。
|
||
- 临时目录的清理工作需要调用者自行管理，该函数不会自动删除创建的临时目录。
|
||
|
||
**输出示例**:
|
||
调用`get_temp_dir()`可能会返回如下形式的元组：
|
||
- (`"/tmp/base_temp_dir/abc123"`, `"abc123"`)，其中`"/tmp/base_temp_dir/abc123"`是临时目录的完整路径，`"abc123"`是该目录的名称。
|