AWS Bedrock AI CQRS Event Sourcing — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

AWS Bedrock AI CQRS Event Sourcing — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

ในยุคที่ระบบซอฟต์แวร์ต้องรองรับความซับซ้อน การขยายตัว และความต้องการที่เปลี่ยนแปลงอย่างรวดเร็ว สถาปัตยกรรมซอฟต์แวร์ที่ยืดหยุ่นและทรงพลังกลายเป็นสิ่งจำเป็นขั้นพื้นฐาน CQRS (Command Query Responsibility Segregation) และ Event Sourcing เป็นสองรูปแบบสถาปัตยกรรมที่ได้รับความนิยมอย่างสูงสำหรับการสร้างระบบที่ตอบสนองต่อการเปลี่ยนแปลงได้ดี แต่วิธีการนำไปปฏิบัติให้มีประสิทธิภาพ โดยเฉพาะในโลกของ Cloud Native และ AI นั้นยังเป็นความท้าทาย

นี่คือจุดที่ AWS Bedrock ก้าวเข้ามาเปลี่ยนเกม บริการ AI Foundational Model แบบ Managed นี้ ไม่เพียงแต่ให้ความสามารถด้าน Generative AI และ Large Language Models (LLMs) เท่านั้น แต่ยังสามารถผสานเข้ากับสถาปัตยกรรม CQRS และ Event Sourcing ได้อย่างลงตัว เพื่อสร้างระบบอัจฉริยะที่สามารถ “เข้าใจ” และ “ประมวลผล” ข้อมูลในรูปแบบเหตุการณ์ (Events) ได้อย่างมีประสิทธิภาพ คู่มือฉบับสมบูรณ์นี้จะพาคุณสำรวจแนวคิด การออกแบบ และการนำ AWS Bedrock มาสร้างระบบ CQRS Event Sourcing แบบ Next-Generation พร้อมตัวอย่างโค้ดและกรณีศึกษาในปี 2026

ทำความเข้าใจพื้นฐาน: CQRS และ Event Sourcing คืออะไร?

ก่อนที่จะดำดิ่งสู่การผสานกับ AWS Bedrock เรามาทบทวนแนวคิดหลักของสถาปัตยกรรมทั้งสองนี้กันก่อน

CQRS (Command Query Responsibility Segregation)

CQRS คือรูปแบบการออกแบบที่แยกโมเดลสำหรับการดำเนินการ (Command) และการอ่านข้อมูล (Query) ออกจากกันโดยสิ้นเชิง

• Command Side: รับผิดชอบการเปลี่ยนแปลงสถานะของระบบ (Write) เช่น การสร้างออร์เดอร์ใหม่, อัพเดทข้อมูลลูกค้า Commands จะตรวจสอบความถูกต้องและสร้าง Events ออกมา
• Query Side: รับผิดชอบการแสดงผลข้อมูล (Read) โดยเฉพาะ โดยมักจะอ่านจาก View Model หรือ Materialized View ที่ออกแบบมาเพื่อการแสดงผลโดยตรง ทำให้การ Query รวดเร็วและมีประสิทธิภาพ

การแยกนี้ช่วยให้แต่ละฝั่งสามารถปรับขนาด (Scale) ได้อย่างอิสระ และเลือกเทคโนโลยีที่เหมาะสมที่สุดกับงาน เช่น ใช้ DynamoDB สำหรับ Command และ Amazon Aurora หรือ Elasticsearch สำหรับ Query

Event Sourcing

Event Sourcing เป็นรูปแบบการเก็บสถานะของระบบไม่ใช่ในรูปแบบของสถานะปัจจุบัน (Current State) แต่เป็นลำดับของเหตุการณ์ (Events) ที่เกิดขึ้นทั้งหมด

• ทุกการเปลี่ยนแปลงในระบบถูกบันทึกเป็น Event Object ที่เปลี่ยนแปลงไม่ได้ (Immutable)
• สถานะปัจจุบันของ Entity ใดๆ สามารถคำนวณได้ใหม่เสมอโดยการ “เล่นซ้ำ” (Replay) เหตุการณ์ทั้งหมดตั้งแต่เริ่มต้น
• Event Store ทำหน้าที่เป็นแหล่งข้อมูลหลัก (Source of Truth) ของระบบ

