项目实训博客记录1

张

张建站

2026/4/6 1:14:56

10分钟阅读

这个记录记录我进行FASTAPI的基本框架的搭建。在前期调研中我重点参考了现有聊天机器人、智能体系统以及主流 Web 后端项目的实现方式结合项目后续需要支持的任务路由、知识检索、结果解释与接口扩展等需求确定采用较为清晰、易维护、便于扩展的schemas-service-repositories-api分层架构。这一架构能够较好地实现数据定义、业务逻辑、数据访问与接口暴露之间的职责分离为后续功能迭代和模块扩展奠定基础。具体而言Schemas 层主要负责定义系统中各类请求与响应的数据结构基于统一的数据模型约束接口输入输出格式。一方面可以提升接口交互的规范性与可读性另一方面也便于后续与前端、模型服务以及外部系统进行标准化对接。API 层负责对外提供直接访问入口将系统功能以清晰的接口形式暴露出来承担请求接收、参数传递与结果返回的职责是系统服务能力的外部承载层。Service 层负责实现核心业务逻辑是当前框架中的关键部分。其主要作用是承接 API 层传入的请求并进一步完成任务解析、流程编排、模型调用、知识检索和结果组织等具体服务逻辑。Repositories 层则主要面向数据访问与持久化操作用于隔离底层数据库、知识库或其他存储资源的具体访问细节。虽然当前阶段重点仍在框架搭建与接口组织上但预留这一层有助于后续数据库接入、向量检索与知识图谱访问能力的平滑扩展。通过这种分层设计系统在工程上能够形成较好的高内聚、低耦合结构上层接口调用不直接依赖底层实现业务逻辑可以独立演进数据模型也能保持统一。这不仅符合当前主流后端服务开发的组织思路也较适合本项目中多任务、多模块协同的智能平台建设需求。在确定系统整体采用该分层架构后为了降低人工搭建基础代码框架所带来的重复性工作量、提升初期开发效率我进一步引入了 AI 辅助开发工具来协助完成基础项目结构的生成与初始化搭建。为了保证生成代码的规范性、准确性与可用性需要围绕项目实际需求对提示词进行严格、细致且具有工程约束性的设计。其中针对schemas部分我设计的提示词如下我要做一个基于大模型的 RNA 智能分析平台后端使用 FastAPI。请你先生成 schemas 层代码。这个平台不是单一问答接口而是一个带有路由、知识检索、任务执行和解释生成的聊天式入口。请你1. 使用 Pydantic 定义 request/response2. 为 chat、router、knowledge、explain、session 分别定义模型3. router 输出中要体现 LLM 路由的可解释性比如 raw_output、fallback、error4. 聊天结果中要把 route_result、parsed_result、task_result、knowledge_result、explanation 等都保留下来5. 再定义几个具体 AI 任务的 schema包括 RNA 修饰预测、序列分类、结构预测、motif 分析6. 代码尽量体现后续可接大模型与特化模型的扩展能力可以看到基本的字段都已经健全。在写好schemas后由于缺少必要的service所以我们先需要进行service部分的实现首先为了实现如果聊天机器人般进行对话并且可以根据对话来自动调取相应功能需要一个任务分类的功能。因此首先先设计一个可以为任务进行分类的函数def route_message_rule_based(message: str) - Dict[str, Any]: 规则兜底版路由 text message.lower() if any(x in message for x in [什么是, 区别, 介绍, 定义, 原理]): return { task_type: knowledge_qa, need_sequence: False, need_knowledge_retrieval: True, need_result_explanation: False } if any(x in text for x in [m7g, m6a, psi]) or 修饰 in message: return { task_type: modification_prediction, need_sequence: True, need_knowledge_retrieval: False, need_result_explanation: True } if 家族 in message or 类型 in message: return { task_type: classification, need_sequence: True, need_knowledge_retrieval: False, need_result_explanation: True } if 二级结构 in message or 结构 in message: return { task_type: structure_prediction, need_sequence: True, need_knowledge_retrieval: False, need_result_explanation: True } if motif in text or 基序 in message: return { task_type: motif_analysis, need_sequence: True, need_knowledge_retrieval: False, need_result_explanation: True } if any(x in message for x in [为什么, 解释一下, 说明一下, 这个结果]): return { task_type: result_explanation, need_sequence: False, need_knowledge_retrieval: False, need_result_explanation: True } return DEFAULT_ROUTE_RESULT.copy()task_type用于标识当前用户请求所属的任务类型need_sequence用于指示当前任务是否需要输入 RNA sequenceneed_knowledge_retrieval用于指示当前任务是否需要结合向量数据库进行知识检索与辅助增强need_result_explanation用于指示当前任务在完成分析后是否还需要调用大模型生成结果解释。但在这一阶段任务判断方式仍然具有较强的僵化性。系统主要依赖预先设定的固定字段进行模式识别因此聊天机器人只能在有限的任务范围内完成判断难以对更复杂、更灵活的用户表达进行准确识别。为提升任务路由的适应能力可以进一步引入大模型 API并结合提示词工程实现更加灵活的任务分类从而增强系统对自然语言语义和用户真实意图的理解能力。ROUTER_SYSTEM_PROMPT 你是RNA智能分析平台的任务路由器。请根据用户输入和历史对话判断当前请求属于哪种任务并返回严格JSON。可选任务类型 1. knowledge_qa 2. modification_prediction 3. classification 4. structure_prediction 5. motif_analysis 6. result_explanation 7. general_chat 字段说明 - task_type: 任务类型 - need_sequence: 是否需要RNA序列输入 - need_knowledge_retrieval: 是否需要知识检索 - need_result_explanation: 是否需要结果解释输出格式 { task_type: knowledge_qa, need_sequence: false, need_knowledge_retrieval: true, need_result_explanation: false } 要求 1. 只输出JSON 2. 不要输出任何额外解释 3. 不要使用Markdown代码块根据上面的代码实现思路在提示词设计时可以保持与原有路由逻辑一致的判定框架将原先基于if语句对message内容进行的条件判断整理并抽象为提示词中的可选任务类型列表同时将原来各分支return的字段结构进一步统一为模型输出的格式规范。在加上一定的言语提示与格式规范后就能够将原本依赖规则匹配的任务路由方式转化为基于大模型语义理解的结构化任务分类提示词设计。应用API代码如下通过OpenAI库与通义千问大模型API即可实现简单调用。from openai import OpenAI from app.core.config import DASHSCOPE_API_KEY, LLM_BASE_URL, LLM_MODEL_NAME client OpenAI( api_keyDASHSCOPE_API_KEY, base_urlLLM_BASE_URL ) def call_llm(messages, modelLLM_MODEL_NAME, temperature0): resp client.chat.completions.create( modelmodel, messagesmessages, temperaturetemperature ) return resp.choices[0].message.content.strip()在提示词设计与 API 调用接口均已完备的情况下还需要进一步考虑一个关键问题即大模型生成的 JSON 结果是否能够始终保持完全可靠。对此答案显然是否定的。尽管通过提示词约束可以在一定程度上提升输出格式的规范性但大模型仍然可能出现字段缺失、类型错误、格式不合法甚至返回非标准 JSON 的情况。若不对这些输出结果进行额外校验就可能直接影响后续程序的解析与系统整体运行稳定性。因此在实际实现中必须对大模型生成的 JSON 结果增加模式检查与规范化处理对其结构、字段类型以及取值合法性进行验证并在必要时进行修正或兜底回退。这样可以有效避免由于 JSON 格式错误或内容异常而导致的系统运行中断从而提升整个平台的鲁棒性与可靠性。def validate_route_result(route_result: Dict[str, Any], message: str) - Dict[str, Any]: 对 LLM 路由结果做结构校验和基础语义修正 if not isinstance(route_result, dict): raise ValueError(route_result 不是字典) route_result.setdefault(task_type, general_chat) route_result.setdefault(need_sequence, False) route_result.setdefault(need_knowledge_retrieval, False) route_result.setdefault(need_result_explanation, False) # 尝试把字符串 true/false 转成布尔 for key in [need_sequence, need_knowledge_retrieval, need_result_explanation]: coerced _coerce_bool(route_result[key]) if coerced is None: raise ValueError(f{key} 不是合法布尔值) route_result[key] coerced if route_result[task_type] not in ALLOWED_TASK_TYPES: raise ValueError(f非法 task_type: {route_result[task_type]})