حل سوالات قطعی با هوش مصنوعی مولد: یک رویکرد عملی

Summarize this content to 400 words in Persian Lang

مقدمه

در چشم انداز پویا مولد هوش مصنوعی امروزی، مدل های زبانی در مقیاس بزرگ (LLM) تعامل ما با فناوری را به شدت متحول کرده اند. این مدل‌ها قابلیت‌های استثنایی را در کارهایی مانند تولید متن، تحلیل احساسات و درک زمینه‌ای نشان داده‌اند. با این حال، هنگامی که با سناریوهایی مواجه می شویم که نیازمند دقت مطلق و نتایج قطعی هستند، با محدودیت های ذاتی مواجه می شویم که باید به روش های نوآورانه مورد توجه قرار گیرد.

چالش مدل های غیر قطعی

مبانی عملیات LLM

مدل‌های زبانی در مقیاس بزرگ با استفاده از یک سیستم احتمالی پیچیده عمل می‌کنند. در هسته خود، این مدل ها:

پیش‌بینی متنی: آنها زمینه قبلی را تجزیه و تحلیل می کنند تا محتمل ترین کلمه یا دنباله بعدی را پیش بینی کنند.

توزیع احتمال: آنها یک توزیع احتمال برای گزینه های مختلف پاسخ ایجاد می کنند.

دما و تصادفی بودن: از پارامترهایی مانند دما برای کنترل خلاقیت در مقابل. جبر در پاسخ های آنها

این ماهیت احتمالی دقیقاً همان چیزی است که LLM ها را برای کارهای خلاقانه و تحلیلی بسیار متنوع می کند، اما همچنین چیزی است که آنها را برای پرس و جوهایی که به دقت عددی یا دقت مطلق نیاز دارند کمتر قابل اعتماد می کند.

زمینه: از یک POC شکست خورده تا یک راه حل نوآورانه

طی چند ماه گذشته، در حین انجام چندین گفتگو در مورد هوش مصنوعی Generative، یک مکالمه خاص توجه من را به خود جلب کرد. یک تیم توسعه نارضایتی خود را از اثبات مفهومی (POC) که به نظر آنها ناموفق بود، با من در میان گذاشتند. مشکل: اجرای هوش مصنوعی مولد آنها برای تجزیه و تحلیل بلیط پشتیبانی نتایج متناقضی ایجاد کرد.

با حفاری عمیق تر در مورد، یک الگوی جالب ظاهر شد:

چه چیزی خوب کار کرد:

“تجزیه و تحلیل تیکت پشتیبانی X”
“خلاصه مورد Y چیست؟”
“این گزارش حادثه چه چیزی را نشان می دهد؟”

این سوالات که نیازمند درک زمینه ای و تحلیل کیفی بودند، پاسخ های دقیق و مفیدی دریافت کردند.

آنچه به طور مداوم شکست می خورد:

“کدام بخش دارای بیشترین بلیط باز است؟”
ماه گذشته به چند بلیط پاسخ داده شد؟
“متوسط ​​زمان تفکیک چقدر است؟”

سوالاتی که نیاز به دقت عددی و محاسبات دقیق داشتند، هرگز نتایج قابل اعتمادی ارائه نکردند.

مکاشفه کلیدی

دلیل شکست زمانی آشکار شد که ماهیت اساسی LLM ها را درک کردیم: آنها ذاتا غیر قطعی هستند. نقطه قوت آن در پردازش زبان طبیعی و تولید محتوای مبتنی بر احتمال است، نه در انجام محاسبات دقیق یا پرس و جوهای دقیق بر روی داده های ساختاریافته.

این چشم انداز من را بر آن داشت تا پرسش کلیدی را دوباره فرموله کنم:

چگونه می توانیم به سؤالات قطعی پاسخ دهیم وقتی که یک LLM، بنا به ماهیت خود، برای این کار طراحی نشده است؟

پاسخ از درک این موضوع بود که ما نیازی به وادار کردن LLM به انجام کاری که برای انجام آن طراحی نشده بود، به دست آمد. در عوض، ما می توانیم:

از LLM برای بهترین کار استفاده کنید: هدف سوال را درک کنید.
در صورت لزوم آن هدف را به پرس و جوهای ساختاریافته ترجمه کنید.
از ابزارهای تخصصی برای محاسبات دقیق استفاده کنید.
نتایج را به صورت منسجم و طبیعی ارائه دهید.

