有可能是推理出来的也可能是计算的（大部分是计算），看是否调用了内部的算术计算能力（或外部工具）。和我最近写的文章类似的问题，越偏向底层的操作模型其实很容易出问题，应为模型大量操作以推理为主。起因是hex做BCC校验时我想用大模型试一试但给的结果和实际的不尽人意，让他做分析不如让他先写代码在用代码去执行。顺便分享下关于这个的文章https://cloud.tencent.com/developer/article/2688173?shareByChannel=link😊... 展开详请

你的业务逻辑还是还是大模型本身的逻辑？ 你的业务逻辑，需要调整业务描述。 大模型的逻辑，需要走rag 大模型底层：需要SFT... 展开详请

设计一个成功的AI系统，绝非仅仅选择一个算法模型那么简单，它是一个​​系统工程​​，核心在于构建一个​​稳定、可扩展且可持续演进的技术架构​​。其设计过程是业务目标与技术现实的深度融合。 ​​首先，明确核心设计原则：​​ ​​业务驱动​​：所有技术决策必须围绕解决具体的业务问题展开，避免“为了AI而AI”。 ​​迭代演进​​：采用MVP（最小可行产品）思路，从一个小而精的场景快速验证，再逐步扩展，而非追求一步到位的大而全系统。 ​​数据与模型分离​​：将数据处理、模型训练、模型推理视为独立的子系统，通过清晰定义的接口进行协作，实现模块化解耦，便于独立优化和迭代。 ​​其次，构建分层技术架构（经典四层）：​​ ​​数据层​​：系统的基石。负责数据的采集、清洗、标注、存储与治理。技术选型：​​Apache Kafka​​（实时数据流）、​​S3/OSS​​（原始数据存储）、​​PostgreSQL/MySQL​​（结构化业务数据）、​​Redis​​（特征缓存）、​​Milvus/Pinecone​​（向量数据库，用于 embedding 检索）。 ​​训练层​​：负责模型开发和迭代。技术选型：​​PyTorch/TensorFlow​​（深度学习框架），在 ​​Kubernetes​​ 上管理GPU训练集群，配合 ​​MLflow​​ 追踪实验、管理模型版本和参数。 ​​推理层​​：提供线上预测服务，是性能与成本的关键权衡点。技术选型：将模型封装为 ​​RESTful API​​ 或 ​​gRPC​​ 服务（使用 ​​FastAPI​​ 或 ​​Triton Inference Server​​），部署于 ​​Kubernetes​​ 以实现弹性伸缩。根据延迟和吞吐需求，选择 ​​CPU​​ 或 ​​GPU​​ 实例，并可利用 ​​OpenVINO/TensorRT​​ 对模型进行优化和加速。 ​​应用层​​：将AI能力整合到最终产品中。技术选型：通过 ​​API 网关​​（如 ​​Spring Cloud Gateway​​）统一管理对推理服务的调用，实现鉴权、限流和降级。前端通过 SDK 或 API 集成能力。 ​​最后，至关重要的技术选项与考量：​​ ​​云 vs. 本地​​：优先考虑云平台，它们提供了全托管的MLOps工具链，能极大降低运维复杂度，快速起步。 ​​模型选择​​：并非越先进越好。平衡“效果”与“成本”，优先从成熟的开源模型（如 ​​Hugging Face​​ 上的模型）微调开始，仅在必要时再考虑训练大型模型或使用商用API（如 OpenAI）。 ​​可观测性​​：必须建立完善的监控体系，追踪模型的​​业务指标​​（如推荐点击率）、​​性能指标​​（QPS、延迟）及​​数据质量​​（输入数据分布是否偏移），确保系统健康可控。... 展开详请