用于客户支持的 GenAI：探索 Elastic Support Assistant
作者：Chris Blaisure, Cory Mangini
我们很高兴地宣布推出 Elastic 的支持助手。本博客将带你了解我们最新的生成式 AI 工具以及它可以帮助你使用 Elastic 技术的一些常见场景。
Elastic 支持助手现已在 Support Hub 上可用
今天，我们宣布 Elastic 支持助手已全面开放给所有拥有支持帐户的客户和试用用户，可通过 Support Hub 访问。支持助手是一种生成式 AI 聊天体验，旨在回答有关所有 Elastic 产品的各种产品问题。我们通过一系列技术博客记录了构建过程，重点介绍了构建过程中的有趣步骤。：
- 第 1 部分：构建我们的概念验证
- 第 2 部分：构建知识库
- 第 3 部分：为人类设计聊天机器人的聊天界面
- 第 4 部分：调整 RAG 搜索的相关性
概述：Elastic 的 AI 助手
正如生成式 AI 的发展速度超出任何人的预期一样，Elastic 也发展迅速，开发了旨在为我们的客户解决不同用例的助手。以下是目前可供客户使用的助手的简要概述：
- 可观察性 AI 助手
- 为可观察性数据分析和问题补救提供见解和聊天支持
- 与外部 AI 模型集成以提供上下文帮助
- 需要企业订阅和 Elastic Stack 8.9 或更高版本
- 安全 AI 助手
- 协助网络安全任务，如警报调查和事件响应
- 使用生成式 AI 以自然语言进行交互和生成查询
- 需要企业订阅，从 Elastic Stack 8.8.1 开始可用
- 支持助手（此产品发布）
- 聊天体验为所有 Elastic 产品提供一般支持，由我们所有可用的上下文（产品文档、博客、知识库等）提供信息
- 使用生成式 AI 和检索增强架构来总结内容以回答特定问题
- 不依赖于部署版本或订阅级别
如何访问支持助手
Elastic 支持助手
现在，所有试用或有效订阅的 Elastic 客户均可在支持中心使用 Elastic 支持助手。登录后，可以在右下角找到支持助手。从那里，你可以开始第一次对话。
支持助手旨在帮助深入了解 Elastic 技术，并可以访问 Elastic 的全部博客、114 个主要/次要版本的 Elastic 产品文档、技术支持文章和入门指南。虽然它无法访问任何部署健康信息或你的数据，但支持助手对 Elastic 的广泛用例有着深入的了解。我们自己的 200 多名 Elastic 员工每天都在使用它，我们很高兴将它的使用范围扩展到 Elastic 客户。
利用支持助手进行部署的方法
支持助手旨在增强客户的 Elastic 技术产品知识，其准确性也在不断提高。但是，与所有 AI 工具一样，用户应谨慎行事，因为响应可能会有所不同。建议使用源文档验证所提供的信息以确保准确性。
1. 配置故障排除
如果你在部署或配置期间遇到问题，支持助手可以针对你明确提到的特定 Elastic 版本提供定制的指导。例如，如果你正在设置新的 8.14 集群并遇到错误，助手可以通过将你的问题与 Elastic 产品文档和知识库中的相关文档和已知问题进行交叉引用来帮助诊断问题。
当你不确定在哪里可以找到特定错误时，这会特别有用。助手可以通过找出适合你的上下文来节省时间，而不是在 Kibana 文档中搜索实际上针对 Elasticsearch 的错误。
2. 性能调优
你可以向支持助手查询有关优化 Elasticsearch 集群性能的最佳实践。无论你是处理慢速查询还是需要资源分配方面的建议，助手都可以根据你的部署细节建议配置更改、分片管理策略和其他性能增强技术。
3. 升级
计划升级到较新版本的 Elastic？支持助手可以找到所需的步骤来指导你完成升级过程，突出显示潜在的重大更改并提供建议以获得更流畅的体验。
4. 安全性和合规性
助手可以提供有关保护 Elastic 部署的指导，从设置基于角色的访问控制 (RBAC) 到配置加密和审计日志记录。对于受监管行业的客户，它还可以提供有关 Elastic 的安全功能如何符合 GDPR 或 HIPAA 等合规性要求的信息。
5. 监控和警报
支持助手可以帮助提供为你的部署设置监控的步骤。无论你需要配置 Kibana 仪表板还是设置特定事件的警报，助手都可以引导你完成必要的步骤，确保你的部署保持健康并及时标记问题。
一旦你开始运行监控和警报，Observability AI 助手可以帮助你回答有关收集的数据的任何问题。
6. 自定义用例和集成
如果你希望通过将 Elastic 与其他工具集成或构建自定义应用程序来扩展其功能，支持助手可以提供与你的特定需求相关的代码片段、集成指南和示例。它可以帮助你解决 Logstash 管道、Kibana 可视化或 Beats 配置的问题。
Elastic 员工会向支持助理询问什么？
我们的内部团队在日常工作流程中依赖支持助理。以下是他们认为有用的几个示例，它们可能会为你提供如何使用它的想法。
综合多个文档的答案
问题：Explain the difference between query_string and query terms in Elasticsearch.
支持助理的回答：
In Elasticsearch, `query_string` and `terms` queries serve different purposes and have distinct behaviors:
1. `query_string` Query:
The `query_string` query is a powerful query that allows you to execute complex searches using a query string syntax. It can parse and split the provided query string based on operators such as AND, OR, NOT, and more. The `query_string` query supports field-specific queries, wildcards, regular expressions, fuzziness, proximity searches, and range queries. It is very flexible but also strict; if the query string contains any invalid syntax, it will return an error. Due to its complexity and strictness, it is not recommended for direct use in search boxes where users can enter free-form text.
Here is an example of a `query_string` query:
```json
GET /_search
{
"query": {
"query_string": {
"query": "(new york city) OR (big apple)",
"default_field": "content"
}
}
}
```
2. `terms` Query:
The `terms` query is used for filtering documents based on an exact match with one or more values specified in an array. It is much simpler than the `query_string` query and is used for structured searches where you know the exact values to look for. The `terms` query does not analyze the search terms, so it will look for exact matches in the inverted index. It is commonly used for filtering on keyword fields, IDs, tags, and other structured data.
Here is an example of a `terms` query:
```json
GET /_search
{
"query": {
"terms": {
"user.id": ["kimchy", "elkbee"]
}
}
}
```
In summary, the `query_string` query is used for complex, full-text searches with a rich query syntax, while the `terms` query is used for simple, exact-match filtering on specific values. The choice between the two depends on the use case and the nature of the search you want to perform.
References:
- [Query string query](https://www.elastic.co/guide/en/elasticsearch/reference/8.14/query-dsl-query-string-query.html)
- [Terms query](https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-terms-query.html) (not directly provided in the context, but relevant for the explanation)一步步帮助
问题：How can I list tasks running when high CPU is seen in the Kibana stack monitoring metrics view?
支持助理的回答：
To list tasks running when high CPU usage is detected in the Kibana Stack Monitoring metrics view, you would typically follow these steps:
1. **Access Kibana**: Open Kibana in your web browser and log in if necessary.
2. **Navigate to Stack Monitoring**: Click on the "Stack Monitoring" link in the main menu to access the monitoring features of your Elastic Stack.
3. **Identify the Node with High CPU Usage**: In the Stack Monitoring section, you should be able to see an overview of your Elasticsearch cluster, including CPU usage metrics. Identify the node or nodes that are experiencing high CPU usage.
4. **View Node Details**: Click on the node with high CPU usage to get more detailed metrics. This will take you to a page with more in-depth information about that particular node.
5. **Access the Elasticsearch API**: To list the tasks running on the node, you will need to use the Elasticsearch `_tasks` API. You can do this directly through the Dev Tools console in Kibana or by using a tool like `curl`.
6. **Use the `_tasks` API**: In the Dev Tools console, you can run the following command to list the tasks on the node with high CPU usage:
```
GET /_tasks?nodes=<node_id>&detailed=true&actions=*search*
```
Replace `<node_id>` with the actual ID of the node you're investigating. This command will list all the detailed tasks related to search actions, which are often a common cause of high CPU usage. You can adjust the `actions` parameter to filter for different types of tasks if necessary.
7. **Analyze the Task List**: The output will show you a list of tasks currently running on the node, including their IDs, types, start times, running times, and other relevant information. This can help you identify which tasks are consuming the most CPU resources.
8. **Take Action**: Depending on what you find, you may need to optimize your queries, scale your cluster, or take other actions to address the high CPU usage.
Please note that the `_tasks` API can provide a lot of information, and you might need to filter the results to find the relevant tasks. Additionally, if you have ongoing performance issues, you might want to set up more detailed monitoring or alerting to catch these issues proactively.
The context provided does not include specific instructions for listing tasks using the Kibana UI, but the general approach outlined above is how you would typically investigate high CPU usage in an Elasticsearch cluster using Kibana and Elasticsearch APIs.
For more detailed information on the `_tasks` API, you can refer to the Elasticsearch documentation:
https://www.elastic.co/guide/en/elasticsearch/reference/current/tasks.html构建你自己的 Elastic 支持助手
在 Elastic 内部，现场技术团队为 Elastic 员工构建工具。我们大量使用自己的技术，并且经常是我们的搜索和可观察性解决方案的零客户。下图显示了此版本发布时的架构。
由于有如此多的架构和软件选项，找到正确的方法可能很困难。如果你有兴趣构建聊天机器人，我们的相关博客 chatbot-tutorial 提供了分步指南来帮助你入门。正如本博客系列中所述，我们发现由 Elasticsearch 提供支持的 RAG 架构为我们的用户提供了最佳结果，并为未来的生成式 AI 解决方案提供了平台。
为了充分利用搜索功能并推动整个企业的 GenAI 创新，我们强烈建议与 Elastic Consulting 合作。无论你是开发高度个性化的电子商务体验还是实施交互式聊天机器人，我们的顾问都拥有技术专业知识，可以根据你独特的业务需求设计和部署 GenAI 解决方案。
体验 Elastic 支持的支持助手
支持助手是 Elastic 支持中心的最新增强功能，体现了我们通过自助知识发现和代理驱动的支持案例为客户提供支持的持续承诺。准确性一直是我们的首要任务，从近一年前我们过渡到语义搜索开始，支持助手的添加也不例外。我们将继续监控并随着时间的推移提高响应准确性。
试用支持助手并让我们知道你的想法 —— 你的反馈将决定其未来的改进。
本文中描述的任何特性或功能的发布和时间均由 Elastic 自行决定。任何当前不可用的特性或功能可能无法按时交付或根本无法交付。
在这篇博文中，我们可能使用或提到了第三方生成 AI 工具，这些工具由其各自的所有者拥有和运营。Elastic 无法控制第三方工具，我们对其内容、操作或使用不承担任何责任，也不对你使用此类工具可能产生的任何损失或损害承担任何责任。将 AI 工具用于个人、敏感或机密信息时请谨慎行事。你提交的任何数据都可能用于 AI 训练或其他目的。我们无法保证你提供的信息将得到安全或保密。在使用任何生成式 AI 工具之前，你应熟悉其隐私惯例和使用条款。
Elastic、Elasticsearch、ESRE、Elasticsearch Relevance Engine 和相关标志是 Elasticsearch N.V. 在美国和其他国家/地区的商标、徽标或注册商标。所有其他公司和产品名称均为其各自所有者的商标、徽标或注册商标。
原文：GenAI for customer support: Explore the Elastic Support Assistant | Elastic Blog