شکاف بین دقت و احتمال: پیاده سازی راه حل

هنگامی که هسته اصلی مشکل شناسایی شد، پیشنهادی ایجاد کردم که ابتدا ماهیت پرس و جو را مشخص می کند و سپس پردازش مناسب را اعمال می کند.

طبقه بندی پرس و جو

پرس و جوهای قطعی:

ویژگی ها:

آنها به شمارش دقیق و قابل تکرار نیاز دارند.
آنها شامل تجمیع در زمینه های بلیط خاص هستند.
آنها بر اساس طرح تعریف شده در آتنا عمل می کنند.

مثال های واقعی:

“کدام بخش دارای بیشترین بلیط باز است؟” SQL تولید شده:

SELECT departamento, COUNT(*) as total
FROM tickets
WHERE estado != ‘CLOSED’
GROUP BY departamento
ORDER BY total DESC

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

“بزرگترین علت حوادث ثبت شده چیست؟” SQL تولید شده:

SELECT causante, COUNT(*) as total_incidentes
FROM tickets
WHERE solicitudes = ‘Incidentes’
GROUP BY causante
ORDER BY total_incidentes DESC
LIMIT 1

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

پرس و جوهای غیر قطعی:

ویژگی ها:

آنها نیاز به تجزیه و تحلیل متنی محتوای بلیط دارند.
آنها از پردازش زبان طبیعی بهره می برند.
آنها توسط پایگاه دانش بستر مدیریت می شوند.

مثال ها:

تجزیه و تحلیل محتوای خاص بلیط
خلاصه موارد
تفسیر الگوها در گزارش ها

جریان پردازش

جریانی که تصمیم گرفتم برای مقابله با چالش انجام دهم به سه مرحله ساده تقسیم می شود.

ارزیابی اولیه

از اعلان تعریف شده برای تعیین قطعی بودن پرس و جو استفاده کنید. در این مرحله و همانطور که بعدا خواهیم دید، من از یک LLM استفاده می کنم تا بدانم آیا چیزی که کاربر می پرسد ماهیت قطعی است یا خیر.
زمانی که قطعی باشد، LLM SQL مناسب را درون تگ ها تولید می کند . این بر اساس جدول آتنا و فرهنگ لغت داده است.

تعقیب قضایی

پرس و جوهای قطعی: از طریق Athena اجرا می شود، ما یک SQL ایجاد شده توسط یک LLM ارسال می کنیم که پرس و جوی کاربر را برآورده می کند.
پرس و جوهای غیر قطعی: آنها از طریق Amazon Bedrock – Knowledge Base پردازش می شوند. این پایگاه دانش حاوی همان فایل CSV است که ما در آتنا از آن استفاده می کنیم.

قالب بندی پاسخ

نتایج آتنا به 25 رکورد محدود شده است (این به این دلیل است که ما نمی‌خواهیم سؤالی بتواند کل پایگاه داده را برگرداند).
LLM برای تبدیل نتایج به پاسخ های طبیعی استفاده می شود.
سازگاری زبان سؤال اصلی حفظ می شود.

معماری راه حل

معماری پیاده‌سازی شده چالش پرس و جوهای قطعی را از طریق ترکیب استراتژیک خدمات AWS و پردازش LLM حل می‌کند. بیایید در مورد هر جزء و اجرای دقیق آن بحث کنیم.

1. ذخیره سازی داده ها و لایه آماده سازی

1.1 ساختار داده های پایه

این سیستم بر روی یک فایل CSV میزبانی شده در S3 کار می کند که حاوی سوابق بلیط است. تهیه این داده ها بسیار مهم است و نیاز به:

CREATE EXTERNAL TABLE IF NOT EXISTS `default`.`tickets` (
`fechaResolucion` string,
`asignado` string,
`solicitudes` string,
`producto` string,
`departamento` string,
— [resto de campos] )
COMMENT “Tabla de tiquetes de Ejemplo”
ROW FORMAT SERDE ‘org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe’
WITH SERDEPROPERTIES (‘field.delim’ = ‘;’)
STORED AS INPUTFORMAT ‘org.apache.hadoop.mapred.TextInputFormat’
OUTPUTFORMAT ‘org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat’
LOCATION ‘s3://MiBucket/’
TBLPROPERTIES (‘classification’ = ‘csv’);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این DDL ضروری است زیرا:

ساختار دقیقی را که آتنا برای پرس و جوها استفاده می کند، تعریف می کند.
جدا کننده را مشخص می کند ; برای تفسیر صحیح CSV.
محل قرارگیری داده ها را در S3 تنظیم می کند.
فرمت ورودی/خروجی را برای بهینه سازی پردازش پیکربندی کنید.

1.2 دیکشنری داده ها

همراه با ساختار، ما یک فرهنگ لغت داده دقیق را حفظ می کنیم که LLM از آن برای درک زمینه هر زمینه استفاده می کند. به عنوان مثال:

fechaResolucion: Campo que indica la fecha y hora de resolución del ticket.
Formato: mes/dia/anno hora:minuto
causante: Campo categórico que indica si el ticket fue levantado por A o B
departamento: Campo calculado descriptivo del departamento que atendió

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

2. سیستم طبقه بندی پرس و جو

2.1 درخواست طبقه بندی

اولین قدم مهم این است که تعیین کنیم آیا یک پرس و جو قطعی است یا خیر. ما این را با استفاده از یک دستور خاص پیاده سازی می کنیم:

StringBuilder prompt = new StringBuilder(
“Eres un experto en análisis de tiquetes, necesito que analices ” +
“la pregunta que te indico y si esa pregunta no puede ser respondida ” +
“por un LLM (ya que es determinística) respondas solamente la frase ” +
“‘DETERMINISTICA’ seguido de un SQL dentro de un tag que cumpla ” +
“con la definición de la siguiente tabla de Athena y su glosario…”
);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این اعلان حیاتی است زیرا:

نقش خاص مدل را مشخص می کند.
قالب پاسخ مورد انتظار دقیق را تنظیم می کند.
شامل زمینه طرحواره و فرهنگ لغت داده است.
یک پاسخ ساختاریافته و عملی را وادار کنید.

2.2 تولید SQL با استفاده از LLM

هنگامی که سیستم تشخیص داد که پرس و جو قطعی است، SQL را برای ارسال به Athena برای اجرا برمی گرداند. این به لطف این واقعیت حاصل می شود که ما در اعلان قبلی تعریف جدول و فرهنگ لغت داده را نشان می دهیم.

در مقاله قبلی در مورد استفاده از Bedrock با RDS{:target=”_blank”} توضیح دادم که چگونه می توان از LLM برای تولید SQL استفاده کرد. و تجربه قبلی بخشی از این راه حل است.

2.2.1 پیکربندی و فراخوانی مدل

var message = Message.builder()
.content(ContentBlock.fromText(prompt.toString()))
.role(ConversationRole.USER)
.build();