เมื่อรวม CQRS + Event Sourcing เข้าด้วยกัน เราจะได้ระบบที่ Command Side สร้าง Events ไปเก็บใน Event Store จากนั้น Query Side จะรับ Events เหล่านั้นมาสร้าง Materialized View สำหรับการอ่าน ซึ่งเป็นสถาปัตยกรรมที่แข็งแกร่งและเหมาะสำหรับระบบที่มีความซับซ้อนทางธุรกิจสูง

บทบาทของ AWS Bedrock ในสถาปัตยกรรม CQRS Event Sourcing

AWS Bedrock เป็นบริการ Managed ที่ให้คุณเข้าถึงโมเดลพื้นฐาน (FMs) จากบริษัทชั้นนำเช่น Anthropic (Claude), Meta (Llama), Amazon (Titan) และ AI21 Labs ผ่าน API เดียว ความสามารถหลักไม่ได้อยู่ที่การสร้างข้อความหรือภาพเท่านั้น แต่คือการทำให้ AI เข้าใจและสร้างโครงสร้างข้อมูล (Structured Data) ได้ ซึ่งเป็นหัวใจสำคัญสำหรับการทำงานกับ Events

1. การวิเคราะห์และประมวลผล Events แบบอัจฉริยะ (Intelligent Event Processing)

Events ที่เกิดขึ้นในระบบมักเป็นข้อมูลดิบที่มีโครงสร้าง (JSON) Bedrock สามารถทำหน้าที่เป็น “Event Interpreter” เพื่อวิเคราะห์ Events เหล่านี้ในเชิงลึก

• Event Enrichment: เพิ่มข้อมูลบริบท (Context) ให้กับ Event ดิบ เช่น จาก Event “ProductAddedToCart” ที่มีแค่ productId และ userId, Bedrock สามารถเรียกข้อมูลเพิ่มจากแหล่งอื่นและสรุปเป็น Event ที่สมบูรณ์กว่าได้
• Event Classification & Routing: ใช้ Bedrock เพื่อจำแนกประเภท Event และกำหนดเส้นทาง (Route) ไปยัง Handler ที่เหมาะสมโดยอัตโนมัติ โดยเรียนรู้จากรูปแบบในอดีต
• Anomaly Detection in Event Stream: ตรวจจับเหตุการณ์ผิดปกติหรือพฤติกรรมที่น่าสงสัยในสตรีมของ Events แบบเรียลไทม์

2. การสร้าง Dynamic Materialized View และ Projections

Query Side ของ CQRS ต้องสร้าง View ที่เหมาะกับผู้ใช้ Bedrock ช่วยให้การสร้าง View เหล่านี้มีความยืดหยุ่นและอัจฉริยะขึ้น

• Personalized Views: สร้าง Materialized View ที่ปรับแต่งเฉพาะสำหรับผู้ใช้แต่ละคน โดยใช้ Bedrock ทำความเข้าใจความต้องการและพฤติกรรมของผู้ใช้จากประวัติ Events
• Natural Language to Query: อนุญาตให้ผู้ใช้ Query ข้อมูลผ่านภาษาธรรมชาติ (เช่น “แสดงยอดขายของผลิตภัณฑ์ X ในไตรมาสที่ผ่านมา ที่มีปัญหาการจัดส่ง”) และใช้ Bedrock แปลงเป็น Query ที่เหมาะสมสำหรับ View นั้นๆ

3. การสร้าง Commands และ Events จากภาษาธรรมชาติ

Bedrock สามารถทำหน้าที่เป็น Interface ระหว่างมนุษย์และระบบ CQRS ที่ซับซ้อน

• ผู้ใช้สามารถพูดหรือพิมพ์คำขอเป็นภาษาธรรมชาติ เช่น “ยกเลิกออร์เดอร์หมายเลข 12345 เพราะลูกค้าย้ายที่อยู่”
• Bedrock จะทำความเข้าใจความตั้งใจ (Intent) แยกแยะ Entities และพารามิเตอร์ แล้วสร้างโครงสร้าง Command Object (เช่น CancelOrderCommand) ที่ถูกต้องพร้อมเหตุผล (Reason) ให้ระบบดำเนินการต่อ
• ในทางกลับกัน ระบบสามารถใช้ Bedrock เพื่อสร้างสรุปเหตุการณ์ (Event Summary) จากลำดับ Events ที่ซับซ้อนให้มนุษย์เข้าใจได้ง่าย

ออกแบบระบบ: Reference Architecture บน AWS

