基于Dynamic Filtering与Amazon Bedrock解决大语言模型幻觉问题，实现可靠代码生成

1. 项目概述：当AI模型开始“偷懒”时

最近在折腾一个基于大语言模型的智能助手项目，用Python搭了个后端，准备用Docker打包部署到阿里云ECS上。项目本身不复杂，就是让模型根据用户的问题，去指定的网页抓取信息，然后基于这些信息生成结构化的数据或者代码。听起来挺美好，对吧？但实际跑起来，我遇到了一个让人哭笑不得的问题：模型它“搜完网页就脑算数字”。

具体来说，我让模型去分析一个网页上的数据表格，然后生成一段处理这些数据的Python代码。理想情况下，它应该读取网页内容，理解数据结构，然后老老实实地写一段包含正确变量和逻辑的代码。但好几次，我发现它生成的代码里，本该从网页内容里解析出来的数字，直接被它“脑补”了一个值写死了。比如网页上明明写着“库存数量: 150”，它生成的代码里却直接写inventory = 200。这就像让一个学生抄写黑板上的题目，他却自己心算了一个答案写上去，完全跳过了“读取”和“解析”的步骤。这种“偷懒”行为在需要精确、可追溯的自动化任务中是致命的，它让整个流程失去了可靠性和可解释性。

这个问题背后的核心，是大语言模型固有的“幻觉”倾向与工具调用（如网页搜索）后处理流程的脱节。模型在生成长文本时，倾向于基于其训练数据中的统计规律进行“续写”，而不是严格遵循你提供给它的上下文。当任务指令是“根据以下内容生成代码”时，模型可能只是把这个指令当作一个“主题”，然后基于它对这个主题的普遍认知去生成内容，并没有真正将提供的网页内容作为生成的唯一、强制性的依据。

为了解决这个让模型“老老实实写代码”的问题，我引入并实践了Dynamic Filtering这个技术思路。它不是某个具体的库或框架，而是一种设计模式和约束方法。其核心思想是：在模型生成内容的每一个关键步骤（尤其是涉及外部数据引用的地方），动态地、强制性地将生成内容与原始输入源（如抓取的网页文本）进行比对和过滤，确保输出严格基于输入，杜绝“脑补”。结合Amazon Bedrock这类提供了强大工具调用能力的托管服务，以及Docker容器化部署的实践，我构建了一套从开发到部署的完整解决方案。接下来，我就把这套方案的思路、踩过的坑和最终稳定的实现，详细拆解一遍。

2. 核心思路与架构设计

2.1 问题根因分析与 Dynamic Filtering 概念

为什么模型会“脑算”数字？这得从大语言模型的工作原理说起。模型本质上是一个基于海量文本训练出来的概率生成器。当你提示它“根据网页内容生成代码”时，它同时处理两件事：一是你提供的网页内容（上下文），二是它内部关于“生成代码”这个任务的庞大知识库。在生成过程中，如果模型判断从自身知识库中“回忆”出一个常见值（比如一个典型的库存数200）比从上下文中精确解析出“150”更“流畅”或概率更高，它就可能选择前者。尤其是在上下文较长或结构复杂时，模型对上下文的“注意力”可能会分散，导致它更依赖自身的“常识”。

Dynamic Filtering就是为了对抗这种倾向而设计的。它的核心不是改变模型本身，而是在模型的使用流程上增加一层“校验与修正”机制。我们可以把它理解为一个动态的、可编程的“过滤器”或“监督员”。这个监督员的工作流程是：

1. 监听：在模型生成文本的过程中，监听那些标志着“外部数据引用”的关键节点。例如，当模型生成一个变量赋值语句（如inventory =）时，这就是一个关键节点。
2. 拦截与查询：一旦监听到关键节点，立即暂停或记录模型的生成。然后，由监督员根据当前生成语境，反向去查询原始的、经过处理的输入源（网页解析后的结构化数据）。
3. 比对与注入/修正：将查询到的真实数据与模型试图生成的内容进行比对。如果一致，则放行；如果不一致，则用真实数据强制替换模型生成的内容，或者要求模型基于真实数据重新生成该部分。
4. 续写：完成修正后，让模型继续生成后续内容。