try {
var client = BedrockRuntimeClient.builder()
.credentialsProvider(DefaultCredentialsProvider.create())
.region(Region.US_EAST_1)
.build();

// Send the message with a basic inference configuration.
ConverseResponse response = client.converse(request -> request
.modelId(FOUNDATIONAL_MODEL)
.messages(message)
.inferenceConfig(config -> config
.maxTokens(512) // Suficiente para consultas SQL complejas
.temperature(0.5F) // Bajo para mayor precisión
.topP(0.9F))); // Alta coherencia en la estructura

// Retrieve the generated text from Bedrock’s response object.
var responseText = response.output().message().content().get(0).text();
client.close();

return responseText;

} catch (SdkClientException e) {
System.err.printf(“ERROR: Can’t invoke ‘%s’. Reason: %s”, FOUNDATIONAL_MODEL, e.getMessage());
return “No se puede responder esa pregunta”;
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

2.2.2 مثال جریان کامل

برای نشان دادن این روند، اجازه دهید این سوال را در نظر بگیریم: “کدام بخش دارای بیشترین بلیط باز است؟”

ورودی پردازش شده توسط مدل:

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

SQL تولید شده است:

SELECT
departamento,
COUNT(*) as total_tickets
FROM tickets
WHERE fechaResolucion IS NULL
GROUP BY departamento
ORDER BY total_tickets DESC
LIMIT 25

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

SQL تولید شده مستقیماً برای اجرا به آتنا فرستاده می شود، با استفاده از این واقعیت که مدل از قبل ساختار دقیق جدول و معنای هر فیلد را به لطف زمینه ارائه شده می داند.

کلید موفقیت این رویکرد در دقت زمینه ارائه شده به مدل و سازگاری در قالب پاسخ درخواستی نهفته است، که امکان تولید قابل اعتماد پرس و جوهای SQL را فراهم می کند که دقیقاً با طرح ما مطابقت دارند.

3. پردازش پرس و جو قطعی

3.1 اجرای کوئری های آتنا

هنگامی که یک پرس و جو قطعی شناسایی شد، سیستم SQL تولید شده را اجرا می کند:

public String executeAthenaQuery(String query, String database) {
try (AthenaClient athenaClient = AthenaClient.builder()
.region(Region.US_EAST_1) // Ajusta la región según tu configuración
.credentialsProvider(DefaultCredentialsProvider.create())
.build()) {

// Configurar la solicitud de consulta
StartQueryExecutionRequest startQueryExecutionRequest = StartQueryExecutionRequest.builder()
.queryString(query)
.queryExecutionContext(QueryExecutionContext.builder()
.database(database)
.build())
.resultConfiguration(ResultConfiguration.builder()
.build())
.build();

// Iniciar la consulta
StartQueryExecutionResponse startQueryExecutionResponse = athenaClient.startQueryExecution(startQueryExecutionRequest);
String queryExecutionId = startQueryExecutionResponse.queryExecutionId();

// Esperar a que la consulta termine
waitForQueryToComplete(athenaClient, queryExecutionId);

// Obtener los resultados de la consulta
return getQueryResults(athenaClient, queryExecutionId);

} catch (Exception e) {
e.printStackTrace();
throw new RuntimeException(“Error executing Athena query”, e);
}
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این کد:

ارتباط ایمن با آتنا برقرار کنید.
پرس و جو را به صورت ناهمزمان اجرا می کند.
شناسه اجرا را برای ردیابی کنترل می کند.

4. قالب بندی پاسخ

آخرین مرحله شامل تبدیل نتایج فنی به پاسخ های قابل درک است:

StringBuilder prompt = new StringBuilder(
“Eres un experto en atención a consultas, debes responder ” +
“de manera profesional, concisa y clara. La pregunta realizada fue ” +
preguntaUsuario + ” y la respuesta de la base de datos es: ” +
respuestaBD);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این قالب بندی:

زمینه سوال اصلی را حفظ می کند.
پاسخ را به طور طبیعی ساختار دهید.
دقت داده های به دست آمده را حفظ می کند.

5. رسیدگی به پرس و جوهای غیر قطعی

هنگامی که سیستم یک پرس و جو را غیر قطعی تشخیص می دهد، به این معنی است که نیاز به تجزیه و تحلیل متنی یا تفسیری دارد که با یک پرس و جو مستقیم SQL قابل حل نیست. در این حالت، سیستم مستقیماً از مدل Anthropic برای پردازش پرس و جو استفاده می کند.

5.1 شناسایی و پردازش

شناسایی در مرحله اول فرآیند اتفاق می افتد، زمانی که مدل کلمه “DETERMINISTIC” و سپس یک SQL را بر نمی گرداند. در این حالت، سیستم به طور مستقیم با استفاده از مدل Bedrock به پردازش پرس و جو می‌پردازد.

5.2 پیکربندی مدل

برای این پرسش‌ها، از پیکربندی پایه مدل Anthropic Sonnet 3.5 v2 استفاده می‌کنیم:

RetrieveAndGenerateInput input = RetrieveAndGenerateInput.builder()
.text(prompt)
.build();

KnowledgeBaseRetrieveAndGenerateConfiguration knowledgeConfig = KnowledgeBaseRetrieveAndGenerateConfiguration
.builder()
.knowledgeBaseId(KNOWLEDGE_BASE_ID)
.modelArn(MODEL_ARN)
.build();

RetrieveAndGenerateConfiguration retrieveConfig = RetrieveAndGenerateConfiguration.builder()
.knowledgeBaseConfiguration(knowledgeConfig)
.type(“KNOWLEDGE_BASE”)
.build();

RetrieveAndGenerateRequest request1 = RetrieveAndGenerateRequest.builder()
.retrieveAndGenerateConfiguration(retrieveConfig)
.input(input)
.build();

RetrieveAndGenerateResponse response1 = bedrockAgentRuntimeClient.retrieveAndGenerate(request1);

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

5.3 نمونه هایی از پرس و جوهای غیر قطعی

پرس و جوهای زیر نمونه های معمولی هستند که سیستم به صورت تفسیری پردازش می کند:

تجزیه و تحلیل محتوا:

Pregunta: “¿Cuáles son los patrones comunes en los tickets de error de conexión?”

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

تفسیر پرونده:

Pregunta: “¿Cómo se resolvió un caso similar la última vez?”

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

خلاصه های متنی:

Pregunta: “Resume el problema principal del ticket #12345”

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

در این موارد سیستم:

تلاشی برای تولید SQL نمی کند.
پرس و جو را مستقیماً از طریق مدل پردازش کنید.
پاسخی را بر اساس زمینه و اطلاعات موجود ارائه می دهد.
قالب و لحن را با سوال اصلی مطابقت دهید.

پاسخ مستقیماً به کاربر تحویل داده می شود و ماهیت مکالمه و زمینه سؤال اصلی را حفظ می کند.

نتیجه گیری و مراحل بعدی

پیاده‌سازی این سیستم ترکیبی، که دقت پرسش‌های SQL را با ظرفیت تفسیری مدل‌های زبانی ترکیب می‌کند، نشان‌دهنده شروعی است از آنچه می‌توان با هوش مصنوعی مولد در تجزیه و تحلیل داده‌های تجاری به دست آورد.

بازتاب های کلیدی

تمایز خودکار بین پرس و جوهای قطعی و غیر قطعی به ما امکان می دهد از بهترین هر دو جهان استفاده کنیم: درستی پایگاه داده های رابطه ای و درک متنی LLM.
معماری پیاده‌سازی شده نشان می‌دهد که می‌توان دقت لازم را در محیط‌های سازمانی حفظ کرد و در عین حال تجربه کاربر را به طور قابل‌توجهی بهبود بخشید.
استفاده از خدمات مدرن مانند Amazon Bedrock به ما اجازه می دهد تا راه حل های پیشرفته هوش مصنوعی را بدون نیاز به مدیریت زیرساخت های پیچیده و دسترسی به پیشرفته ترین LLM پیاده سازی کنیم.

من از شما دعوت می کنم که این مثال را به عنوان نقطه شروعی برای کاوش های خود در نظر بگیرید. چه به دنبال بهبود سیستم های تجزیه و تحلیل بلیط خود باشید، چه بخواهید این مفاهیم را در حوزه های کاملاً متفاوت به کار ببرید، احتمالات بسیار زیاد است.

GenAI نحوه تعامل ما با داده ها را تغییر می دهد و من هیجان زده هستم که بخشی از این تحول باشم. آیا شما هم جرات می کنید بخشی از آن باشید؟

   SELECT departamento, COUNT(*) as total
   FROM tickets
   WHERE estado != 'CLOSED'
   GROUP BY departamento
   ORDER BY total DESC

   SELECT causante, COUNT(*) as total_incidentes
   FROM tickets
   WHERE solicitudes = 'Incidentes'
   GROUP BY causante
   ORDER BY total_incidentes DESC
   LIMIT 1

CREATE EXTERNAL TABLE IF NOT EXISTS `default`.`tickets` (
 `fechaResolucion` string,
 `asignado` string,
 `solicitudes` string,
 `producto` string,
 `departamento` string,
 -- [resto de campos]
)
COMMENT "Tabla de tiquetes de Ejemplo"
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.lazy.LazySimpleSerDe'
WITH SERDEPROPERTIES ('field.delim' = ';')
STORED AS INPUTFORMAT 'org.apache.hadoop.mapred.TextInputFormat'
OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION 's3://MiBucket/'
TBLPROPERTIES ('classification' = 'csv');

fechaResolucion: Campo que indica la fecha y hora de resolución del ticket.
                Formato: mes/dia/anno hora:minuto
causante: Campo categórico que indica si el ticket fue levantado por A o B
departamento: Campo calculado descriptivo del departamento que atendió

StringBuilder prompt = new StringBuilder(
   "Eres un experto en análisis de tiquetes, necesito que analices " +
   "la pregunta que te indico y si esa pregunta no puede ser respondida " +
   "por un LLM (ya que es determinística) respondas solamente la frase " +
   "'DETERMINISTICA' seguido de un SQL dentro de un tag  que cumpla " +
   "con la definición de la siguiente tabla de Athena y su glosario..."
);

var message = Message.builder()
      .content(ContentBlock.fromText(prompt.toString()))
      .role(ConversationRole.USER)
      .build();

try {
  var client = BedrockRuntimeClient.builder()
      .credentialsProvider(DefaultCredentialsProvider.create())
      .region(Region.US_EAST_1)
      .build();

  // Send the message with a basic inference configuration.
  ConverseResponse response = client.converse(request -> request
          .modelId(FOUNDATIONAL_MODEL)
          .messages(message)
          .inferenceConfig(config -> config
                  .maxTokens(512)    // Suficiente para consultas SQL complejas
                  .temperature(0.5F) // Bajo para mayor precisión
                  .topP(0.9F)));     // Alta coherencia en la estructura

  // Retrieve the generated text from Bedrock's response object.
  var responseText = response.output().message().content().get(0).text();
  client.close();

  return responseText;

} catch (SdkClientException e) {
  System.err.printf("ERROR: Can't invoke '%s'. Reason: %s", FOUNDATIONAL_MODEL, e.getMessage());
  return "No se puede responder esa pregunta";
}

[Todo el contexto anterior + schema + diccionario]
Pregunta: ¿Cuál departamento tiene más tickets abiertos?

SELECT
   departamento,
   COUNT(*) as total_tickets
FROM tickets
WHERE fechaResolucion IS NULL
GROUP BY departamento
ORDER BY total_tickets DESC
LIMIT 25

public String executeAthenaQuery(String query, String database) {
 try (AthenaClient athenaClient = AthenaClient.builder()
   .region(Region.US_EAST_1) // Ajusta la región según tu configuración
   .credentialsProvider(DefaultCredentialsProvider.create())
   .build()) {

   // Configurar la solicitud de consulta
   StartQueryExecutionRequest startQueryExecutionRequest = StartQueryExecutionRequest.builder()
     .queryString(query)
     .queryExecutionContext(QueryExecutionContext.builder()
       .database(database)
       .build())
     .resultConfiguration(ResultConfiguration.builder()
       .build())
     .build();

   // Iniciar la consulta
   StartQueryExecutionResponse startQueryExecutionResponse = athenaClient.startQueryExecution(startQueryExecutionRequest);
   String queryExecutionId = startQueryExecutionResponse.queryExecutionId();

   // Esperar a que la consulta termine
   waitForQueryToComplete(athenaClient, queryExecutionId);

   // Obtener los resultados de la consulta
   return getQueryResults(athenaClient, queryExecutionId);

 } catch (Exception e) {
   e.printStackTrace();
   throw new RuntimeException("Error executing Athena query", e);
 }
}

StringBuilder prompt = new StringBuilder(
   "Eres un experto en atención a consultas, debes responder " +
   "de manera profesional, concisa y clara. La pregunta realizada fue " +
   preguntaUsuario + " y la respuesta de la base de datos es: " +
   respuestaBD);

RetrieveAndGenerateInput input = RetrieveAndGenerateInput.builder()
        .text(prompt)
        .build();

KnowledgeBaseRetrieveAndGenerateConfiguration knowledgeConfig = KnowledgeBaseRetrieveAndGenerateConfiguration
        .builder()
        .knowledgeBaseId(KNOWLEDGE_BASE_ID)
        .modelArn(MODEL_ARN)
        .build();

RetrieveAndGenerateConfiguration retrieveConfig = RetrieveAndGenerateConfiguration.builder()
        .knowledgeBaseConfiguration(knowledgeConfig)
        .type("KNOWLEDGE_BASE")
        .build();

RetrieveAndGenerateRequest request1 = RetrieveAndGenerateRequest.builder()
        .retrieveAndGenerateConfiguration(retrieveConfig)
        .input(input)
        .build();

RetrieveAndGenerateResponse response1 = bedrockAgentRuntimeClient.retrieveAndGenerate(request1);

  Pregunta: "¿Cuáles son los patrones comunes en los tickets de error de conexión?"

  Pregunta: "¿Cómo se resolvió un caso similar la última vez?"

  Pregunta: "Resume el problema principal del ticket #12345"