มาดูตัวอย่างการออกแบบระบบ CQRS Event Sourcing ที่ผสาน AWS Bedrock และบริการ AWS อื่นๆ

ภาพรวมสถาปัตยกรรม (High-Level Architecture)

• Command Ingestion: API Gateway + AWS Lambda (Command Handler) รับ Commands จาก Client
• Event Store & Command Processing: Lambda ตรวจสอบความถูกต้องและบันทึก Event ลงใน Amazon DynamoDB (ใช้เป็น Event Store) ผ่าน Stream
• AWS Bedrock Integration Layer: Lambda Function ที่ถูกเรียกโดย DynamoDB Stream เพื่อส่ง Events ไปประมวลผลกับ Bedrock สำหรับการ Enrich, Classify หรือ Detect Anomaly
• Event Streaming & Processing: Events ที่ผ่านการประมวลผลแล้วจะถูกส่งต่อไปยัง Amazon EventBridge สำหรับการ Route และ AWS Step Functions สำหรับ Workflow ที่ซับซ้อน
• Projections & Query Side: Lambda (Projection Handlers) รับ Events จาก EventBridge เพื่ออัพเดท Materialized View ใน Amazon Aurora PostgreSQL หรือ Amazon OpenSearch Service
• Intelligent Query Interface: API Gateway + Lambda ที่ใช้ Bedrock เพื่อแปลงคำขอภาษาธรรมชาติเป็น Query ไปยัง Materialized View

ตัวอย่างโค้ด: Command Handler และการบันทึก Event

ส่วนต่อไปนี้แสดงตัวอย่างการเขียน Command Handler ด้วย AWS Lambda ที่รับ Command, ตรวจสอบความถูกต้อง และสร้าง Event ลงใน DynamoDB Event Store

import boto3
import json
import uuid
from datetime import datetime
from botocore.exceptions import ClientError

dynamodb = boto3.resource('dynamodb')
event_store = dynamodb.Table('EventStore')

def lambda_handler(event, context):
    """Lambda handler สำหรับประมวลผล PlaceOrderCommand"""
    
    command = json.loads(event['body'])
    command_type = command['commandType']
    
    if command_type != 'PlaceOrder':
        return {'statusCode': 400, 'body': 'Invalid command type'}
    
    # 1. ตรวจสอบความถูกต้องของ Command (สามารถเรียก Bedrock เพื่อตรวจสอบเชิงความหมายได้)
    if not is_valid_order(command['payload']):
        return {'statusCode': 400, 'body': 'Invalid order data'}
    
    # 2. สร้าง Event จาก Command
    order_id = str(uuid.uuid4())
    order_placed_event = {
        'eventId': str(uuid.uuid4()),
        'aggregateId': order_id, # ID ของ Aggregate Root (Order)
        'eventType': 'OrderPlaced',
        'payload': {
            'orderId': order_id,
            'customerId': command['payload']['customerId'],
            'items': command['payload']['items'],
            'totalAmount': command['payload']['totalAmount'],
            'shippingAddress': command['payload']['shippingAddress']
        },
        'metadata': {
            'timestamp': datetime.utcnow().isoformat(),
            'commandId': command['commandId'],
            'userId': command['userId']
        },
        'version': 1
    }
    
    # 3. บันทึก Event ลงใน Event Store (DynamoDB)
    try:
        event_store.put_item(Item=order_placed_event)
        
        # 4. (Optional) ส่ง Event ไปยัง EventBridge สำหรับการประมวลผลต่อไป
        eventbridge = boto3.client('events')
        eventbridge.put_events(
            Entries=[
                {
                    'Source': 'order.service',
                    'DetailType': 'OrderPlaced',
                    'Detail': json.dumps(order_placed_event),
                    'EventBusName': 'default'
                }
            ]
        )
        
        return {
            'statusCode': 201,
            'body': json.dumps({
                'orderId': order_id,
                'message': 'Order placed successfully',
                'eventId': order_placed_event['eventId']
            })
        }
    except ClientError as e:
        print(f"Error saving event: {e}")
        return {'statusCode': 500, 'body': 'Failed to process order'}

def is_valid_order(payload):
    """ฟังก์ชันตรวจสอบความถูกต้องเบื้องต้น"""
    # ในโลกจริงอาจใช้ Bedrock ในการตรวจสอบความสมเหตุสมผลของข้อมูล
    required_fields = ['customerId', 'items', 'totalAmount']
    return all(field in payload for field in required_fields) and len(payload['items']) > 0

