AWS Architecture BlogAWS 架构博客
Reducing Text2SQL latency with parameterized query templates使用参数化查询模板降低 Text2SQL 延迟
If your Text2SQL system takes 25-30 seconds to respond, user engagement drops significantly. For teams scaling beyond pilot projects, this latency gap between a working demo and a production-ready tool is the biggest barrier to adoption. Without caching, every question triggers a Large Language Model (LLM) call to generate SQL, and those calls introduce challenges: unpredictable response times, throttling limits, and token costs that grow linearly with traffic. Parameterized query templates provide an intelligent caching layer that in our production deployment, reduced end-to-end latency by 80% and cut token consumption by over 50%, turning a slow prototype into a responsive production system. In this post, we walk through the architecture behind this approach, covering the implementation details, performance results, and lessons learned from running a Text2SQL system in production.如果你的 Text2SQL 系统响应需要 25-30 秒，用户参与度会显著下降。对于扩展到试点项目之外的团队来说，工作演示与生产就绪工具之间的这种延迟差距是采用的最大障碍。如果没有缓存，每个问题都会触发一次大语言模型（LLM）调用来生成 SQL，而这些调用会带来挑战：不可预测的响应时间、限流限制以及随流量线性增长的令牌成本。参数化查询模板提供了智能缓存层，在我们的生产部署中，端到端延迟降低了 80%，令牌消耗减少了 50% 以上，将缓慢的原型转变为响应迅速的生产系统。在本文中，我们将介绍这种方法背后的架构，包括实现细节、性能结果以及在生产环境中运行 Text2SQL 系统的经验教训。
When you move AI applications from pilot to production, you need solutions that scale under real traffic and perform consistently. Traditional caching strategies, storing expensive computations once and serving them many times, don’t translate directly to generative AI. End users rarely phrase the same question the same way, context varies between sessions, and outputs depend on small input variations. Yet the underlying principle (caching) still holds value. Rather than abandoning caching entirely, the key is finding the right abstraction layer where similar requests can share cached results.当您将 AI 应用程序从试点迁移到生产环境时，您需要能够在真实流量下扩展并保持一致性能的解决方案。传统的缓存策略（将昂贵的计算存储一次并多次提供服务）并不能直接应用于生成式 AI。最终用户很少用相同的方式表述相同的问题，会话之间的上下文各不相同，输出也会因输入的微小变化而不同。然而，底层原理（缓存）仍然具有价值。与其完全放弃缓存，关键在于找到合适的抽象层，使相似的请求可以共享缓存结果。
Solution overview解决方案概述
We applied the solution described in the following section to a system where business users query operational databases using natural language. You ask questions like “What were total sales in Q3?” or “Show me top performing products this month?” and the system generates SQL queries, executes them against the database, and returns results in conversational format. The system translates natural language to SQL using Amazon Bedrock foundation models, while AWS Lambda orchestrates the workflow. You can see a basic overview of used architectural components in Diagram 1.我们将下一节中描述的解决方案应用于一个系统，业务用户使用自然语言查询运营数据库。你可以问“第三季度总销售额是多少？”或“显示本月表现最佳的产品？”系统会生成 SQL 查询，对数据库执行，并以对话格式返回结果。该系统使用 Amazon Bedrock 基础模型将自然语言转换为 SQL，而 AWS Lambda 编排工作流。您可以在图 1 中看到所用架构组件的基本概述。
Figure 1 — Solution overview architecture图 1 — 解决方案概览架构
During the initial implementation phase, the approach with generating and executing SQL queries for user questions on the fly worked well. Response quality was high, and users found the interface intuitive. After these positive results, we started looking into scaling the solution for production traffic. Preserving accuracy was the main priority. Experiments with smaller, faster models didn’t provide a good trade-off between query quality and latency reduction. The accuracy degradation wasn’t acceptable for our system.在初始实施阶段，针对用户问题即时生成并执行 SQL 查询的方法效果良好。响应质量很高，用户觉得界面直观。在这些积极成果之后，我们开始研究为生产流量扩展解决方案。保持准确性是首要任务。使用更小、更快的模型进行实验并未在查询质量和延迟降低之间提供良好的权衡。准确率下降在我们的系统中是不可接受的。
This led us to explore alternative approaches, and caching naturally came to mind. Caching user question and answer pairs is the most straightforward option, but it has a fundamental limitation: underlying data changes constantly. An answer about Q3 sales cached today becomes incorrect as soon as new transactions are recorded. The cache would need constant invalidation, undermining its purpose.这促使我们探索其他方法，自然想到了缓存。缓存用户问答对是最直接的选择，但它有一个根本限制：底层数据不断变化。今天缓存的关于第三季度销售额的答案一旦记录新交易就会变得不正确。缓存需要不断失效，从而削弱其目的。
Caching the SQL query instead solves this problem. A query like:改为缓存 SQL 查询解决了这个问题。一个像这样的查询：
SELECT SUM(revenue) FROM sales WHERE quarter = 'Q3'SELECT SUM(revenue) FROM sales WHERE quarter = 'Q3'
always fetches fresh data when executed, regardless of when it was cached. Structured Query Language (SQL) captures the user’s intent in a structured, deterministic form that remains valid even as data evolves. It also happens to target the most time and token consuming step in the pipeline, since generating SQL queries requires sending full schema context and examples to a frontier model.在执行时始终获取最新数据，无论何时被缓存。结构化查询语言（SQL）以结构化、确定性的形式捕获用户意图，即使数据演变也保持有效。它恰好也针对了流程中最耗时和消耗令牌的步骤，因为生成 SQL 查询需要将完整的架构上下文和示例发送给前沿模型。
Analyzing the generated queries revealed an opportunity to go further. Many queries follow the same structure, different only in their filter values. A question about Q3 sales produces:分析生成的查询揭示了一个进一步优化的机会。许多查询遵循相同的结构，仅在筛选值上有所不同。关于第三季度销售额的问题产生：
SELECT SUM(revenue) FROM sales WHERE quarter = 'Q3'
while Q2 sales produce:而第二季度销售额产生：
SELECT SUM(revenue) FROM sales WHERE quarter = 'Q2'SELECT SUM(revenue) FROM sales WHERE quarter = 'Q2'
The same pattern appeared across product lookups, date ranges, and category filters. This led to the templating approach: instead of caching complete queries, we generalize them into templates with placeholders. A single template now covers an entire family of questions:相同的模式出现在产品查找、日期范围和类别筛选中。这导致了模板化方法：我们不缓存完整查询，而是将其泛化为带有占位符的模板。一个模板现在覆盖了一整类问题：
SELECT SUM(revenue) FROM sales WHERE quarter='{quarter}'SELECT SUM(revenue) FROM sales WHERE quarter='{quarter}'
Figure 2 — Templated SQL query cache hit图 2 — 模板化 SQL 查询缓存命中
Templating solves the limited reusability of plain user question, but still leaves a challenge: how do you match an incoming question to the right template when users phrase things differently? “Show me Q3 sales” and “What were sales in Q3?” ask for the same data but share few words. Traditional string matching or keyword lookup would miss these connections. We address this by storing each template alongside a vector embedding of its original question. When a new question arrives, we compute its embedding and perform semantic similarity search against the cache. Because embeddings capture meaning rather than surface wording, both phrasings map to the same template with high confidence. If a match is found above a confidence threshold, we extract entities from the question using lightweight named entity recognition, fill the template placeholders, and execute the query directly, bypassing the LLM entirely. In Diagram 2, you can see the flow of a cache hit.模板化解决了纯用户问题复用性有限的问题，但仍留下一个挑战：当用户措辞不同时，如何将传入的问题与正确的模板匹配？“显示第三季度销售额”和“第三季度的销售额是多少”请求的是相同数据，但共享词汇很少。传统的字符串匹配或关键词查找会错过这些联系。我们通过将每个模板与其原始问题的向量嵌入一起存储来解决这个问题。当新问题到达时，我们计算其嵌入，并针对缓存执行语义相似性搜索。由于嵌入捕获的是含义而非表面措辞，因此两种表述都以高置信度映射到同一模板。如果找到高于置信度阈值的匹配，我们使用轻量级命名实体识别从问题中提取实体，填充模板占位符，并直接执行查询，完全绕过 LLM。在图 2 中，您可以看到缓存命中的流程。
For questions without matching templates, the system falls back to full LLM generation. It then generalizes the newly generated query into a template, pairs it with the question’s embedding, and adds it to the cache. This creates a self-improving system where cache coverage grows organically as more query patterns are encountered.对于没有匹配模板的问题，系统回退到完整的 LLM 生成。然后将新生成的查询泛化为模板，与问题的嵌入配对，并添加到缓存中。这创建了一个自我改进的系统，随着遇到更多查询模式，缓存覆盖率会有机增长。
Walkthrough – Text2SQL pipeline演练 — Text2SQL 管道
The following sections describe each step of the template caching pipeline. Each user’s question flows through entity extraction, template retrieval, and SQL query execution. Cache misses trigger full LLM generation, with new queries feeding back into the cache. The following diagram shows the complete flow of a user question through the newly introduced caching layer.以下各节描述了模板缓存管道的每一步。每个用户的问题流经实体提取、模板检索和 SQL 查询执行。缓存未命中触发完整的 LLM 生成，新查询反馈到缓存中。下图显示了用户问题通过新引入的缓存层的完整流程。
Figure 3 — Text2SQL pipeline with template caching layer图 3 — 带有模板缓存层的 Text2SQL 管道
1. Entity extraction1. 实体提取
After a user submits a question, the system performs entity recognition to extract named entities and values. This step considers not only the current question but also conversation history, current date, and user preferences. This context helps resolve ambiguous references like “last month” or “my region”. Using a lightweight model like Amazon Nova 2 Lite or a custom-trained named entity recognition (NER) model, we identify entities such as dates (“Q3 2024”), names (“Product X”), categories (“electronics”), and numeric values (“top 10”). The system stores these extracted entities separately and uses them later to fill out template placeholders.用户提交问题后，系统执行实体识别以提取命名实体和值。此步骤不仅考虑当前问题，还考虑对话历史、当前日期和用户偏好。此上下文有助于解析“上个月”或“我的地区”等模糊引用。使用像 Amazon Nova 2 Lite 这样的轻量级模型或自定义训练的命名实体识别（NER）模型，我们识别诸如日期（“2024 年第三季度”）、名称（“产品 X”）、类别（“电子产品”）和数值（“前 10 名”）等实体。系统单独存储这些提取的实体，并在之后用于填充模板占位符。
2. Template retrieval through semantic search2. 通过语义搜索进行模板检索
The system converts the user’s question into an embedding vector using the same embedding model used during cache population. This vector queries the template cache through semantic similarity search, returning the closest matching templates above a confidence threshold. The search matches based on the question’s intent and structure rather than exact wording, so “What were Q3 sales?” and “Show me revenue for third quarter” both match the same template despite different phrasing.系统使用与缓存填充时相同的嵌入模型将用户问题转换为嵌入向量。该向量通过语义相似性搜索查询模板缓存，返回高于置信度阈值的最接近匹配模板。搜索基于问题的意图和结构而非精确措辞进行匹配，因此“第三季度销售额是多少？”和“显示第三季度收入”尽管措辞不同，都会匹配同一模板。
It’s important to note that the confidence threshold governs the cache retrieval layer’s precision-recall trade-off. Set it too high and the system rejects valid, differently worded questions, forcing it to build SQL from scratch. Set it too low and loosely related templates slip through, risking confident answers built on the wrong query. The right value is domain-dependent: narrow, well-templated domains tolerate stricter thresholds, while broad or sparsely covered ones need looser ones.需要注意的是，置信度阈值控制着缓存检索层的精确率-召回率权衡。设置得太高，系统会拒绝有效的、不同措辞的问题，迫使其从头构建 SQL。设置得太低，不相关的模板就会溜进来，冒着基于错误查询给出自信答案的风险。正确的值取决于领域：狭窄、模板化良好的领域可以容忍更严格的阈值，而广泛或覆盖稀疏的领域则需要更宽松的阈值。
Rather than relying on a single threshold, we suggest monitoring retrievals in production, logging matched templates and their similarity scores, so we can see when valid questions are being rejected or unrelated templates are slipping through. When embedding similarity alone doesn’t give enough precision, we added a lightweight reranking step: first we retrieve a broader set of candidate templates with a looser threshold, then re-score them with a small LLM or a specialized reranker model to select the best match. This improves precision without sacrificing recall and still costs far less than generating SQL from scratch.与其依赖单一阈值，我们建议在生产中监控检索，记录匹配模板及其相似度分数，以便我们能看到有效问题何时被拒绝或无关模板何时溜进来。当嵌入相似度本身无法提供足够精确度时，我们添加了一个轻量级的重排序步骤：首先使用较宽松的阈值检索更广泛的候选模板集，然后用小型 LLM 或专门的重新排序模型重新评分以选择最佳匹配。这在不牺牲召回率的情况下提高了精确率，并且成本仍远低于从头生成 SQL。
3. Template filling and query execution3. 模板填充和查询执行
When a matching template is found, the system maps extracted entities to template placeholders. If the template contains `{quarter}` and entity recognition extracted “Q3”, the system replaces the placeholder with the actual value. The system validates the filled SQL query for syntax correctness, then executes it directly against the database. This path bypasses the time and token intensive LLM call that generates the SQL query.找到匹配模板后，系统将提取的实体映射到模板占位符。如果模板包含 `{quarter}` 且实体识别提取了“Q3”，系统会用实际值替换占位符。系统验证填充后的 SQL 查询语法是否正确，然后直接对数据库执行。此路径绕过了生成 SQL 查询所耗费时间和令牌的 LLM 调用。
This design helps the system to protect against SQL injection on two levels. First, it validates each extracted entity against the expected format for its placeholder: a `{quarter}` must match a known set of values, a `{date}` must parse as a valid date, a numeric threshold must be a number. The system rejects values that do not pass validation before they ever reach the query. Second, the system fills the placeholders using parameterized database queries (prepared statements) rather than string interpolation, so the parameterized query mechanism treats entity values as data rather than executable SQL. This approach also catches entity-extraction errors, improving answer reliability beyond the security benefit.这种设计有助于系统在两个层面防止 SQL 注入。首先，它根据占位符的预期格式验证每个提取的实体：`{quarter}` 必须匹配一组已知值，`{date}` 必须解析为有效日期，数字阈值必须是数字。系统会在值到达查询之前拒绝未通过验证的值。其次，系统使用参数化数据库查询（预处理语句）而不是字符串插值来填充占位符，因此参数化查询机制将实体值视为数据而非可执行的 SQL。这种方法还能捕获实体提取错误，在安全性之外提高了答案的可靠性。
For richer responses, the system can retrieve multiple top-K similar templates and execute them in parallel. This provides additional context and related information beyond the primary query, for example returning both: quarterly sales totals and a breakdown by product category. The parallel execution adds minimal latency while delivering more comprehensive answers.为了提供更丰富的响应，系统可以检索多个 top-K 相似模板并并行执行。这提供了超出主要查询的额外上下文和相关信息，例如同时返回季度销售总额和按产品类别的细分。并行执行增加的延迟极小，同时提供更全面的答案。
4. Response generation and validation4. 响应生成和验证
After executing the query, the system sends results to a response generation model. This model has two jobs, both handled in a single call: judge whether the results answer the question, and, if they do, summarize them into a conversational response.执行查询后，系统将结果发送到响应生成模型。该模型有两个工作，都在一次调用中处理：判断结果是否回答了问题，如果回答了，则将其总结为对话式回复。
The sufficiency check is driven by instructions in the prompt. The system instructs the model to confirm that the results are non-empty, that they contain the fields the question asked about, and that they cover every part of the question rather than only some of it. For example, if a user asks for “Q3 sales by region” but the matched template returns only a Q3 total, the results are incomplete, and the model is instructed to flag them as insufficient instead of answering with partial data. The model returns this judgment as a structured signal alongside its response, so the pipeline can branch on it deterministically. This step helps verify that users receive accurate answers rather than partial or misleading information from imperfect template matches.充分性检查由提示中的指令驱动。系统指示模型确认结果非空，包含问题所询问的字段，并且涵盖问题的每个部分而不仅仅是其中一部分。例如，如果用户要求“按地区的第三季度销售额”，但匹配的模板仅返回第三季度总计，则结果不完整，模型被指示将其标记为不足，而不是用部分数据回答。模型将此判断作为结构化信号与其响应一起返回，以便管道可以确定性地分支。此步骤有助于确保用户获得准确的答案，而不是因不完美的模板匹配而获得部分或误导性信息。
This task is fundamentally simpler than SQL generation: instead of writing structured code from natural language, the model only needs to read tabular data and either summarize it or declare it insufficient. Because the task is simple, a smaller, faster model like Claude Haiku 4.5 can handle it effectively.这项任务从根本上比 SQL 生成更简单：模型无需从自然语言编写结构化代码，只需读取表格数据并总结或声明其不足。由于任务简单，像 Claude Haiku 4.5 这样更小、更快的模型可以有效地处理它。
On a cache hit, there is only a single lightweight LLM call, which improves both latency and cost thanks to the smaller model. On a cache miss, the model flags the template results as insufficient and the system falls back to full SQL generation before producing the answer, for three calls in total: the sufficiency check, the SQL generation, and the response. That is one call more than the uncached pipeline, so misses carry extra latency. The trade-off is favorable because the added call is the cheap sufficiency check rather than another expensive generation, and because at a healthy hit rate the savings on hits outweigh the penalty on misses.在缓存命中时，只有一次轻量级 LLM 调用，由于模型更小，延迟和成本都得到改善。在缓存未命中时，模型将模板结果标记为不足，系统在生成答案之前回退到完整的 SQL 生成，总共三次调用：充分性检查、SQL 生成和响应。这比未缓存管道多一次调用，因此未命中会带来额外延迟。这种权衡是有利的，因为增加的调用是廉价的充分性检查而不是另一次昂贵的生成，而且在良好的命中率下，命中的节省超过未命中的惩罚。
5. Fallback to full generation5. 回退到完整生成
If no template matches the confidence threshold, or if the validation step determines that cached results are insufficient, the system falls back to the standard Text2SQL pipeline. The question, along with the full context, goes to the foundation model for SQL generation. The generated query executes against the database, and results return to the user. Importantly, this newly generated query doesn’t disappear. It enters the reinforcement loop.如果没有模板匹配置信度阈值，或者验证步骤确定缓存结果不足，系统会回退到标准的 Text2SQL 管道。问题连同完整上下文一起发送到基础模型以生成 SQL。生成的查询对数据库执行，结果返回给用户。重要的是，这个新生成的查询不会消失。它进入强化循环。
6. Reinforcement loop for cache growth6. 用于缓存增长的强化循环
After a successful fallback generation, the system evaluates whether the new query should join the template cache. If the query executed successfully and returned valid results, it becomes a candidate for templating. The system generalizes the query by replacing specific values with placeholders and computes the original question’s embedding. It then adds this new template-question pair to the vector store, expanding cache coverage. Over time, the cache grows organically to cover query patterns specific to your users’ actual needs.成功回退生成后，系统评估新查询是否应加入模板缓存。如果查询成功执行并返回有效结果，它就成为模板化的候选。系统通过用占位符替换特定值来泛化查询，并计算原始问题的嵌入。然后，它将这对新的模板-问题添加到向量存储中，扩大缓存覆盖率。随着时间的推移，缓存会有机增长，以覆盖用户实际需求特有的查询模式。
Results and performance gains结果和性能提升
The figures in this section come from our production deployment but treat them as an illustrative model rather than a fixed benchmark. Exact token counts and latencies depend on your schema size, prompt design, model choice, and query mix. What generalizes is the direction of the improvement, not the specific numbers.本节中的数字来自我们的生产部署，但请将其视为说明性模型而非固定基准。确切的令牌数和延迟取决于您的架构大小、提示设计、模型选择和查询组合。可推广的是改进的方向，而不是具体的数字。
The dominant cost and latency in a Text2SQL request come from a single step: generating the SQL query. That call sends the user question, conversation history, the database schema, few-shot examples, and domain guidance to a powerful LLM such as Anthropic Claude Sonnet, which is needed to produce reliable queries. In our deployment this prompt runs on the order of 60K input tokens for a few hundred output tokens, and takes roughly 15-20 seconds. Every other step: embedding, vector search, template filling, and query execution, is minor by comparison. Entity recognition, runs on a dedicated NER model hosted on Amazon SageMaker AI rather than an LLM, adding negligible cost and latency next to SQL generation. Optimizing the pipeline is therefore mostly about avoiding that one expensive call.Text2SQL 请求中主要的成本和延迟来自一个步骤：生成 SQL 查询。该调用将用户问题、对话历史、数据库架构、少样本示例和领域指导发送给强大的 LLM（如 Anthropic Claude Sonnet），这是生成可靠查询所必需的。在我们的部署中，此提示大约有 6 万输入令牌和几百个输出令牌，大约需要 15-20 秒。其他每个步骤——嵌入、向量搜索、模板填充和查询执行——相比之下都很次要。实体识别在 Amazon SageMaker AI 上托管的专用 NER 模型上运行，而不是 LLM，与 SQL 生成相比，增加的成本和延迟可以忽略不计。因此，优化管道主要是为了避免那一次昂贵的调用。
On a cache hit, the system skips SQL generation entirely. What remains is response summarization, turning the query results into a conversational answer, which runs on a small model with a small prompt (on the order of a couple thousand input tokens). Because summarization is needed on both, the cached and uncached paths, a cache hit does not remove tokens completely, but it eliminates the 60K-token generation call, cutting token consumption by roughly 90% on that request.在缓存命中时，系统完全跳过 SQL 生成。剩下的是响应总结，将查询结果转换为对话式答案，它在一个小模型上以小型提示（约几千个输入令牌）运行。由于缓存命中和未命中路径都需要总结，因此缓存命中并不能完全消除令牌，但消除了 6 万令牌的生成调用，将该请求的令牌消耗减少了大约 90%。
This 90% is the saving on a single cache hit. Overall cost depends on the average across all requests, since cache misses still incur the full generation cost. At the roughly 60% hit rate we observed in production, the blended reduction across all traffic comes out above 50%. Latency follows the same pattern. An uncached request spends 15-20 seconds on the SQL call, retries and error handling included, then a few more seconds on summarization, putting a typical request in the 25-30 second range. On a cache hit, retrieval, template filling, and execution finish well under a second, and the remaining time is almost entirely the summarization call. That brings the end-to-end cache-hit path under 5 seconds, roughly an 80% reduction, or about 6x faster. It also pinpoints where the residual latency comes from: not the cache lookup, but the one LLM call that still has to run.这 90% 是单次缓存命中的节省。总体成本取决于所有请求的平均值，因为缓存未命中仍会产生完整的生成成本。在我们生产中观察到的约 60% 命中率下，所有流量的综合降低超过 50%。延迟遵循相同的模式。未缓存的请求在 SQL 调用上花费 15-20 秒（包括重试和错误处理），然后在总结上再花几秒，使典型请求处于 25-30 秒范围内。在缓存命中时，检索、模板填充和执行在不到一秒内完成，剩余时间几乎全部是总结调用。这使端到端缓存命中路径低于 5 秒，大约减少 80%，或约 6 倍。它还指出了剩余延迟的来源：不是缓存查找，而是仍然必须运行的一次 LLM 调用。
These per-request gains only matter if cache hits are common. In our production system the hit rate reached about 60% after roughly two weeks of active use, though the achievable rate depends heavily on the domain and how repetitive the queries are. Cache misses run the full pipeline plus the small sufficiency check, so they cost marginally more than a purely uncached request, which means the net gain comes entirely from hits. As the reinforcement loop keeps adding templates, the hit rate climbs and both the cost and latency benefits continue to compound.这些每请求的收益只有在缓存命中常见时才有意义。在我们的生产系统中，经过大约两周的积极使用后，命中率达到约 60%，但可达到的速率在很大程度上取决于领域以及查询的重复程度。缓存未命中运行完整管道加上小的充分性检查，因此它们比完全未缓存的请求略贵，这意味着净收益完全来自命中。随着强化循环不断添加模板，命中率攀升，成本和延迟收益都继续累积。
Conclusion结论
Scaling AI applications to production often requires rethinking traditional optimization strategies. In this post, we demonstrated how template-based caching addresses the latency and cost challenges of Text2SQL systems without sacrificing accuracy. By caching SQL query structures rather than complete responses and using semantic similarity to match user questions to templates, the system can bypass expensive LLM inference calls. The reinforcement loop ensures cache coverage grows organically based on actual usage patterns.将 AI 应用程序扩展到生产环境通常需要重新思考传统的优化策略。在本文中，我们展示了基于模板的缓存如何在不过度牺牲准确性的情况下解决 Text2SQL 系统的延迟和成本挑战。通过缓存 SQL 查询结构而不是完整响应，并使用语义相似性将用户问题与模板匹配，系统可以绕过昂贵的 LLM 推理调用。强化循环确保缓存覆盖率根据实际使用模式有机增长。
In practice, this means: 6x faster response times on cache hits, inference costs decrease proportionally to your cache hit rate, and accuracy remains high because templates are generated by the most capable models. The patterns we covered, such as semantic matching, output generalization, entity extraction, and continuous improvement loops, extend beyond Text2SQL to any AI system where similar requests should produce structurally similar outputs.在实践中，这意味着：缓存命中的响应时间快 6 倍，推理成本与缓存命中率成比例下降，并且准确性保持较高，因为模板由最有能力的模型生成。我们涵盖的模式，如语义匹配、输出泛化、实体提取和持续改进循环，可以扩展到 Text2SQL 之外的任何 AI 系统，在这些系统中，相似的请求应产生结构相似的输出。
Further reading进一步阅读
Generating value from enterprise data: Best practices for Text2SQL and generative AI从企业数据中创造价值：Text2SQL 和生成式 AI 的最佳实践
Enterprise-grade natural language to SQL generation using LLMs: Balancing accuracy, latency, and scale使用 LLM 进行企业级自然语言到 SQL 生成：平衡准确性、延迟和规模
Build a robust text-to-SQL solution generating complex queries, self-correcting, and querying diverse data sources构建一个稳健的文本到 SQL 解决方案，生成复杂查询、自我纠正并查询多种数据源
Text-to-SQL solution powered by Amazon Bedrock由 Amazon Bedrock 提供支持的文本到 SQL 解决方案
Amazon S3 Vectors: First cloud storage with native vector support at scaleAmazon S3 Vectors：首个在云存储中原生支持大规模向量的服务
Amazon Nova 2 LiteAmazon Nova 2 Lite