做RAG的人都在交一种隐形税。向量数据库、嵌入流水线、分块逻辑、检索调优、令牌预算管理、上下文注入——教程写到200行还没看到输出。所有这套基础设施只为回答一个问题：输入内容和我的文档匹不匹配？
这不是数据库问题。是你的对象不知道自己该遵守什么规则。
大语言模型懂很多世界知识，但不懂你的定价层级、排除政策、团队上季度写的合规条款。标准做法是给每个需要接地行为的模型搭一套RAG流水线，把正确文档块检索出来塞进提示词。能跑通，但把一个10行功能变成了200行基础设施项目。
问题不在检索。问题在于你的领域对象没办法说："我创建的时候，去查一下这份文档。"
exomodel把这个变成了一行方法重写。
假设你在做提案生成器，业务规则存在markdown里：最低项目预算1万美元、定价必须含10%安全边际、不接烟草或赌博行业客户、时间估算要留两周QA缓冲。你的对象需要知道这份文档。代码是这样写的：
from exomodel import ExoModel
class Proposal(ExoModel):
client: str = ""
project_title: str = ""
budget: float = 0.0
timeline_weeks: int = 0
summary: str = ""
@classmethod
def get_rag_sources(cls):
return ["proposal_rules.md"]
集成到此结束。没有流水线，没有数据库，没有分块代码。
p = Proposal.create("为Acme Corp起草提案——云迁移项目，8周")
print(p.budget) # 45000.0（已含10%安全边际）
print(p.timeline_weeks) # 10（8周+2周QA缓冲）
对象自己应用了规则。提示词工程零行代码。
实际发生了什么？当get_rag_sources()被定义时，exomodel在内部、在调用时、无外部依赖地跑完整RAG栈：读取列出的每个文件、把内容切成重叠片段、嵌入到内存向量存储、检索与输入最相关的章节、和schema一起注入提示词。没有外部数据库，没有要配置的嵌入API，没有要管理的持久状态。索引在请求期间活在内存里。
基础设施没有消失，只是搬到了对象内部该在的地方。
对象现在知道自己不能做什么。RAG接地行为不只是正确填字段，它还强制执行约束。当你试图让它给赌博公司做5000美元提案时，它会拒绝——因为它读过规则文档，知道哪些输入该被拦下来。
这是对象层面的策略即代码。不是文档检索后靠提示词工程硬掰，是让对象在实例化时就把规则内化成行为边界。
开发者省下的不只是代码量。向量数据库选型、嵌入模型对比、分块策略调参、检索阈值优化——这些决策被压缩成一个方法里的文件路径列表。团队可以把注意力放回业务逻辑，而不是RAG基础设施的运维。
代价是每次调用都要重建索引。对于规则文档不大、调用频率不高的场景，内存重建的开销可以忽略。但如果你的策略文档是几百页的手册、每秒上千次调用，这套模式可能需要缓存层补充。
exomodel的取舍很清晰：用计算换复杂度。把分布式系统的编排问题，降级成单进程内的函数调用。对于大多数需要"让AI遵守业务规则"的场景，这个交换是划算的。
更深的问题被暴露出来：我们为什么默认RAG必须是基础设施层的事？向量数据库厂商花了三年教育市场——检索增强生成需要专用存储、需要运维、需要调优。但检索的本质是"找到相关内容"，这个操作完全可以在对象生命周期内完成，不需要持久化状态。
框架的选择重构了问题边界。当RAG从系统架构降级为类方法，很多曾经的"最佳实践"突然显得过度设计。不需要为每个模型配一套流水线，不需要在提示词里手动拼接上下文，不需要在令牌限制和检索精度之间走钢丝。
对象知道自己该遵守什么规则，这个设计直觉本该更早点出现。
热门跟贴