ตัวอย่างโค้ด: การใช้ AWS Bedrock เพื่อ Enrich Event

Lambda Function นี้ถูก trigger โดย DynamoDB Stream เมื่อมี Event ใหม่เกิดขึ้น และใช้ Bedrock เพื่อเพิ่มข้อมูลบริบทให้กับ Event

import boto3
import json
import os

bedrock = boto3.client(service_name='bedrock-runtime')
dynamodb = boto3.resource('dynamodb')
enriched_event_store = dynamodb.Table('EnrichedEventStore')

def lambda_handler(event, context):
    """ประมวลผล Events จาก DynamoDB Stream และใช้ Bedrock Enrich ข้อมูล"""
    
    for record in event['Records']:
        if record['eventName'] == 'INSERT':
            new_event = record['dynamodb']['NewImage']
            
            # แปลง DynamoDB format เป็น JSON ปกติ
            event_data = unmarshal_dynamodb_item(new_event)
            
            # เตรียม Prompt สำหรับ Bedrock เพื่อวิเคราะห์และ Enrich Event
            prompt = f"""
            คุณเป็นระบบวิเคราะห์ Event สำหรับระบบ E-Commerce
            Event ที่ได้รับคือ: {json.dumps(event_data, ensure_ascii=False)}
            
            โปรดวิเคราะห์ Event นี้และเพิ่มข้อมูลต่อไปนี้หากทำได้:
            1. หมวดหมู่ของผลิตภัณฑ์หลักในออร์เดอร์ (ถ้าเป็น Event OrderPlaced)
            2. ระดับความเร่งด่วนของการจัดส่ง (ปกติ, ด่วน) จากที่อยู่และประเภทสินค้า
            3. ข้อความสรุปเหตุการณ์ที่เป็นมิตรต่อมนุษย์ (Human-Friendly Summary)
            
            ตอบกลับในรูปแบบ JSON เท่านั้น ตามโครงสร้างนี้:
            {{
                "eventId": "{event_data['eventId']}",
                "enrichedData": {{
                    "primaryCategory": "...",
                    "deliveryUrgency": "...",
                    "humanSummary": "..."
                }}
            }}
            """
            
            # เรียกใช้ Bedrock (ใช้ Claude model)
            try:
                response = bedrock.invoke_model(
                    modelId='anthropic.claude-3-sonnet-20240229-v1:0',
                    contentType='application/json',
                    accept='application/json',
                    body=json.dumps({
                        "anthropic_version": "bedrock-2023-05-31",
                        "max_tokens": 1000,
                        "messages": [{
                            "role": "user",
                            "content": prompt
                        }]
                    })
                )
                
                response_body = json.loads(response['body'].read())
                enrichment_result = json.loads(response_body['content'][0]['text'])
                
                # ผสานข้อมูลเดิมกับข้อมูลที่ Enrich แล้ว
                event_data['enriched'] = enrichment_result['enrichedData']
                event_data['isEnriched'] = True
                
                # บันทึกลงใน Enriched Event Store
                enriched_event_store.put_item(Item=event_data)
                
                print(f"Event {event_data['eventId']} enriched successfully.")
                
            except Exception as e:
                print(f"Error invoking Bedrock for event {event_data.get('eventId')}: {e}")
                # Fallback: บันทึก Event เดิมโดยไม่มี enriched data
                event_data['isEnriched'] = False
                enriched_event_store.put_item(Item=event_data)

def unmarshal_dynamodb_item(item):
    """แปลง DynamoDB Item format เป็น Python dictionary"""
    result = {}
    for key, val in item.items():
        if 'S' in val:
            result[key] = val['S']
        elif 'N' in val:
            result[key] = int(val['N']) if '.' not in val['N'] else float(val['N'])
        elif 'BOOL' in val:
            result[key] = val['BOOL']
        elif 'M' in val:
            result[key] = unmarshal_dynamodb_item(val['M'])
        elif 'L' in val:
            result[key] = [unmarshal_dynamodb_item(v) for v in val['L']]
    return result

การเปรียบเทียบ: แนวทางดั้งเดิม vs แนวทางที่ใช้ AWS Bedrock

ตารางต่อไปนี้สรุปความแตกต่างระหว่างการนำ CQRS Event Sourcing แบบดั้งเดิมกับการผสาน AWS Bedrock

Best Practices และข้อควรระวังสำหรับการใช้งานใน Production

