浅谈 LLM RAG 对话机器人和 Text2SQL 的设计和实现
内容提要
本文介绍了大语言模型（LLM）的基本逻辑和应用场景，包括RAG对话机器人和Text2SQL。LLM应用分为开源和商业模型，商业模型效果更好。LLM模型适配可以通过预训练、微调和RAG增强上下文等方式实现。在具体业务场景中，可以通过LLM实现规章制度查询和统计数据查询等功能。在构建端到端应用时，可以使用意图识别来决定走哪个应用。在LLM项目中，需要注意提示语工程的问题、LLM的非一致性问题和预期控制。
延伸解读
Token消耗机制对成本的影响
文章指出，LLM每次生成新Token都需要将之前所有Token作为输入，因此对话中每次提问的输入Token数包含历史对话和文档内容。这意味着即使模型支持超长上下文窗口，实际使用中每轮问答的成本会随对话轮次累积增加，推理效率也可能下降。读者在设计应用时需权衡上下文长度与成本，避免盲目依赖大窗口。
RAG与微调的适用场景对比
文章对比了预训练、微调和RAG三种模型适配方式。微调虽能用少量数据注入领域知识，但信息频繁变动时需反复微调，且基础模型升级后需重新微调，增加运维复杂度。RAG则通过外挂知识库避免重新训练，更适合知识更新快的场景。作者最终选择RAG，因其在动态性和成本间取得平衡。
Text2SQL落地中的元数据与提示语工程
Text2SQL的实现依赖准确的元数据：字段需有详细注释，枚举值应明确列出，并建议按领域划分大宽表以减少JOIN。提示语工程需包含格式指定、降低幻觉、提供额外上下文等要素，且必须建立基准问题和版本管理机制。文章强调，不同LLM甚至同一模型的不同版本对提示语的响应不同，需记录对应关系并做回归测试。
LLM非确定性带来的测试挑战
LLM推理使用随机种子，导致相同输入可能产生不同输出，商业模型多不支持固定种子，使得测试无法保证下次回答一致。此外，模型升级可能引发非一致性问题，即新版本在增强某些能力时削弱原有能力。文章建议准备基准问题进行回归测试，并对模型升级持谨慎态度，避免影响已稳定运行的应用。
Q&A
LLM 的推理过程是怎样的？为什么流式输出是一个字一个字显示？
LLM 基于 Transformer 模型，通过预填充和生成两个步骤产生文本。生成时采用自回归方式，每次根据之前所有 Token 预测下一个 Token，因此流式输出会逐字显示，这反映了模型本身的工作机制。
在 LLM 应用中，预训练、微调和 RAG 增强上下文分别适用于什么场景？
预训练从头训练模型，需要海量资源，一般应用不会自行预训练；微调（如 LoRA）可用少量数据为开源模型注入领域知识，但信息频繁变动时成本高；RAG 增强上下文通过检索相关片段作为上下文，适合需要外部知识且更新频繁的场景。
如何为规章制度查询构建 RAG 对话机器人？
步骤包括：将规章制度转换为问答形式（可借助 LLM 生成）；使用向量化算法（如 BGE）将文字转为向量；构建向量数据库（如 Amazon OpenSearch）存储问答和向量；用户提问时取回最相似的预设问答作为上下文，与用户问题一起发送给 LLM 生成答案。
Text2SQL 应用中，如何提高 LLM 生成 SQL 的准确性？
关键措施包括：确保字段有详细注释，枚举字段列出可选值；简化元数据（如将 CREATE TABLE 转为简洁格式）；划分领域形成大宽表减少 JOIN；进行提示语工程，明确格式、提供元数据、降低幻觉、添加额外上下文；建立验证流程和基准问题测试。
如何让一个聊天机器人同时处理规章制度查询和统计数据查询？
可以通过意图识别来实现统一入口。预存一系列“问题→意图”映射关系，将用户问题与预存问题对比判断意图，从而决定走 FAQ 还是 Text2SQL 应用。也可以引入 LLM 进行意图判断，但会增加成本和延迟。
LLM 项目中有哪些常见风险需要注意？
主要风险包括：LLM 的非确定性导致输出不稳定；提示语泛化能力差，换说法可能失效；模型升级可能引发非一致性问题（新能力导致旧能力下降）；需控制预期，避免过度乐观。应通过基准测试、版本管理和回归测试来应对。
