上下文增加。负载不一定要增加。
从 AI 助手到 RAG 系统，从代理工作流到文档分析，Aether Compress 可以适应不同的使用场景，从而减少发送到 LLM 的不必要输入负载。
应用不同。上下文问题相同。
随着 AI 应用的增长，发送到模型的信息也会增加。对话历史、检索结果、工具输出、文档和系统指令在每次新请求中都会成为输入成本的一部分。
Aether 创建了一个单独的层，可以在负载到达 LLM 之前进行优化。
在使用上下文的所有地方都可以作为优化的空间。
使用领域更多地与发送给 LLM 的输入结构相关，而不是行业。
让长对话更轻便。
随着AI助手的发展，对话历史、系统指令和额外上下文可能会在每次请求中重复传输。Aether Compress通过优化发送给模型的上下文，帮助减少输入负载。
不必传递检索到的完整上下文。
检索层可能会为单个查询返回大量文档片段。Aether 可以在 LLM 调用前优化检索到的上下文，帮助你生成更小的输入。
不要在每次支持请求中重复发送相同的负载。
支持机器人；可以在同一请求中携带客户历史、产品文档、以前的信息和支持规则。Aether 确保在 LLM 之前优化此上下文。
随着 Agent 的成长，上下文不必同步增长。
在 Agent 系统中，工具结果、任务历史和中间步骤可以在上下文中快速积累。Aether 可用于在下一次模型调用之前减少传输的输入负载。
更高效地发送大型技术上下文。
代码助手和技术 AI 工具可以在同一上下文中携带源代码、错误日志、配置和文档。Aether 可以在模型调用之前优化此输入。
不要在每次提问时重复携带长文档。
在处理报告、合同、手册和企业文档的 AI 应用中，所需的上下文可以根据查询进行优化，从而向模型发送较小的输入。
根据上下文。根据查询。
可用于希望优化内容而不针对特定问题的流程。对话历史、代理状态或携带一般上下文的系统是例子。
如果事先知道用户的查询，Aether 可以将查询也纳入优化过程，从而以面向该请求的方式处理上下文。
检索完成后优化可以开始。
Aether 不会替代检索系统。 它会在检索结果和 LLM 调用之间加入。
应用会收到问题。
现有的 RAG 基础设施会获取相关的文档片段。
获取到的上下文会根据用户查询进行优化。
优化后的上下文会发送到您现有的模型提供商。
单次请求中的 token 差异可能看起来很小。 当相同的优化在数千或数百万次 LLM 调用中重复出现时， 总输入量的差异会增大。
Aether 不是模型选择。 由于它在上下文准备阶段起作用， 可以被添加在您现有 AI 流程之前。
如果问题是 token,行业是次要的。
Aether 并不是根据特定行业的术语设计的优化层，因此相同的架构可以在不同的 AI 应用中使用。
使用 AI 功能的软件产品。
产品、支持和购物助手。
文档和基于知识库的 AI 应用。
长文档和合同分析。
内部知识库和员工助手。
使用代码、日志和技术上下文的应用。
获取上下文。或者获取答案。
优化后的上下文会直接返回到您的应用程序。 您当前的基础设施将自动进行下一次LLM调用。
上下文首先通过 Aether Compress 优化， 然后发送到您选择的AI提供商， 最终答案返回到您的应用程序。
并非每个请求都需要压缩。
如果上下文已经很小，需要优化的额外负载可能有限。
在调用 LLM 次数非常少的应用程序中，总体经济影响自然可能更低。
如果输入已经被密集优化，额外减少的空间可能有限。
最准确的决定是通过在您自己的真实输入上测试 Aether 得出的。