大模型应用的适用边界大模型擅长处理不规则文本、归纳信息和生成草稿却不天然适合承担精确计算、权限判断或不可逆操作。应用设计的关键不是扩大模型参与范围而是找准它能提升体验的位置并为不确定输出设置校验、降级和人工复核。在推进大模型项目落地时常常能遇到两种极端态度一种是觉得大模型啥都能干试图靠一段神仙 Prompt 解决所有业务难题另一种是在尝试了几次输出格式不符合预期后直接否定大模型的实用价值。这两种态度的根源在于没有在项目立项之初讲清楚 Prompt Engineering 和大模型的能力适用边界。1. 大模型能力边界的物理客观限制大语言模型的本质是基于 Transformer 架构的概率预测函数。它的擅长领域集中在语义理解、跨模态映射、非结构化文本总结与代码辅助生成。而在遇到下面这些要求“确定性与绝对精准”的工程场景时纯粹靠 Prompt 优化往往效果甚微大数值精确算术运算例如计算两个 10 位数的浮点数乘法大模型容易因为 Token 切分BPE Tokenization将数字拆碎而产生计算偏差。高时效性的精确数据库查询例如查询“截至 5 分钟前某用户的账户实时余额”模型无法感知实时外部状态强行提示只会引发严重的幻觉。极高并发与低延迟响应要求 P99 延迟低于 50ms 的实时控制流大模型的 Autoregressive 逐 Token 生成机制在物理上就无法满足要求。清楚地意识到这些限制才能在设计系统架构时少走弯路。2. 为什么精准检索与逻辑计算不能全丢给 Prompt不少开发者在设计 RAG检索增强生成系统时喜欢把全部召回的文档碎屑原封不动地拼接到 Prompt 里然后在 System Prompt 里写上“请分析上述文档找出所有 2024 年 Q3 销售额大于 500 万的用户列表”。这种做法本质上是在用算力昂贵、速度缓慢的大模型去干关系型数据库SQL最擅长的事。[错误架构] 原始文档 ➔ 拼入 Prompt ➔ 送入 LLM ➔ 靠自然语言 Prompt 过滤复杂条件 (慢、易遗漏) [正确架构] 原始数据 ➔ 关系型数据库 (SQL) / 搜索引擎 ➔ 精确过滤条件 ➔ 提取摘要送入 LLM 格式化输出大模型不擅长做大批量数据的精准过滤与聚合统计把这些工作交给 SQL 或 Python 脚本而把最后的语义整理交给 LLM才是更稳妥的工程分工。3. 混合决策管线让 Python 算子与 Prompt 各司其职在真实的工程落地中最佳方案绝不是“纯代码”或“纯 LLM”而是构建一套混合决策管线Hybrid Pipelines。下面是一个用 Python 实现的混合任务路由与执行管道。它将算术运算与精细过滤路由到本地 Python 算子处理仅将文本转换和语义加工任务交给 LLMimport re import json import logging from typing import Dict, Any, Union logging.basicConfig(levellogging.INFO) logger logging.getLogger(HybridPipeline) class HybridTaskExecutor: def __init__(self, llm_client): self.llm_client llm_client def _is_math_query(self, query: str) - bool: # 使用确定性的正则匹配识别纯数学计算表达式 pattern r^[\d\s\\-\*\/\(\)\.]$ return bool(re.match(pattern, query.strip())) def _execute_native_math(self, query: str) - Dict[str, Any]: 使用 Python 本地环境安全评估数学算术绝对不消耗 Token try: # 仅允许安全字符输入拒绝 eval 注入风险 allowed_chars set(0123456789-*/(). ) if not set(query).issubset(allowed_chars): raise ValueError(包含非法算术字符) result eval(query, {__builtins__: None}, {}) return { source: python_native_engine, success: True, result: str(result) } except Exception as e: return {source: python_native_engine, success: False, error: str(e)} def _execute_llm_semantic(self, query: str) - Dict[str, Any]: 使用大模型处理语义总结与非结构化文本加工 system_prompt You are a concise text summarizer. Return direct summary only. try: response self.llm_client.generate(systemsystem_prompt, promptquery) return { source: llm_semantic_engine, success: True, result: response.strip() } except Exception as e: return {source: llm_semantic_engine, success: False, error: str(e)} def process_request(self, user_input: str) - Dict[str, Any]: cleaned_input user_input.strip() # 1. 优先校验是否触发确定性代码边界 if self._is_math_query(cleaned_input): logger.info(路由命中有向算术算子跳过 LLM) return self._execute_native_math(cleaned_input) # 2. 否则路由至 LLM 语义处理管道 logger.info(路由命中 LLM 语义 processing 管道) return self._execute_llm_semantic(cleaned_input)这段代码的关键在于入口处的路由判断。如果请求是1258 * 34.5这样的算术计算系统直接在_execute_native_math中由 Python 毫秒级返回彻底杜绝了模型计算出错的风险同时也节省了 API 成本。4. 评估大模型落地选型时的指标对照表在评估某个业务场景是否适合引入 Prompt / 大模型时可以通过下表进行量化评估评估维度适合使用 Prompt / LLM适合使用传统工程代码输入数据类型非结构化文本、客服对话、多语言乱码格式固定的 JSON、CSV、数据库表记录逻辑规则明确度规则极其复杂且无法枚举如判别文本情感语气逻辑清晰如“满 300 减 30”、“逾期 3 天扣罚”容错率与准确率允许偶尔的语义微调与人工介入要求 100% 账实相符不允许 0.01% 的错误响应时延要求可接受 1s ~ 5s 的推演延迟要求 P99 50ms 极速响应单次处理成本预算充裕能覆盖 Token 支出必须控制在零点几分钱以内的高并发场景划清适用边界不是为了缩减 AI 的应用范围而是为了把大模型用到最能发挥其价值的地方让传统代码和大模型算法在各自的边界内高效协同。
大模型应用的适用边界大模型擅长处理不规则文本、归纳信息和生成草稿却不天然适合承担精确计算、权限判断或不可逆操作。应用设计的关键不是扩大模型参与范围而是找准它能提升体验的位置并为不确定输出设置校验、降级和人工复核。在推进大模型项目落地时常常能遇到两种极端态度一种是觉得大模型啥都能干试图靠一段神仙 Prompt 解决所有业务难题另一种是在尝试了几次输出格式不符合预期后直接否定大模型的实用价值。这两种态度的根源在于没有在项目立项之初讲清楚 Prompt Engineering 和大模型的能力适用边界。1. 大模型能力边界的物理客观限制大语言模型的本质是基于 Transformer 架构的概率预测函数。它的擅长领域集中在语义理解、跨模态映射、非结构化文本总结与代码辅助生成。而在遇到下面这些要求“确定性与绝对精准”的工程场景时纯粹靠 Prompt 优化往往效果甚微大数值精确算术运算例如计算两个 10 位数的浮点数乘法大模型容易因为 Token 切分BPE Tokenization将数字拆碎而产生计算偏差。高时效性的精确数据库查询例如查询“截至 5 分钟前某用户的账户实时余额”模型无法感知实时外部状态强行提示只会引发严重的幻觉。极高并发与低延迟响应要求 P99 延迟低于 50ms 的实时控制流大模型的 Autoregressive 逐 Token 生成机制在物理上就无法满足要求。清楚地意识到这些限制才能在设计系统架构时少走弯路。2. 为什么精准检索与逻辑计算不能全丢给 Prompt不少开发者在设计 RAG检索增强生成系统时喜欢把全部召回的文档碎屑原封不动地拼接到 Prompt 里然后在 System Prompt 里写上“请分析上述文档找出所有 2024 年 Q3 销售额大于 500 万的用户列表”。这种做法本质上是在用算力昂贵、速度缓慢的大模型去干关系型数据库SQL最擅长的事。[错误架构] 原始文档 ➔ 拼入 Prompt ➔ 送入 LLM ➔ 靠自然语言 Prompt 过滤复杂条件 (慢、易遗漏) [正确架构] 原始数据 ➔ 关系型数据库 (SQL) / 搜索引擎 ➔ 精确过滤条件 ➔ 提取摘要送入 LLM 格式化输出大模型不擅长做大批量数据的精准过滤与聚合统计把这些工作交给 SQL 或 Python 脚本而把最后的语义整理交给 LLM才是更稳妥的工程分工。3. 混合决策管线让 Python 算子与 Prompt 各司其职在真实的工程落地中最佳方案绝不是“纯代码”或“纯 LLM”而是构建一套混合决策管线Hybrid Pipelines。下面是一个用 Python 实现的混合任务路由与执行管道。它将算术运算与精细过滤路由到本地 Python 算子处理仅将文本转换和语义加工任务交给 LLMimport re import json import logging from typing import Dict, Any, Union logging.basicConfig(levellogging.INFO) logger logging.getLogger(HybridPipeline) class HybridTaskExecutor: def __init__(self, llm_client): self.llm_client llm_client def _is_math_query(self, query: str) - bool: # 使用确定性的正则匹配识别纯数学计算表达式 pattern r^[\d\s\\-\*\/\(\)\.]$ return bool(re.match(pattern, query.strip())) def _execute_native_math(self, query: str) - Dict[str, Any]: 使用 Python 本地环境安全评估数学算术绝对不消耗 Token try: # 仅允许安全字符输入拒绝 eval 注入风险 allowed_chars set(0123456789-*/(). ) if not set(query).issubset(allowed_chars): raise ValueError(包含非法算术字符) result eval(query, {__builtins__: None}, {}) return { source: python_native_engine, success: True, result: str(result) } except Exception as e: return {source: python_native_engine, success: False, error: str(e)} def _execute_llm_semantic(self, query: str) - Dict[str, Any]: 使用大模型处理语义总结与非结构化文本加工 system_prompt You are a concise text summarizer. Return direct summary only. try: response self.llm_client.generate(systemsystem_prompt, promptquery) return { source: llm_semantic_engine, success: True, result: response.strip() } except Exception as e: return {source: llm_semantic_engine, success: False, error: str(e)} def process_request(self, user_input: str) - Dict[str, Any]: cleaned_input user_input.strip() # 1. 优先校验是否触发确定性代码边界 if self._is_math_query(cleaned_input): logger.info(路由命中有向算术算子跳过 LLM) return self._execute_native_math(cleaned_input) # 2. 否则路由至 LLM 语义处理管道 logger.info(路由命中 LLM 语义 processing 管道) return self._execute_llm_semantic(cleaned_input)这段代码的关键在于入口处的路由判断。如果请求是1258 * 34.5这样的算术计算系统直接在_execute_native_math中由 Python 毫秒级返回彻底杜绝了模型计算出错的风险同时也节省了 API 成本。4. 评估大模型落地选型时的指标对照表在评估某个业务场景是否适合引入 Prompt / 大模型时可以通过下表进行量化评估评估维度适合使用 Prompt / LLM适合使用传统工程代码输入数据类型非结构化文本、客服对话、多语言乱码格式固定的 JSON、CSV、数据库表记录逻辑规则明确度规则极其复杂且无法枚举如判别文本情感语气逻辑清晰如“满 300 减 30”、“逾期 3 天扣罚”容错率与准确率允许偶尔的语义微调与人工介入要求 100% 账实相符不允许 0.01% 的错误响应时延要求可接受 1s ~ 5s 的推演延迟要求 P99 50ms 极速响应单次处理成本预算充裕能覆盖 Token 支出必须控制在零点几分钱以内的高并发场景划清适用边界不是为了缩减 AI 的应用范围而是为了把大模型用到最能发挥其价值的地方让传统代码和大模型算法在各自的边界内高效协同。
![[光学原理与应用-521]：对光的错误理解与纠偏](http://pic.xiahunao.cn/yaotu/[光学原理与应用-521]：对光的错误理解与纠偏)
