基于大模型和RAG的智能问数系统SQLBot，是一个帮助企业用户用自然语言直接查询数据库的开源工具。
下面的表格整理了它的核心功能与特点：
| 特性维度 | 具体说明 |
|---|---|
| 核心能力 | 基于大语言模型和RAG技术，将自然语言问题实时转换为精确的SQL查询语句和可视化图表。 |
| 核心目标 | 让非技术用户（如业务、运营、管理层）在没有SQL基础的情况下，能直接通过对话与数据库交互。 |
| 核心优势 | 开箱即用（配置模型与数据源即可）；易于集成到第三方系统；安全可控，支持细粒度权限管理。 |
| 技术架构 | LLM+RAG架构，利用RAG从数据库元数据中检索信息，为大模型提供上下文，以提升SQL生成的准确性。 |
| 提升准确性 | 提供四项关键的业务上下文配置功能：表管理、表关联关系管理、示例SQL、自定义术语。 |
| 最新版本 (v1.4.0) | 增强企业集成（支持LDAP/OAuth2/OIDC）、知识管理（支持术语/SQL示例批量导入导出）、智能交互（模型生成对话标题）等。 |
| 应用场景 | 业务人员自助分析、数据师快速探索数据、嵌入现有系统（如CRM/ERP）实现嵌入式分析。 |
根据开源社区的分享，部署和使用过程相对清晰：
http://<你的服务器IP>:8000/，使用默认账号（admin/SQLBot@123456）登录，建议首次登录后修改密码。完成以上配置后，就可以在问答界面直接用自然语言提问，系统会自动生成SQL、执行查询并返回结果或图表。
为了让SQLBot生成的SQL更贴合你的具体业务，官方文档特别强调了进行“业务上下文配置”的重要性。这个过程通常可以遵循以下四个步骤进行系统性的调优：
| 调优步骤 | 主要目的 | 操作示例（以CRM系统为例） |
|---|---|---|
| 1. 精简数据源 | 划定模型可访问的数据表范围，排除日志、配置等无关表的干扰。 | 在93张表中，仅保留“线索表”、“客户表”、“商机表”等核心业务表。 |
| 2. 明确表关联 | 为模型提供清晰的表连接（JOIN）关系，确保跨表查询逻辑正确。 | 手动定义线索表的organization_id字段与组织表的ID字段的关联。 |
| 3. 提供标准示例 | 针对复杂、高频的业务问题，提供“标准问题”和“标准答案SQL”，供模型参考学习。 | 为“统计东区制造业第三季度赢单总数”这类复杂查询，预先编写好正确的递归查询SQL作为示例。 |
| 4. 消除指标歧义 | 建立业务术语与数据库字段间的映射词典，统一口语化表述与专业字段名称。 | 将业务中常用的产品简称（如“JS”）映射到数据库中的全称（如“JumpServer”）。 |
1 个月前
Xiaomi-Robotics-0 预训练了大量跨身体机器人轨迹和视觉语言数据，使其能够获得广泛且可推广的动作生成知识，同时保持强大的VLM能力。
1 个月前
在2026年开发AI产品时，搭建一个生产级（production-grade）RAG系统已经不再是“简单接个向量数据库就行”，而是需要系统性工程化思维。以下是从0到1再到生产可用的完整路径，按实际优先级和踩坑顺序组织。 一、生产级RAG ≠ Demo级RAG 的本质区别（2025-2026共识） 维度 Demo级（常见教程） 生产级（真正能上线赚钱） 为什么重要 文档量 几MB ~ 几百页 几万 ~ 几百万文档 / 多模态 / 每天增量更新 决定了分块、索引、召回策略完全不同 召回准确率 60-75% 目标88-95%+（视场景） 差10%召回率，用户体验天差地别 延迟 2-8秒随便 <1.5秒（p95），理想<800ms 用户流失率与延迟呈指数关系 幻觉控制 看运气 需要多重机制把幻觉率压到<5% 企业客户最怕胡说八道 可维护性 脚本跑一遍就行 需要数据质量pipeline、版本控制、监控告警 半年后没人敢碰代码 成本 不care embedding + LLM + vectorDB 每月几千到几十万刀 直接影响商业模式能否跑通 二、2026年主流生产级RAG搭建完整路径（推荐路线） Phase 0：先别写代码，先做这两件事（很多人跳过直接失败） 明确业务成功标准（最重要一步） 准确率目标：≥88%（RAGAS faithfulness & answer relevancy） 幻觉率：<5% 响应时间：p95 < 2秒（或按产品定位） 支持的文档类型：PDF/Word/Excel/网页/Markdown/扫描件/表格/图片？ 更新频率：实时 / 每天 / 每周？ 用户问题类型：单轮 / 多轮 / 带表格 / 需要推理？ 准备评估集（金标准） 至少200-500条 真实用户问题 + 人工标注的完美答案 后续所有优化都拿这个集子打分 Phase 1：数据摄入与预处理（决定天花板，占60%工作量） 现代顺序（2025-2026主流做法）： 文档清洗与质量分级（最被低估的一步） 运行一个轻量文档质量打分模型（或规则+小型LLM） 分三类：Clean / Decent / Garbage Garbage类直接人工干预或低权重处理 结构化解析（别直接喂Unstructured） PDF：用Marker / PyMuPDF + table detection（Marker 2025年后很强） Word/Excel：python-docx / pandas 保留层级：标题 → 段落 → 表格 → 图片说明 → 元数据 高级Chunk策略（2026年最核心差异化点） 策略 Chunk大小 适用场景 召回提升 Fixed-size 512 token 快速验证 baseline Semantic 200-800 主流生产 +15-25% Hierarchical 父子chunk 长文档、合同、手册 +20-35% Proposition-based 小粒度命题 法律/医疗/技术文档 +30%+ 推荐起步组合：Semantic + 父子索引 + 100-200 token重叠 Phase 2：Embedding 与 向量存储（2026主流选型） Embedding模型推荐（2026.2月时点性价比排序）： bge-m3 / Snowflake Arctic Embed（开源王者） voyage-3-large / Cohere embed-v4（闭源但效果顶尖） text-embedding-3-large（稳定但已被超越） 向量数据库主流选择： 场景 首选数据库 次选 备注 < 100万向量 Chroma / Qdrant本地 PGVector 开发快 100万-1亿 Qdrant / Milvus Weaviate Qdrant 2025-2026口碑最佳 亿级 + 高并发 Pinecone serverless Zilliz Cloud 省心但贵 极致私有化 pgvector + pgvectorscale Milvus standalone 强烈建议：hybrid search（dense + sparse / BM25）几乎成为2026标配。 Phase 3：检索与后处理（拉开差距的关键层） 现代检索流水线（2026主流）： 用户问题 ↓ Query分类与改写（是否需要检索？多意图拆分？） ↓ 多路召回（vector + BM25 + 知识图谱等） ↓ 初筛 top-30~100 ↓ 重排序（Cohere Rerank3 / bge-reranker-v2 / flashrank） ↓ 上下文压缩 / 抽取（LLM summarize top-8） ↓ 最终给LLM的上下文（带清晰source引用） Phase 4：生成与防幻觉 Prompt工程模板（必须有）： 强制要求：只用提供的内容回答 / 不知道就说不知道 / 标注来源 结构化输出（JSON）便于下游解析 防幻觉组合拳： Self-Check / Self-RAG Corrective RAG Groundedness check（RAGAS / TruLens） 后置事实核查（小模型或规则） Phase 5：评估、监控、迭代闭环（生产级灵魂） 必须上的指标： Retrieval：Recall@K, MRR, NDCG Generation：Faithfulness, Answer Relevancy, Context Precision/Recall End-to-End：用户打分 / A/B测试 / 业务指标（解决率、CSAT） 推荐工具组合（2026主流）： 评估：RAGAS / DeepEval / TruLens / Phoenix 监控：LangSmith / Helicone / Phoenix / PromptLayer Orchestration：LangGraph / LlamaIndex Workflows / Haystack / Flowise（低代码） 三、2026年推荐最小可用生产技术栈（性价比最高） 极简但能上线（适合小团队） 解析 → Marker / LlamaParse 向量化 → bge-m3 或 voyage-3 向量库 → Qdrant (docker) 召回+重排 → Qdrant + bge-reranker-v2 框架 → LlamaIndex 或 LangGraph LLM → DeepSeek-R1 / Qwen2.5-72B-Instruct / Claude-3.5-Sonnet (根据预算) 评估 → RAGAS + 人工golden set 进阶企业级（已验证可支撑十万+文档） 加：混合检索 + 父子索引 + query分解 + 多路召回 + 上下文压缩 + corrective RAG + 在线监控 一句话总结2026年RAG哲学： “70%的效果提升来自于数据质量、切块策略和检索后处理；20%来自embedding和重排序模型；只有10%靠换个更强的LLM。” 先把前70%做好，后面自然水到渠成。 （ Grok ）
1 个月前
AI Agent 的真正智能，来自于知识获取（RAG） + 协作协议（MCP） + 执行能力（SKILLS）的统一协同，而不是单一大模型孤立输出。
1 个月前
命令优先，而非图形界面。
2 个月前
这正是当前 AI 视频生成领域最前沿的突破方向。你提出的这个问题，本质上是在问如何让 AI 从“画皮”进阶到“画骨”——即不仅画面好看，运动逻辑也要符合现实世界的物理法则。 结合最新的技术进展（如 2025 年的相关研究），要让 AI 生成符合真实规律的视频，我们可以通过以下几种“高级语言描述法”来与模型沟通： 1. 使用“力提示”技术：像导演一样指挥物理力 🎬 这是谷歌 DeepMind 等团队提出的一种非常直观的方法。你不需要懂复杂的物理公式，只需要在提示词中描述“力”的存在。 描述力的方向与强度： 你可以直接告诉 AI 视频中存在某种力。例如，不只是写“旗帜飘动”，而是写“旗帜在强风中剧烈飘动”或“气球被轻轻向上吹起”。 区分全局力与局部力： 全局力（风、重力）： 影响整个画面。例如：“Global wind force blowing from left to right”（从左到右的全局风力）。 局部力（碰撞、推力）： 影响特定点。例如：“A ball rolling after being kicked”（球被踢后滚动）。 效果： AI 模型（如 CogVideoX 结合特定模块）能理解这些力的矢量场，从而生成符合动力学的运动，比如轻的物体被吹得更远，重的物体移动缓慢。 2. 调用“思维链”与物理常识：让 LLM 当质检员 🧠 有时候直接描述很难精准，我们可以借助大型语言模型（LLM）作为“中间人”来审核物理逻辑。这种方法（如匹兹堡大学的 PhyT2V）利用 LLM 的推理能力。 分步描述（Chain-of-Thought）： 你可以在提示词中要求 AI “思考过程”。例如，不只是生成“水倒入杯子”，而是引导它：“首先，水从壶嘴流出，形成抛物线；然后，水撞击杯底，产生涟漪；最后，水位上升，流速减慢。” 明确物理规则： 在提示词中直接嵌入物理常识。例如：“根据重力加速度，球下落的速度应该越来越快”或“流体具有粘性，流动时会有拉丝效果”。 回溯修正： 如果第一版视频不符合物理规律（比如球浮在空中），你可以通过反馈指令让系统进行“回溯推理”，识别出视频与物理规则的语义不匹配，并自动修正提示词重新生成。 3. 参数化控制：像物理老师一样给定数值 📏 如果你需要极其精确的物理运动（例如做科学实验模拟或电影特效），可以使用类似普渡大学 NewtonGen 框架的思路，直接给定物理参数。 设定初始状态： 在语言描述中包含具体的物理量。 位置与速度： “一个小球从坐标 (0, 10) 以初速度 5m/s 水平抛出”。 角度与旋转： “一个陀螺以角速度 10rad/s 旋转”。 质量与材质： “一个轻质的泡沫块”与“一个沉重的铁球”在相同力作用下的反应是不同的。 指定运动类型： 明确指出是“匀速直线运动”、“抛物线运动”还是“圆周运动”。AI 会根据这些语义，调用内置的“神经物理引擎”来计算轨迹，确保视频中的物体运动轨迹符合牛顿定律。 4. 结合物理引擎的混合描述：虚实结合 🧩 更高级的方法是让语言描述直接驱动物理模拟器（如 Blender, Genesis），然后将结果渲染成视频。 描述物理属性： 在提示词中指定物体的密度、弹性系数、摩擦力等。 事件驱动描述： 描述物体间的相互作用。例如：“一个刚性的小球撞击一个柔软的布料，布料发生形变并包裹住小球”。 通用物理引擎： 像 Genesis 这样的新模型，允许你用自然语言描述复杂的物理场景（如“一滴水滑落”），它能直接生成符合流体动力学的模拟数据，而不仅仅是看起来像视频的图像帧。 📝 总结：如何写出“物理级”提示词？ 为了更直观地掌握这种描述方式，这里总结了一个对比表： 一句话总结： 要用语言描述物理运动，关键在于将“视觉结果”转化为“物理过程”。多用描述力（风、推力）、属性（重力、粘性）、参数（速度、角度）的词汇，甚至直接告诉 AI 要遵循某种物理规律，这样生成的视频才会有真实的“重量感”和“真实感”。
2 个月前
利用大语言模型（LLM）构建虚拟的“世界模型”（World Models），以此作为 KI 智能体（AI Agents）积累经验和训练的场所。 核心概念：让 LLM 成为 AI 的“模拟练习场” 目前，开发能在现实世界执行复杂任务的 AI 智能体（如机器人、自动化软件助手）面临一个巨大挑战：获取实际操作经验的成本极高且充满风险。 如果让机器人在物理世界中通过“试错”来学习，不仅效率低下，还可能造成硬件损毁。 研究人员提出的新思路是：利用已经掌握了海量人类知识的大语言模型（LLM），由它们通过文字或代码生成一个模拟的“世界模型”。 1. 什么是“世界模型”？ 世界模型是一种模拟器，它能预测特定行为可能产生的结果。 传统方式： 需要开发者手动编写复杂的代码来定义物理法则和环境规则。 LLM 驱动方式： 预训练的大模型（如 GPT-4 或 Claude）已经具备了关于世界运行逻辑的知识（例如：知道“推倒杯子水会洒”）。研究人员可以利用 LLM 自动生成这些模拟环境的逻辑。 2. 研究的具体内容 来自上海交通大学、微软研究院、普林斯顿大学和爱丁堡大学的国际研究团队对此进行了深入研究。他们测试了 LLM 在不同环境下充当模拟器的能力： 家庭模拟（Household Simulations）： 模拟洗碗、整理房间等日常任务。 电子商务网站（E-Commerce）： 模拟购物行为、库存管理等逻辑。 3. 关键发现： 强结构化环境表现更佳： 在规则清晰、逻辑严密的场景（如简单的文本游戏或特定流程）中，LLM 驱动的模拟效果非常好。 开放世界的局限性： 对于像社交媒体或复杂的购物网站这类高度开放的环境，LLM 仍需要更多的训练数据和更大的模型参数才能实现高质量的模拟。 真实观察的修正： 实验显示，如果在 LLM 模拟器中加入少量来自现实世界的真实观察数据，模拟的质量会显著提升。 对 AI 行业的意义 加速 AI 智能体进化： 这种方法让 AI 智能体可以在几秒钟内完成数千次的虚拟实验，极大加快了学习速度。 降低训练门槛： 开发者不再需要搭建昂贵的物理实验室，只需要调用 LLM 接口就能创建一个“训练场”。 2026 年的趋势： 这预示着 2026 年及以后，“自主智能体”将成为 AI 发展的核心，而这种“基于模拟的学习”将是通往通用人工智能（AGI）的关键一步。 总结 该研究证明，LLM 不仅仅是聊天机器人，它们可以演变成复杂的“数字世界创造者”。在这个虚拟世界里，新一代的 AI 智能体可以安全、低成本地反复磨练技能，最终再将学到的能力应用到现实生活和工作中。 （ 根据海外媒体编译 ）
2 个月前
MongoDB 和 PostgreSQL 都是当今最顶尖的数据库，但它们的设计哲学截然不同。没有绝对的“赢家”，只有更适合我们场景的工具。 为了帮助我们做出决定，本文将从核心差异、适用场景和决策建议三个维度为你详细拆解。 ⚔️ 核心差异速览 首先，我们需要理解它们最本质的区别： PostgreSQL (Postgres)：是关系型数据库 (SQL) 的典范。它像一个严谨的图书管理员，要求你先定义好书架（表结构），再把内容规整地放入格子中。它强调数据的强一致性、完整性和复杂的关联查询。 MongoDB：是文档型数据库 (NoSQL) 的代表。它像一个灵活的储物箱，你直接把整个“包裹”（JSON-like 文档）扔进去就行，不需要预先定义里面有什么。它强调灵活性、高吞吐量和水平扩展能力。 为了一目了然，我整理了这份对比表： 维度 PostgreSQL (SQL) MongoDB (NoSQL) 数据模型 表格结构（行和列），严格 Schema 文档结构（BSON/JSON），灵活 Schema 查询语言 标准 SQL，支持复杂的多表 JOIN MongoDB 查询语言 (MQL)，擅长单集合查询 扩展方式 主要靠垂直扩展（升级服务器配置） 天生支持水平扩展（分片，加机器） 事务支持 完整的 ACID 事务，强一致性 支持多文档 ACID 事务，但更偏向高性能 适用数据 结构化数据，数据关系复杂 半结构化/非结构化数据，数据结构多变 🧭 场景决策：什么时候选哪个？ 🅿️ 选择 PostgreSQL 的情况 如果业务场景符合以下特征，PostgreSQL 是不二之选： 需要复杂的关联查询 (JOIN) 比如电商系统，你需要把“订单表”、“用户表”、“商品表”关联起来，计算某个用户在某段时间的消费总额。PostgreSQL 的 SQL 优化器在处理这种复杂查询时比 MongoDB 强大得多。 对数据一致性要求极高 (ACID) 比如银行转账、金融交易系统。你必须确保数据的绝对准确，不能容忍“最终一致性”带来的延迟。PostgreSQL 的强一致性模型（Serializable 隔离级别）能给你最强的安全感。 数据结构相对稳定 如果业务逻辑已经很成熟，表结构很少变动，PostgreSQL 严谨的 Schema 能帮你避免很多数据错误。 地理空间数据处理 (PostGIS) 如果需要做地图相关的复杂计算（如“查找附近5公里的医院”），PostgreSQL 的 PostGIS 扩展是行业标准，功能比 MongoDB 的地理空间查询更强大。 🅼️ 选择 MongoDB 的情况 如果你的业务场景符合以下特征，MongoDB 会让你开发得更爽： 数据结构灵活多变 (Schema-less) 比如内容管理系统（CMS）或用户画像系统。不同用户可能有不同的属性，或者需求迭代非常快，今天要加个“爱好”字段，明天要加个“等级”字段。MongoDB 不需要改表结构，直接插入新字段即可，不会阻塞线上业务。 海量数据写入与高并发 比如物联网（IoT）数据、日志收集、实时分析。这些场景下数据像洪水一样涌来，且主要是插入操作。MongoDB 的分片（Sharding）机制可以让你轻松地通过增加服务器来横向扩容，扛住巨大的流量。 数据本身就是“文档”形式 比如博客文章、评论、JSON 配置文件。这些数据天然就是嵌套的结构，用 MongoDB 存储，直接就是一对一的映射，不需要像在 SQL 里那样为了存一个对象而拆分成多张表。 快速原型开发 如果是初创公司，或者在做一个新项目，业务逻辑还不确定。MongoDB 的灵活性能让你快速迭代，不用在项目初期就花大量时间设计复杂的数据库表结构。 🤝 一个有趣的趋势：界限正在模糊 值得注意的是，这两个数据库都在互相学习对方的优点： PostgreSQL 现在拥有极好的 JSONB 支持。你可以把表的一列定义为 JSONB 类型，像存文档一样存数据，甚至可以对 JSON 里面的字段建索引。这使得 Postgres 也能胜任很多 NoSQL 的场景。 MongoDB 在 4.0 版本之后引入了多文档 ACID 事务，并增强了聚合管道的能力，让它也能处理更复杂的业务逻辑。 📌 总结建议 如果是做金融、ERP、CRM 或者需要复杂报表分析，请毫不犹豫地选择 PostgreSQL。它成熟、稳健、功能强大。 如果是做社交 App、游戏、物联网、内容平台 或者需要快速迭代的初创项目，MongoDB 会让你的开发效率倍增，运维压力更小。 在实际的大型项目中，混合使用也是一种非常聪明的策略。例如：用 MongoDB 存储原始的用户行为日志（写入快、灵活），然后通过 ETL 工具清洗后存入 PostgreSQL 供运营人员做复杂的财务或业务分析（查询强、一致性强）。
3 个月前
Nova 2是亚马逊于2025年12月在re:Invent 全球大会上推出的新一代基础模型家族，共包含4款模型，均需通过Amazon Bedrock平台使用，兼顾行业领先的性价比与多场景适配性，具体介绍如下 ： 1. Nova 2 Lite： 主打快速、高性价比的日常推理任务，可处理文本、图像和视频输入并生成文本。能通过调节“思考”深度平衡智能、速度与成本，适合客服聊天机器人、文档处理等场景。在基准测试中，它对标Claude Haiku 4.5、GPT - 5 Mini等模型，多数项目表现持平或更优。 2. Nova 2 Pro（预览版）： 是该家族中智能度最高的推理模型，可处理文本、图像、视频和语音输入并生成文本。适配代理编码、长期规划等复杂任务，还能作为“教师模型”向小型模型传递能力，在与Claude Sonnet 4.5、Gemini 2.5 Pro等主流模型的对比中，多项基准测试表现出色。 3. Nova 2 Sonic： 专注端到端语音交互的模型，能实现类人化实时对话。它支持多语言与丰富音色，拥有100万token上下文窗口，可支撑长时交互，还能与Amazon Connect等语音服务、对话框架无缝集成，适配客服、AI助手等语音场景。 4. Nova 2 Omni： 业内首款统一多模态推理与生成模型，可处理文本、图像等多种输入，还能同时生成文本和图像。它能一次性处理海量多格式内容，比如数百页文档、数小时音频等，适合营销素材一站式制作等需要整合多类信息的场景。 这4款模型均具备100万token上下文窗口，且内置网页查找和代码执行能力，能保障回答的时效性与实用性 。
Minimax（海螺AI）已由大模型名Minimax替换原海螺AI。现海螺AI为Minimax视频生成产品名。
海螺AI