这个过程是“动态”的，因为它发生在生成过程中，而不是事后批量处理。它也是“过滤”的，因为它过滤掉了模型基于幻觉产生的内容，只允许基于证据的内容通过。

2.2 技术栈选型与整体架构

为了实现上述思路，我选择了以下技术栈，并设计了相应的架构：

• 核心模型服务与工具调用：Amazon Bedrock

  • 为什么选它？Bedrock 提供了对多种顶尖大模型（如 Claude 3, Llama 3）的托管访问，更重要的是，它原生支持Converse API 中的工具调用（Tool Use）功能。这意味着我可以将“网页抓取”定义为一个标准的工具（Tool），让模型在需要时主动调用，获取到的网页内容会以结构化的方式（如 JSON）成为模型上下文的一部分。这比传统的手动拼接网页文本到提示词（Prompt）中更规范、更可靠，减少了格式混乱导致模型误解的风险。此外，Bedrock 的按需付费和免运维特性，对于我这个个人项目来说非常合适。

• 业务逻辑与 Dynamic Filtering 实现：Python

  • 为什么是 Python？这是 AI 应用开发的事实标准。丰富的库生态（requests,beautifulsoup4,openpyxl等）可以轻松处理网页抓取、数据解析。我需要用 Python 编写主要的应用逻辑，包括：
    1. 定义 Bedrock 的工具（抓取网页）。
    2. 设计和管理与 Bedrock 模型的对话。
    3. 实现 Dynamic Filtering 的核心逻辑：解析模型生成的代码（例如使用ast模块进行抽象语法树分析），识别出数据引用点；然后与从工具调用中获取的原始数据进行映射和替换。

• 环境封装与部署：Docker

  • 为什么需要 Docker？我的应用依赖特定的 Python 版本、一系列第三方库，以及可能需要的一些系统依赖。直接在 ECS 上配置环境是一场噩梦。Docker 可以将我的应用代码、运行环境、依赖全部打包成一个独立的镜像。这个镜像在任何安装了 Docker 的机器上（包括我的本地开发机、测试机和阿里云 ECS）都能以完全相同的方式运行，彻底解决了“在我机器上好好的”这个问题。

• 部署与运行平台：阿里云 ECS

  • 为什么是 ECS？对于需要持续运行、有一定资源需求的后端服务，云服务器是最直接的选择。阿里云 ECS 提供了稳定的计算资源，我可以选择安装好 Docker 的镜像，轻松地将我的 Docker 容器运行起来。结合阿里云容器镜像服务，可以实现从代码提交到自动构建镜像再到部署的流水线。

整体架构流程如下：

1. 用户通过前端或 API 发送一个请求，例如：“分析 https://example.com/inventory 页面，生成统计库存的Python代码”。
2. Python 后端接收到请求，准备调用 Bedrock。它首先会定义好“网页抓取工具”，并将用户请求转换为 Bedrock Converse API 能理解的格式。
3. 调用 Bedrock Converse API，模型会先“思考”，发现需要网页内容，于是调用我们定义的工具。
4. Python 后端执行工具逻辑（实际去抓取和解析网页），将结果（结构化数据）返回给 Bedrock 模型。
5. 模型接收到网页数据，开始生成代码。与此同时，我们启用的 Dynamic Filtering 模块开始工作。
6. 模型每生成一段代码（或达到一个检查点），Filtering 模块就介入，检查生成的代码中是否有变量应来源于网页数据。如果是，则从步骤4获得的结构化数据中查找对应值，并确保代码中使用的是该值。
7. 模型生成完整的、经过过滤校验的代码。
8. Python 后端将最终代码返回给用户。

这个架构的关键在于第5、6步，Dynamic Filtering 作为模型生成流程中的一个“插件”或“中间件”存在，确保了输出的可靠性。

3. 核心模块实现详解

3.1 基于 Amazon Bedrock 的工具调用集成

首先，我们需要让模型具备“搜网页”的能力。这里不采用简单的将网页文本塞进 Prompt 的做法，而是使用 Bedrock 的 Tool Use 功能。

步骤一：安装 SDK 与配置认证

pip install boto3

在代码中，配置 AWS 认证（通常通过环境变量AWS_ACCESS_KEY_ID,AWS_SECRET_ACCESS_KEY，以及AWS_REGION）。