การนำ AWS Bedrock มาใช้กับระบบที่สำคัญต้องคำนึงถึงแนวทางปฏิบัติที่ดีดังนี้

1. การออกแบบ Prompt ที่มีประสิทธิภาพและปลอดภัย

• ใช้ Structured Output: กำหนดรูปแบบการตอบกลับของ Bedrock ให้เป็น JSON หรือโครงสร้างที่ชัดเจนเสมอ เพื่อให้ระบบนำไปประมวลผลต่อได้โดยอัตโนมัติ
• Context Isolation: จำกัดบริบทของ Prompt เฉพาะข้อมูลที่จำเป็นสำหรับงานนั้นๆ เพื่อป้องกัน Data Leakage และลดความสับสนของโมเดล
• Prompt Versioning: บันทึกและควบคุมเวอร์ชันของ Prompt เหมือนกับโค้ดแอปพลิเคชัน ใช้ระบบเช่น AWS AppConfig หรือ Parameter Store ในการจัดการ

2. การจัดการความเสถียรและต้นทุนของ Bedrock

• Implement Retry & Fallback Logic: Bedrock API อาจมี Latency หรือข้อผิดพลาดชั่วคราว ต้องมีกลไก Retry ที่เหมาะสมและ Fallback Logic (เช่น ใช้กฎดั้งเดิม) เมื่อ Bedrock ล้มเหลว
• Cache Responses: หากมีคำขอที่คล้ายกันซ้ำๆ (เช่น การ Enrich Event ประเภทเดียวกัน) ให้พิจารณาใช้ Amazon ElastiCache เพื่อเก็บผลลัพธ์ชั่วคราวและลดต้นทุน
• Monitor Usage and Cost: ใช้ Amazon CloudWatch และ AWS Cost Explorer เพื่อติดตามการเรียกใช้ Bedrock แบบเรียลไทม์ ตั้งค่า Budgets และ Alarms เพื่อควบคุมต้นทุน

3. การรักษาความสอดคล้องของข้อมูล (Data Consistency)

• Idempotency is Key: ตรวจสอบให้แน่ใจว่าการประมวลผลด้วย Bedrock เป็นแบบ Idempotent (ทำงานซ้ำได้ผลลัพธ์เดิม) โดยใช้ Event ID หรือ Deduplication ID
• Event Sourcing as Source of Truth: ข้อมูลที่ได้จาก Bedrock (เช่น enriched data) ควรถูกเก็บเป็นส่วนเสริมของ Event ดั้งเดิม ห้ามแก้ไข Event ดั้งเดิมที่บันทึกไว้แล้ว
• Replayability: ระบบต้องสามารถ Replay Events ทั้งหมดได้เสมอ โดยผลลัพธ์จากการประมวลผลด้วย Bedrock ในการ Replay ควรให้ผลสอดคล้องกัน (อาจต้องบันทึกผลลัพธ์ของ Bedrock ไว้ด้วย)

4. การทดสอบและ Monitoring

• Test with Multiple Models: ทดสอบระบบกับ Foundation Models หลายๆ ตัวบน Bedrock เพื่อเปรียบเทียบความแม่นยำ ต้นทุน และความเร็ว
• Human-in-the-Loop (HITL) for Critical Events: สำหรับ Events ที่สำคัญมากๆ (เช่น การอนุมัติเครดิตจำนวนสูง) ควรมีระบบให้มนุษย์เข้ามาตรวจสอบและยืนยันก่อน
• Log and Audit AI Decisions: บันทึก Prompt, Response และ Metadata จากการเรียกใช้ Bedrock ทุกครั้งลงใน Amazon S3 หรือ DynamoDB เพื่อใช้ในการตรวจสอบ (Audit) และ Debug ในภายหลัง

กรณีศึกษาในโลกจริง (Real-World Use Cases)

Use Case 1: ระบบการเงินและการตรวจจับการฉ้อโกง (Financial & Fraud Detection System)

ปัญหา: ระบบธนาคารต้องการตรวจจับการทำธุรกรรมที่น่าสงสัยแบบเรียลไทม์จาก Events หลายล้านเหตุการณ์ต่อวัน โดยรูปแบบการฉ้อโกงเปลี่ยนแปลงตลอดเวลา

โซลูชันด้วย AWS Bedrock + CQRS/ES:

• Command Side: ลูกค้าส่งคำสั่งโอนเงิน (TransferCommand) ผ่าน Mobile App
• Event: ระบบสร้าง TransferInitiatedEvent เก็บใน Event Store
• Bedrock Processing: DynamoDB Stream เรียก Lambda ที่ส่ง Event นี้พร้อมประวัติการทำธุรกรรม 30 วันที่ผ่านมาของลูกค้าไปให้ Bedrock วิเคราะห์
  • Prompt: “วิเคราะห์ว่าการโอนเงินนี้มีความเสี่ยงต่อการฉ้อโกงหรือไม่ โดยพิจารณาจากรูปแบบปกติของลูกค้า จำนวนเงิน เวลา และผู้รับใหม่”
• Result: Bedrock ส่งกลับ Risk Score และเหตุผล (เช่น “การโอนไปยังบัญชีใหม่ที่ไม่มีประวัติ + จำนวนเงินสูงผิดปกติ”)
• Action: ระบบสร้าง TransactionFlaggedEvent หรือ TransactionApprovedEvent ตาม Risk Score เพื่อให้ Fraud Analyst Team ตรวจสอบต่อไป

import boto3
import json
import logging

logger = logging.getLogger()
logger.setLevel(logging.INFO)

bedrock = boto3.client(service_name='bedrock-runtime')
# สมมติว่าเราเชื่อมต่อกับ OpenSearch Service
opensearch = boto3.client('opensearch')

def lambda_handler(event, context):
    """รับคำถามภาษาธรรมชาติและแปลงเป็น Query สำหรับ Materialized View"""
    
    user_query = event.get('queryStringParameters', {}).get('q', '')
    
    if not user_query:
        return {'statusCode': 400, 'body': 'Missing query parameter "q"'}
    
    # ใช้ Bedrock แปลงภาษาธรรมชาติเป็น OpenSearch Query
    prompt = f"""
    คุณเป็นผู้ช่วยแปลงคำถามธุรกิจเป็น Query ทางเทคนิค
    เรามี Materialized View ชื่อ "customer_orders_view" ใน OpenSearch ที่มีฟิลด์ดังนี้:
    - customerId, customerName, customerSegment
    - orderId, orderDate, orderStatus, totalAmount
    - productNames (list), lastSupportContactDate
    
    คำถามจากผู้ใช้: "{user_query}"
    
    โปรดแปลงคำถามนี้เป็น query body ของ OpenSearch (ในรูปแบบ JSON) สำหรับการค้นหา
    ตอบกลับเฉพาะ JSON เท่านั้น ไม่มีคำอธิบายเพิ่มเติม
    ตัวอย่างรูปแบบ: {{"query": {{"bool": {{"must": [...]}}}}}}
    """
    
    try:
        response = bedrock.invoke_model(
            modelId='anthropic.claude-3-haiku-20240307-v1:0', # ใช้ Haiku เพราะเร็วและถูก
            contentType='application/json',
            accept='application/json',
            body=json.dumps({
                "anthropic_version": "bedrock-2023-05-31",
                "max_tokens": 500,
                "messages": [{"role": "user", "content": prompt}]
            })
        )
        
        response_body = json.loads(response['body'].read())
        query_json_str = response_body['content'][0]['text'].strip()
        
        # ทำความสะอาดข้อความที่ได้ (อาจมี backticks)
        query_json_str = query_json_str.replace('```json', '').replace('```', '').strip()
        
        opensearch_query = json.loads(query_json_str)
        
        # เรียกใช้ OpenSearch ด้วย query ที่ได้
        # ในที่นี้เป็นตัวอย่างเท่านั้น การ implement จริงจะต้องมี endpoint และ authentication
        # search_response = opensearch.search(
        #     body=opensearch_query,
        #     index='customer_orders_view'
        # )
        
        # สำหรับตัวอย่าง เราจะส่งกลับ query ที่สร้างได้
        return {
            'statusCode': 200,
            'headers': {'Content-Type': 'application/json'},
            'body': json.dumps({
                'originalQuery': user_query,
                'generatedOpenSearchQuery': opensearch_query,
                # 'results': search_response['hits']['hits']
            }, indent=2)
        }
        
    except json.JSONDecodeError as e:
        logger.error(f"Failed to parse Bedrock response as JSON: {e}. Response text: {query_json_str}")
        return {'statusCode': 500, 'body': 'Error parsing AI response'}
    except Exception as e:
        logger.error(f"Error in processing query: {e}")
        return {'statusCode': 500, 'body': 'Internal server error'}