import boto3 import json bedrock_runtime = boto3.client( service_name='bedrock-runtime', region_name='us-east-1' # 替换为你的区域 )

步骤二：定义网页抓取工具我们需要按照 Bedrock Tool Use 的规范，定义一个工具模式（Tool Schema）。这个模式告诉模型：有一个叫fetch_webpage的工具，它需要一个url参数，调用后会返回网页的标题和主要内容。

# 定义工具 tools_config = [ { "toolSpec": { "name": "fetch_webpage", "description": "Fetch and extract the main content from a given URL.", "inputSchema": { "json": { "type": "object", "properties": { "url": { "type": "string", "description": "The URL of the webpage to fetch." } }, "required": ["url"] } } } } ]

步骤三：实现工具的执行函数当模型决定调用工具时，Bedrock API 的响应中会包含工具调用的请求。我们需要截获这个请求，执行真正的抓取逻辑，并将结果返回。

import requests from bs4 import BeautifulSoup def execute_tool(tool_name, tool_input): if tool_name == "fetch_webpage": url = tool_input.get("url") try: response = requests.get(url, timeout=10) response.raise_for_status() soup = BeautifulSoup(response.content, 'html.parser') # 简单的正文提取，可根据实际网页结构调整 main_content = soup.get_text(separator=' ', strip=True)[:5000] # 限制长度 title = soup.title.string if soup.title else "No Title" return { "title": title, "content": main_content } except Exception as e: return {"error": f"Failed to fetch webpage: {str(e)}"} else: return {"error": f"Unknown tool: {tool_name}"}

步骤四：发起对话并处理工具调用这是最核心的循环逻辑。我们发起一个对话，模型可能会在中间返回工具调用请求，我们需要处理它，并将结果送回给模型，让它继续。

def converse_with_model(messages, tools): """与Bedrock模型对话，处理工具调用""" response = bedrock_runtime.converse( modelId='anthropic.claude-3-sonnet-20240229-v1:0', # 示例模型ID messages=messages, toolConfig={'tools': tools} ) output_message = response['output']['message'] tool_use_requests = [] # 检查输出中是否包含工具调用请求 for content in output_message.get('content', []): if content.get('toolUse'): tool_use_requests.append(content['toolUse']) # 如果有工具调用，则执行并准备下一轮消息 if tool_use_requests: tool_results = [] for req in tool_use_requests: tool_result = execute_tool(req['name'], req['input']) tool_results.append({ "toolUseId": req['toolUseId'], "content": [{"json": tool_result}] }) # 将工具执行结果作为新的用户消息追加 messages.append(output_message) # 先追加模型的消息（包含工具请求） messages.append({ "role": "user", "content": [{"toolResult": tr} for tr in tool_results] }) # 递归调用，继续对话 return converse_with_model(messages, tools) else: # 没有工具调用，返回最终结果 return output_message # 初始化对话 initial_messages = [{ "role": "user", "content": [{"text": "请分析 https://example.com/data 页面的库存表格，并生成一段计算总库存的Python代码。"}] }] final_response = converse_with_model(initial_messages, tools_config) generated_text = "" for content in final_response.get('content', []): if 'text' in content: generated_text += content['text'] print("模型生成的原始代码：\n", generated_text)

注意：实际生产中，网页抓取工具可能需要更健壮的异常处理、反爬策略、以及更精细的内容解析（如专门解析表格）。这里是一个简化示例。另外，Bedrock的计费与Token使用量相关，工具调用的输入输出也会计入，需注意成本。

3.2 Dynamic Filtering 逻辑的设计与实现

现在，我们有了模型生成的原始代码generated_text。接下来是实现 Dynamic Filtering 的关键：确保代码里的数字来自网页，而非模型的“脑补”。

设计思路：

1. 数据提取：在执行工具fetch_webpage时，我们不仅返回文本，还要进行初步的数据结构化。例如，如果知道目标页面是库存表，我们可以用BeautifulSoup或pandas直接解析出表格，得到一个 Python 字典或列表，如{'产品A': 150, '产品B': 200}。
2. 代码解析与模式匹配：使用 Python 的ast（抽象语法树）模块解析生成的代码。我们寻找特定的模式，比如赋值语句的右值是数字字面量，且左值变量名与我们感兴趣的数据键名相关。
3. 动态替换：当找到这样一个模式时，用我们从网页中提取的真实值替换掉代码中的数字字面量。

代码实现：假设我们的网页抓取工具升级，能返回解析后的库存字典extracted_data。

import ast import re class CodeDynamicFilter: def __init__(self, extracted_data): """ extracted_data: 从网页提取的结构化数据，例如 {'inventory_a': 150, 'inventory_b': 200} """ self.data = extracted_data def filter_code(self, code_string): """对生成的代码字符串进行动态过滤""" try: tree = ast.parse(code_string) except SyntaxError as e: print(f"生成的代码有语法错误，无法过滤: {e}") return code_string # 返回原代码，或进行错误处理 # 使用自定义的访问器遍历AST filtered_tree = self._FilterVisitor(self.data).visit(tree) # 将修改后的AST转换回代码 return ast.unparse(filtered_tree) if hasattr(ast, 'unparse') else astor.to_source(filtered_tree) # 需要 astor 库 class _FilterVisitor(ast.NodeTransformer): def __init__(self, data): self.data = data def visit_Assign(self, node): """访问赋值语句，例如 `inventory = 200`""" # 只处理右值是数字常量的情况 if isinstance(node.value, ast.Constant) and isinstance(node.value.value, (int, float)): # 检查赋值目标（可能是单个变量或多个变量） for target in (node.targets if isinstance(node.targets, list) else [node.targets]): if isinstance(target, ast.Name): var_name = target.id # 尝试在提取的数据中查找匹配的变量名（这里使用简单匹配，实际可能更复杂） # 例如，变量名包含 'inventory'，且数据中有 'inventory_a'，可以尝试模糊匹配 for data_key, true_value in self.data.items(): # 简单示例：如果变量名是数据键的一部分，则替换 if var_name.lower() in data_key.lower() or data_key.lower() in var_name.lower(): print(f"[Dynamic Filter] 检测到赋值语句 `{var_name} = {node.value.value}`，从数据源替换为真实值 `{true_value}`") node.value = ast.Constant(value=true_value) break # 找到第一个匹配项就替换 return self.generic_visit(node) # 继续遍历子节点 # 使用示例 extracted_data_from_web = {'product_alpha_inventory': 150, 'product_beta_stock': 200} filter = CodeDynamicFilter(extracted_data_from_web) raw_code = """ # 计算总库存 inventory_alpha = 250 # 模型可能脑补的值 inventory_beta = 180 total = inventory_alpha + inventory_beta print(f"总库存为: {total}") """ filtered_code = filter.filter_code(raw_code) print("经过Dynamic Filtering后的代码：\n", filtered_code)

输出可能会是：

[Dynamic Filter] 检测到赋值语句 `inventory_alpha = 250`，从数据源替换为真实值 `150` [Dynamic Filter] 检测到赋值语句 `inventory_beta = 180`，从数据源替换为真实值 `200` 经过Dynamic Filtering后的代码： # 计算总库存 inventory_alpha = 150 inventory_beta = 200 total = inventory_alpha + inventory_beta print(f'总库存为: {total}')

实操心得：AST 遍历和模式匹配的规则是 Dynamic Filtering 的难点和核心。上面的例子非常基础。在实际项目中，你可能需要处理更复杂的情况：变量名与数据键的映射关系可能需要一个配置文件；数字可能不是直接赋值，而是出现在表达式里（如count = old_count + 10）；数据可能不是数字，而是字符串。你需要根据具体的任务领域来设计和强化你的NodeVisitor逻辑。一个更稳健的做法是，在提示词（Prompt）中明确要求模型使用特定的变量名，这些变量名与你数据提取的键名保持一致，从而简化过滤器的匹配逻辑。

3.3 容器化封装与本地测试

为了让应用能在任何地方一致运行，我们需要将其 Docker 化。

步骤一：编写 Dockerfile在项目根目录创建Dockerfile。

# 使用官方 Python 运行时作为父镜像 FROM python:3.9-slim # 设置工作目录 WORKDIR /app # 将当前目录内容复制到容器的 /app 下 COPY . /app # 安装系统依赖（如果需要，例如对于某些Python包） RUN apt-get update && apt-get install -y \ gcc \ && rm -rf /var/lib/apt/lists/* # 安装 Python 依赖 RUN pip install --no-cache-dir -r requirements.txt # 声明运行时容器暴露的端口（如果应用是Web服务） # EXPOSE 8080 # 定义环境变量（如AWS凭证，但强烈建议通过ECS任务定义或 secrets manager 注入，而非写死在镜像） # ENV AWS_ACCESS_KEY_ID=... # ENV AWS_SECRET_ACCESS_KEY=... # 在容器启动时运行应用 CMD ["python", "main.py"]

步骤二：创建 requirements.txt列出所有 Python 依赖。

boto3>=1.34.0 requests>=2.31.0 beautifulsoup4>=4.12.0 pandas>=2.0.0 # 如果需要表格处理 astor>=0.8.0 # 用于将AST转回代码（如果Python版本<3.9）

步骤三：构建与运行 Docker 镜像在包含Dockerfile的目录下执行：

# 构建镜像，命名为 dynamic-filter-app docker build -t dynamic-filter-app . # 运行容器，将本地当前目录挂载到容器的/app（方便开发调试），传递环境变量 docker run --rm -it \ -v $(pwd):/app \ -e AWS_ACCESS_KEY_ID=你的AK \ -e AWS_SECRET_ACCESS_KEY=你的SK \ -e AWS_REGION=us-east-1 \ dynamic-filter-app

重要警告：如上所述，将密钥直接放在命令行或 Dockerfile 中是极不安全的。这只是本地测试的快捷方式。对于生产环境，必须使用 Docker Secrets、AWS Secrets Manager 或通过 ECS 任务角色（推荐）来管理凭证。

步骤四：调试与优化在容器内运行，如果遇到类似“virtualization support not detected docker desktop failed to start”的错误，那是 Docker Desktop 本身的问题，与你的镜像无关。你需要确保主机 BIOS 中开启了虚拟化支持（Intel VT-x/AMD-V），并在 Windows 功能中开启“Hyper-V”和“Windows 虚拟机监控程序平台”。 对于应用本身的调试，可以在Docker run时使用-it参数进入交互模式，或者将日志输出到标准输出，方便查看。

4. 部署至阿里云 ECS 与生产化考量

本地测试通过后，就可以部署到云服务器了。

4.1 ECS 环境准备与 Docker 安装

1. 购买与配置 ECS：在阿里云控制台购买一台 ECS 实例。操作系统选择常见的 Linux 发行版，如 Ubuntu 22.04 或 Alibaba Cloud Linux 3。建议选择至少 2核4G 的配置，具体视应用负载而定。安全组需要开放你应用服务的端口（如果有）。
2. 登录 ECS：通过 SSH 连接到你的 ECS 实例。
3. 安装 Docker：在 ECS 上安装 Docker Engine。

   # 以 Ubuntu 为例 sudo apt-get update sudo apt-get install -y ca-certificates curl sudo install -m 0755 -d /etc/apt/keyrings sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc sudo chmod a+r /etc/apt/keyrings/docker.asc echo \ "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.asc] https://download.docker.com/linux/ubuntu \ $(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \ sudo tee /etc/apt/sources.list.d/docker.list > /dev/null sudo apt-get update sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

4. （可选）配置非 root 用户运行 Docker：为了安全，可以将当前用户加入docker组。

   sudo usermod -aG docker $USER newgrp docker # 刷新组权限，或退出重新登录

4.2 镜像推送与容器运行

我们不会直接在 ECS 上构建镜像，而是使用镜像仓库。

1. 使用阿里云容器镜像服务（ACR）：
   • 在阿里云控制台开通并创建一个容器镜像实例（个人版即可）。
   • 在实例中创建一个命名空间（如my-namespace）和一个镜像仓库（如dynamic-filter），选择本地仓库。
   • 按照控制台指引，完成 Docker 登录认证。

   # 在本地开发机执行 docker login --username=你的阿里云账号 registry.cn-hangzhou.aliyuncs.com

2. 重新标记并推送本地镜像：

   # 给本地镜像打上符合ACR格式的标签 docker tag dynamic-filter-app registry.cn-hangzhou.aliyuncs.com/my-namespace/dynamic-filter:latest # 推送到ACR docker push registry.cn-hangzhou.aliyuncs.com/my-namespace/dynamic-filter:latest

3. 在 ECS 上拉取并运行镜像：

   # 在ECS上登录ACR（同样需要先配置认证，可以使用访问凭证） sudo docker login --username=你的阿里云账号 registry.cn-hangzhou.aliyuncs.com # 拉取镜像 sudo docker pull registry.cn-hangzhou.aliyuncs.com/my-namespace/dynamic-filter:latest # 运行容器，通过环境变量文件或ECS任务定义注入敏感信息（生产环境做法） # 首先，创建一个环境变量文件（不要提交到git） # echo "AWS_ACCESS_KEY_ID=xxx" > .env # echo "AWS_SECRET_ACCESS_KEY=yyy" >> .env # 然后运行 sudo docker run --rm -d \ --name dynamic-filter-container \ --env-file .env \ -p 8080:8080 \ # 如果应用监听8080端口 registry.cn-hangzhou.aliyuncs.com/my-namespace/dynamic-filter:latest

   生产环境安全实践：绝对不要在镜像、环境变量文件或命令行中硬编码密钥。在阿里云 ECS 上，最佳实践是：

   1. 为 ECS 实例分配一个具有相应权限的RAM 角色。在实例内部，应用程序通过 SDK（如 boto3）会自动获取该角色的临时凭证，无需配置 AK/SK。
   2. 或者，将密钥存储在阿里云 Secrets Manager中，在容器启动时通过环境变量注入（ECS 任务定义支持此功能）。

4.3 生产环境优化与监控

1. 使用 Docker Compose：对于多服务或需要定义网络、卷的情况，使用docker-compose.yml管理更清晰。

   version: '3.8' services: app: image: registry.cn-hangzhou.aliyuncs.com/my-namespace/dynamic-filter:latest container_name: dynamic-filter-app restart: unless-stopped # 自动重启 environment: - AWS_REGION=us-east-1 # 其他环境变量... # 通过ECS RAM角色获取凭证，此处不设置AK/SK ports: - "8080:8080" # volumes: # - ./logs:/app/logs # 挂载日志卷

   在 ECS 上运行：sudo docker-compose up -d

2. 日志管理：确保应用将日志输出到标准输出（stdout）和标准错误（stderr），Docker 可以捕获这些日志。使用docker logs [容器名]查看。对于生产环境，可以考虑配置log-driver将日志发送到阿里云 SLS 或其他日志服务。

3. 健康检查：在 Dockerfile 或 docker-compose 中定义HEALTHCHECK，确保服务可用性。

   HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \ CMD curl -f http://localhost:8080/health || exit 1

4. 资源限制：在docker run或docker-compose中为容器设置 CPU 和内存限制，防止单个容器耗尽主机资源。

   services: app: # ... deploy: resources: limits: cpus: '1.0' memory: 1G

5. 常见问题排查与实战技巧

在实际开发和部署过程中，我遇到了不少坑。这里总结一下，希望能帮你绕过去。

5.1 Bedrock 工具调用相关

• 问题：模型不调用工具，直接开始“脑补”回答。

  • 排查：首先检查工具定义（toolSpec）的description和inputSchema是否清晰、准确。模型需要明确理解工具的作用和输入格式。其次，检查用户提示词（Prompt）。指令必须明确要求模型“使用工具获取数据”。例如，“请使用 fetch_webpage 工具获取https://... 页面的内容，然后根据内容生成代码。”比“请分析 https://... 页面并生成代码”更有效。
  • 技巧：在对话的system消息中（如果模型支持）或第一条用户消息中，明确强调“你必须使用提供的工具来获取外部信息，不得依赖内部知识进行假设”。

• 问题：工具调用返回了内容，但模型似乎没“看”到或理解错误。

  • 排查：检查工具返回的结果格式。它必须是有效的 JSON 对象，并且结构尽量简单、清晰。过长的、非结构化的文本可能会让模型难以提取关键信息。考虑在工具执行层就对网页内容进行预处理，比如只提取干净的表格数据、关键段落，而不是整个网页的杂乱文本。
  • 技巧：在工具description中说明返回值的结构。例如，“返回一个包含title(字符串) 和inventory_data(字典，产品名到数量的映射) 的 JSON 对象。”

5.2 Dynamic Filtering 实现相关

• 问题：AST 解析失败，因为生成的代码有语法错误。

  • 排查：大语言模型生成的代码偶尔会有小语法错误，比如缺少冒号、缩进混乱。这会导致ast.parse()失败。
  • 解决：在过滤前，可以增加一个简单的代码清理或语法检查步骤。对于微小的错误，可以尝试用autopep8或black格式化一下。如果错误无法自动修复，可以设计一个反馈机制，将错误信息连同原始网页数据一起，再次发送给模型，要求它修正代码。这相当于一个多轮校验。

• 问题：变量名匹配不上，过滤不生效。

  • 排查：这是最常见的问题。模型生成的变量名（如stock_level）和你从网页提取的数据键名（如inventory_quantity）可能完全不同。
  • 解决：
    1. 强化提示词：在给模型的指令中，明确规定它必须使用哪些特定的变量名。例如，“请将产品A的库存数量赋值给变量inventory_a，产品B的赋值给inventory_b。”
    2. 建立映射表：在过滤器中维护一个映射关系配置文件，将可能出现的模型变量名映射到已知的数据键名。这需要一些领域知识。
    3. 使用更智能的匹配：除了精确匹配，可以使用模糊字符串匹配（如difflib库）、或基于上下文的匹配（比如，变量名和产品名同时出现在同一行注释或附近代码中）。
    4. 后处理与验证：过滤后，可以添加一个验证步骤，检查代码中是否仍然存在“未经验证”的数字字面量，并给出警告。

• 问题：性能开销。对每一段生成的代码都进行 AST 解析和遍历，在频繁调用的场景下可能有性能影响。

  • 优化：不是所有生成内容都需要过滤。可以只在模型生成“代码块”时触发过滤逻辑。或者，采用更轻量级的正则表达式匹配特定模式（例如匹配= \d+这样的数字赋值），但正则表达式不如 AST 精确和灵活，需权衡。

5.3 Docker 与 ECS 部署相关

• 问题：Docker 构建时下载 Python 包速度慢。

  • 解决：在Dockerfile中更换 pip 源。

    RUN pip install --no-cache-dir -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple

• 问题：ECS 上容器运行失败，报错找不到 AWS 凭证。

  • 排查：这是生产环境最易出错的地方。首先，确保 ECS 实例关联的 RAM 角色拥有调用 Bedrock 的权限（如BedrockRuntimeFullAccess或自定义策略）。然后，在容器内，检查元数据服务是否可达。在 ECS 上，通常可以通过http://100.100.100.200/latest/meta-data/访问。你的 Python 代码使用的boto3客户端如果不显式提供凭证，会自动从该端点获取。
  • 验证：在 ECS 上运行一个测试容器，执行curl http://100.100.100.200/latest/meta-data/ram/security-credentials/[角色名]看能否拿到临时凭证。如果不行，检查 RAM 角色配置。

• 问题：容器内应用无法访问外网（如抓取网页）。

  • 排查：检查 ECS 实例的安全组和网络 ACL，是否放行了出方向流量。另外，确保 ECS 实例本身配置了公网 IP 或处于可以访问外网的 NAT 网关之后。

5.4 一个综合性的避坑技巧：设计验证闭环

仅仅依赖 Dynamic Filtering 可能还不够。我后来增加了一个最终验证步骤，形成了“生成-过滤-验证”的闭环：

1. 生成与过滤：得到经过 Dynamic Filtering 的代码。
2. 安全执行验证：在一个极度受限的沙箱环境（如docker run --read-only --network none启动的一个临时容器，或使用PyPy的沙箱、restrictedpython等）中，执行这段代码，并喂入我们已知的、从网页提取的测试数据。
3. 结果比对：将代码执行的结果，与我们根据原始数据手动计算（或通过一个可信的简单脚本计算）的预期结果进行比对。
4. 反馈修正：如果结果不一致，说明过滤可能失败或代码逻辑有误。将不一致的信息、原始数据和代码一起，作为新的提示反馈给模型，要求它检查和修正。

这个闭环虽然增加了复杂度，但极大地提高了最终输出结果的可靠性，让“老老实实写代码”不再是愿望，而是可验证的事实。它特别适用于生成代码后需要立即执行并依赖其结果的关键任务。