- 博客(193)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 AI的进化：从“失忆”到“过目不忘”，认知型RAG技术深度解析
认知型RAG是传统RAG的升级版，其核心逻辑是：给AI一个“会思考的大脑”。它不仅能像传统RAG那样从知识库中检索相关信息，还能对信息进行深度理解、逻辑推理、跨领域整合与动态记忆，最终生成更精准、有深度、可信赖的回答。如果说传统RAG是“只会背诵的学生”，那么认知型RAG就是“会归纳、会推理、会举一反三的学霸”。从“失忆”到“过目不忘”，从“复读机”到“思考者”，认知型RAG技术的进化本质上是AI从“工具属性”向“智慧属性”的跨越。它不仅解决了传统AI的核心痛点，更重新定义了人与机器的协作模式。
2026-01-08 10:46:53
583
原创 零基础10分钟部署MinerU：Docker Compose一键搭建指南
MinerU Docker Compose 部署核心分为三步：构建国内适配镜像、下载配置文件、按 profile 启动对应服务；不同 profile 对应不同功能模块，可根据需求选择性启动（如仅用可视化界面可只启动 gradio，需 API 调用则启动 api）；部署后可通过系列命令完成服务的启停、日志查看等运维操作，便于问题排查。通过以上步骤，你可以快速完成 MinerU 的 Docker Compose 部署，无需关注复杂的环境依赖，直接开箱即用。
2026-01-08 09:34:48
441
原创 Cognee API 完整使用文档（含分类、调用顺序、curl 示例、文件样本、一键脚本及异常码）
按核心功能模块划分，Cognee API 共分为 8 大类，各类接口的核心作用、关键参数、支持文件格式、内容样本及标准输出示例。
2025-12-31 16:30:14
734
原创 从底层原理看Cognee：如何根治通用RAG的三大核心缺陷？
Brand（品牌）→ Product（产品）→ Model（型号）→ After-Sales Policy（售后政策），并明确“苹果”在该语境下特指“苹果公司”，而非水果。# 1. 初始化本体（手机行业专属）# 2. 定义核心类（实体类型）# 3. 定义类的属性（限定实体特征）Product.add_property(Property(name="type", data_type="string", allowed_values=["手机", "平板", "配件"]))
2025-12-24 17:09:06
1133
原创 如何使用Ollama本地模型实现Cognee类似功能
本文通过整合Ollama、Streamlit、Kuzu、LanceDB等工具，成功实现了一套类似Cognee的本地知识库智能管理系统，具备文档处理、知识图谱构建、混合检索、智能问答等核心功能，且支持复合实体全程处理，满足私有化知识管理的需求。支持更多文档格式：增加对PPT、Markdown等格式文档的支持，提升文档兼容性优化检索性能：针对大数据量场景，优化LanceDB向量检索与Kuzu图查询性能，加入索引优化增强知识图谱功能：支持实体属性编辑、关系可视化展示，提升知识图谱的可操作性模型优化。
2025-12-24 11:35:06
763
原创 开源AI记忆工具Cognee深度解析：技术优势、部署实践与实测验证
Cognee通过创新的ECL架构、动态记忆更新、极简部署等核心优势，解决了传统AI应用的"失忆"痛点，92.5%的高回答相关性确保了输出精准度，同时支持多源数据兼容和灵活扩展，覆盖从独立开发者到企业级用户的全场景需求。其典型应用场景包括：智能客服：整合历史对话与企业知识库，提升问题解决率；个人助手：动态学习用户习惯，提供个性化服务；企业知识库管理：整合多格式文档，支持精准检索与统计分析；AI Agents开发：快速为智能体构建持久记忆层，降低开发成本。
2025-12-19 22:32:54
672
1
原创 保险类文档 RAG 全流程实现方案
元数据字段字段类型说明（通用化）doc_type字符串文档类型（如 “保险产品介绍”“保险条款”）issuer字符串发行机构（如 “保险公司名称”）字符串文档更新时间（如 “YYYY 年 MM 月”）数组适用地区（如 [“香港”,“澳门”]）数组支持的保单货币类型（如 [“美元”,“港元”]）core_tags数组核心检索标签（如 [“长期 IRR”,“回本周期”,“红利权益”,“退保规则”]）数组文档包含的逻辑模块（如 [“产品基础”,“收益案例”,“权益规则”,“条款约束”]）数组。
2025-12-17 15:18:47
521
原创 RAG 精准匹配破局：关键字 vs 元数据，多属性 + 特殊字符场景的实操对决
知识库：500 篇保险产品条款文档，包含 “险种代码、受保人年龄、整付保费、受保人姓氏” 等属性，部分文档含偏僻字（如 “龑姓”）、字母组合（如 “XX-B1 险种”）；用户提问示例基础款：“0 岁男性整付保费 50,000 美元，XX-B1 险种的预期总回本期是多少年？复杂款：“受保人為龑姓，30 岁女性投保 XX-C3 险种，年缴保费 20,000 美元，回本周期多久？核心评估指标。
2025-12-16 11:18:29
543
原创 文本分块技术选型指南：字符分块、语义分块与按页分块的深度对比
文本分块的本质是 “平衡信息粒度与处理可行性”—— 过细的分块会导致上下文断裂，过粗的分块则可能超出模型处理能力或包含无关信息。文本分块技术的选型核心是 “匹配业务需求与文本特性”：字符分块是 “效率优先” 的折中选择，适合大规模、结构化弱的文本处理；语义分块是 “语义优先” 的精准选择，适合需要深度分析的非结构化文本；按页分块是 “结构优先” 的简化选择，仅适用于页面独立的特殊文档。
2025-12-12 17:35:23
785
原创 极速部署VibeVoice：实时语音交互模型从0到1实战指南
VibeVoice部署核心依赖NVIDIA GPU和官方PyTorch容器，--gpus all参数是GPU调用的关键，缺一不可；部署流程分为容器启动、源码克隆安装、Demo运行三步，核心命令可直接复用；模型下载慢、显存不足是常见问题，可通过镜像源和量化策略解决，低显存GPU需适配更小量级模型。通过以上步骤，开发者可在10分钟内完成VibeVoice的部署与运行，快速体验实时语音交互的效果。后续可基于源码二次开发，适配智能客服、语音助手等实际业务场景。
2025-12-10 15:01:05
830
1
原创 OCR TXT文档语义分块技术实现
本文档详细阐述面向OCR输出TXT文件的语义分块实现方案，核心目标是将无结构化、存在乱码/格式不规范的OCR文本，按照语义连贯性和Token长度约束拆分为高质量文本块（Chunk），同时具备完整的性能耗时统计能力。方案兼顾分块效果与工程实用性，解决了OCR文本分块的核心痛点。技术完整性：覆盖文本预处理、语义嵌入、边界检测、Chunk优化全流程，适配OCR文本的特殊性；效果可控：通过语义相似度+Token长度双重约束，保证Chunk的语义连贯性和长度适配性；工程实用。
2025-12-09 10:32:15
974
原创 5 分钟搞定！腾讯混元 OCR API 部署全攻略
文章标签：#HunyuanOCR #OCR 识别 #多语种识别 #文档解析 #图片翻译 #vLLM 部署 #API 服务最近腾讯开源的混元 OCR（HunyuanOCR）凭借 1B 轻量化参数却斩获多项业界 SOTA 的表现火出圈了！作为混元原生多模态端到端 OCR 专家模型，它不仅支持文字检测识别、复杂文档解析，还能实现卡证票据信息抽取、视频字幕识别、拍照翻译等全场景功能。
2025-12-08 09:34:45
819
1
原创 5分钟搞定！小红书Dots.OCR API部署全攻略
这套部署方案基于Docker容器化，完美解决了环境依赖、版本兼容等问题，5分钟就能搞定Dots.OCR API服务。不管是个人使用还是集成到项目中，都非常方便～有任何问题欢迎评论区交流～#DotsOCR #OCR识别 #小红书开源 #PDF识别 #表格识别 #Docker部署 #API开发 #人工智能。
2025-12-05 15:33:59
1099
原创 零踩坑部署DeepSeek-OCR API：基于Docker+CUDA 11.8的完整指南
本次部署的核心是Unsloth版本精准适配：通过指定版本，解决了CUDA 11.8环境下的兼容问题；Dockerfile的关键优化点包括国内镜像加速、模型预下载、健康检查，大幅提升部署效率和服务稳定性；构建镜像，启动容器，验证重点是Unsloth安装和健康接口状态。按照本文步骤操作，可零踩坑完成DeepSeek-OCR API的容器化部署，且服务具备GPU加速、自动重启、状态监控等生产级特性。
2025-12-04 14:54:10
954
原创 深度解析：基于Dify API的企业级PDF批量OCR解决方案——从架构设计到落地实践
本文提出了一种基于Dify API的企业级PDF批量OCR解决方案，针对传统OCR工具在批量处理、断点续跑、页码顺序等方面的痛点问题。该方案采用原子化进度管理、强制顺序保障、多重容错机制等设计理念，通过状态管理模块实现精细化的断点续跑功能，支持四级降级恢复机制。技术架构涵盖PDF转图片、OCR处理、文本合并等核心模块，并采用中心化参数管理提升可维护性。方案兼容多系统环境，提供完善的异常处理和进度可视化功能，满足企业级场景的高效稳定需求。
2025-12-03 21:57:12
1215
原创 从图片PDF到结构化文本：基于Python+Dify的批量OCR自动化解决方案
本文提出的基于Python+Dify的批量OCR解决方案，完美解决了图片PDF的文本提取难题。通过将PDF转图片、Dify OCR识别、文本合并等环节自动化串联，大幅提升了文档处理效率，适用于企业办公、教育培训、政务处理等多个场景。该方案兼顾了易用性和扩展性，既可以直接部署使用，也可以根据实际需求进行二次开发。随着AI识别技术的不断进步，结合Dify平台的灵活配置能力，后续还可以进一步优化识别精度和处理效率，为文档数字化转型提供更强大的支持。
2025-12-03 14:10:32
1129
原创 Gemini 2.5、DeepSeek-OCR与MinerU2.5 OCR核心能力全方位对比报告
本次报告聚焦三款主流具备OCR能力的模型，其中Gemini 2.5-Pro是谷歌推出的通用多模态大模型，MinerU2.5是上海人工智能实验室开源的专业文档解析模型，DeepSeek-OCR则是专注于高效文档识别的开源模型。本次对比围绕OCR核心的识别精度、处理效率、复杂场景适配性等关键指标，结合权威评测数据与实测场景，综合评估三者的OCR表现，为不同场景下的工具选型提供参考。优点：零样本泛化能力强，能处理金属雕刻、扭曲字体等非传统文档的特殊OCR场景；基础文本识别无需复杂配置，上手门槛低。
2025-12-03 10:47:24
526
原创 TRL+Unsloth 高效微调大模型
本项目基于指定依赖版本（torch 2.7.1+cu128、trl 0.23.0 等），构建了一套低资源、高效率、高准确率的企业知识库大模型微调系统，核心成果如下：技术方案成熟可靠：通过 Unsloth+LoRA+TRL 的组合，实现单卡 16GB 显存高效训练，令牌准确率达 97.0%，超过目标阈值；参数配置科学合理：训练参数与依赖特性深度适配，平衡训练速度、显存占用与模型性能，支持训练过程可复现；系统功能完整：涵盖数据获取、预处理、训练、评估、部署全流程，支持实时监控与流式交互，可直接业务落地；
2025-12-01 10:11:47
1061
原创 谷歌ADK：让AI智能体组队写剧本，多智能体协作的黑科技揭秘
它知道谁适合做什么（智能体角色定义）；它知道任务的先后顺序（SequentialAgent）；它知道哪些任务可以同时做（ParallelAgent）；它知道什么时候需要反复打磨（LoopAgent）；它还会管理团队的「共享文件柜」（状态管理）。而剧本创作案例，就是这个「AI项目经理」成功操盘的一个项目——从用户的一个简单需求，到最终产出完整的剧本文件，全程自动化、专业化，让人不得不感叹：多智能体协作的时代，已经来了！
2025-11-20 08:52:11
727
原创 AI重塑社会结构：当“闲人”时代来临，我们该如何自处？
AI不仅是工具，更是一种“新物种”——它可能拥有情感模拟能力、伦理判断逻辑，甚至影响人类最私密的社会关系。当AI深度融入生活，我们需重新思考“人与AI的边界”，以及“人之所以为人”的核心价值。从社会关系重构来看，AI正改变“人与人连接”的方式。在医疗领域，智能手环实时监测健康数据，AI医生远程诊断，传统“医院集中诊疗”模式逐渐瓦解，人们无需聚集即可获得医疗服务；在教育领域，个性化学习设备替代传统课堂，学生可在家与AI导师互动，学校的“集中教育”功能弱化。
2025-11-16 09:29:36
760
原创 LiveTalking 数字人实战全解：从本地到云端，打造低延迟、高保真的 AI 数字人直播系统
LiveTalking 是一个开源的实时多模态数字人驱动系统，具备音视频同步、语音交互、大模型对话、TTS 播报等能力，适用于直播、客服、教育、虚拟主播等场景。如需进一步协助部署、调试或定制开发（如接入 Coze、重写 TTS 调用、适配 GPT-SoVITS），可微信沟通，我可以提供配置文件模板、代码片段或 Docker 镜像建议。文本转语音（TTS） 支持多种 TTS 服务，如 GPT-SoVITS、FishSpeech、EdgeTTS、腾讯云 TTS、豆包 TTS 等。
2025-11-07 17:03:32
1715
原创 wav语音流在safari浏览器或手机浏览器上播放不了怎么办？
这篇文档介绍了如何通过浏览器将WAV音频流转换为MP3格式并进行播放的技术方案。主要内容包括：使用Web Audio API解析WAV音频数据通过LAME.js编码器将PCM数据转换为MP3格式实现浏览器端音频格式转换和播放功能提供完整的HTML代码示例，包含音频获取、格式转换和播放控制等功能该方案特别针对Safari浏览器的兼容性问题进行了优化，适用于需要在前端处理音频格式转换的场景。
2025-10-14 23:19:09
210
原创 A100 vllm 运行Qwen3-30B-A3B，生成速度有多快？
测试结果：7.6 tokens/s，是否有点失望？还没有M2 Max快（50+ tokens/s)。部署方式：docker。
2025-10-13 15:50:01
445
原创 Milvus部署在T4 GPU上,Dify检索性能可以提升多少？
另外，默认的验证false始终无效，还是要验证MILVUS_USER和MILVUS_PASSWORD，我们设置为默认的值，如：root和Milvus。在.env环境变量中，使用默认的配置，一直连接失败，如：MILVUS_URI=http://host.docker.internal:19530。通常情况下，Dify检索知识库在秒级别，通常需要1-2秒，而部署在T4 GPU上则可以达到毫秒级别，通常在几十毫秒。部署配置说明一下，这很关键，直接关系到是否可以正常访问milvus。测试三：who are u?
2025-10-13 15:28:27
531
原创 LLM厂商靠什么赚钱？——解码大模型商业化的“明线”与“暗线”
但“水电”毛利极薄。据第三方测算，在H100上跑开源Llama-3.3-70B，每1000次推理成本约0.013美元，而公开API报价0.02美元，毛利率仅35%左右，再扣掉运维、带宽、人力，基本无利可图。LLM厂商的终点不是“卖模型”，而是把模型变成通往算力、咨询与奢侈级服务的“流量入口”——现在亏掉的钱，只是为将来收更高的“税”铺路。结论：当大模型变成高端咨询的“锤子”，厂商就能摆脱Token价格战，按人力+交付价值收费。结论：把最强模型做成“身份符号”，既能锁定收入，又能防止技术被蒸馏，一石二鸟。
2025-10-10 20:23:55
664
原创 CosyVoice2支持Nvidia 5090及vLLM加速
文章摘要： 本文介绍了在Nvidia 5090显卡上运行CosyVoice2并启用vLLM加速的方法。关键点包括：1）需安装torch 2.8.0+以支持sm_120架构；2）通过pip安装vLLM时需注意版本兼容性；3）提供完整的vLLM测试代码示例，包含音频处理和保存功能。测试代码展示了100轮语音合成任务的处理流程，支持零样本推理，并详细记录各环节耗时。文中特别强调驱动/CUDA版本匹配、半精度推理等优化事项，同时包含丰富的调试信息输出，帮助定位张量转换、音频保存等环节的潜在问题。
2025-09-25 12:00:47
460
原创 AI算力革命2025：从百亿烧钱竞赛到盈利破局
2025年AI行业迎来关键转折，训练成本逼近百亿美元，推理日耗达千万美元。行业从"参数竞赛"转向"成本控制"，资本更看重算力投入产出比。五大创新范式应运而生：小模型逆袭、智能路由优化、全域缓存体系、专用芯片突破和精准定价策略。垂直场景的小模型表现优异，专用芯片效率提升15倍，95%请求实现零推理响应。AI从业者角色重塑，成本优化师成为稀缺人才。行业共识表明，控制算力成本已成为AI企业生存与盈利的核心竞争力，参数规模让位于商业价值的精准转化。
2025-09-24 23:17:24
1204
原创 ZipVoice小米语音合成-MacOS可运行
ZipVoice：主要针对单说话人零样本合成，它基于Zipformer骨干网络，该网络基于U-Net的多尺度高效结构，巧妙结合卷积与注意力机制，并能多次复用注意力权重，使ZipVoice在参数量上相比同类模型直接缩减了约63%。同时，通过流蒸馏（Flow Distillation）技术，在不牺牲语音质量的前提下，大幅减少了推理所需的步数，在CPU上也能达到接近实时的合成速度。
2025-09-16 12:49:01
494
原创 MacOS 运行CosyVoice
MacOS上运行比较简单，直接使用docker即可，虽然是docker是 AMD64版本非ARM64版本，但在容器中仍然可以使用，但性能会有所损失，相当于直接用的CPU，也没有使用MPS加速。3、克隆时间比较长（取决于GPU性能，使用H20以满足低延迟输出），L4 克隆默认文本需要10秒。说明：默认使用asset/zero_shot_prompt.wav 作为参考声音。若要指定参考声音：--prompt_wav "你的参考声音.wav"若要指定克隆文本：--tts_text "你需要克隆的文本内容"
2025-09-09 16:41:15
562
原创 MacOS M芯片 运行GPT-SoVITSv2Pro
训练和推理的基本流程类似，目前GPT-Sovits已经升级，MacOS下部署更能简单一些。5）一键三连提取自监督特征和语义特征（第一步需要下载nltk_data，有可能会失败，要科学上网）5、创建虚拟环境 python=3.10，并安装（--device MPS）2）指定待训练的声音文件路径：如：input/someone。3）依次执行声音拆分、降噪和ASR转写（自动标注）2、安装ffmpeg(webui.py需要使用）3、安装wget(install.sh需要使用）4）标注界面也不是必须的（手工标注）
2025-09-08 14:33:11
587
原创 成功的三重筛选：从方向到迭代的生存法则
筛选门核心能力成事者的“修炼”第一道精准目标看清方向第二道长期坚持耐住寂寞第三道频繁迭代拥抱变化这三者，不是孤立的条件，而是相辅相成的整体没有精准目标的坚持 → 是“盲目奔跑”没有长期坚持的迭代 → 是“浅尝辄止”没有频繁迭代的目标 → 是“固步自封”✅真正的成功，从来不是“幸运降临”，而是在三道筛选门中不断突破自我的结果。当你能：✅ 精准定位方向✅ 耐住长期寂寞✅ 持续优化自我你不仅能做成一件事更会成为一个——🌱可持续成长的人。
2025-08-30 09:00:27
644
原创 上下文工程
模型输入中的文本内容（如用户提问、历史对话、文档片段等）；模型在生成响应时所依赖的所有信息；包含任务描述、示例、背景知识、约束条件等。✅ 例如：在问答系统中，上下文可能是问题本身 + 一段参考文章。上下文工程 = 让大模型“看得懂、想得清、答得准”的系统性方法论。它不仅是“写得好提示”，更是信息架构、知识管理、任务建模与用户体验设计的融合。在LLM应用落地中，优秀的上下文工程往往是决定成败的关键。
2025-08-22 12:00:13
756
原创 强化学习- GRPO
要点说明✅广义奖励超越原始奖励，融合内在动机、多任务、不确定性等信息✅策略优化驱动以最大化期望累积回报为核心目标✅正则化增强鲁棒性通过KL、熵、梯度约束等，防止策略崩溃或过拟合✅灵活性与可扩展性可适配多种任务、环境与约束条件✅平衡探索与利用通过奖励设计与正则项实现动态平衡在复杂、不确定或高风险环境中，通过“广义奖励”与“智能正则化”的结合，实现稳定、高效、可泛化的策略优化。它不是单一算法，而是一种策略优化的设计哲学，强调灵活性、安全性与长期性能的统一。
2025-08-21 16:39:06
1213
原创 使用大模型构建“点咖啡”会话管理：从提示词到完整交互
{“user_name”:“小明”,“order_items”:[{“drink”:“拿铁”,“size”:“中杯”,“sugar”:“半糖”,“milk”:“燕麦奶”}],“awaiting_field”:“drink”,“confirmed”:false}{“user_name”:“小明”,“order_items”:[{“drink”:“拿铁”,“size”:“”,“sugar”:“”,“milk”:“”}],“awaiting_field”:“detail”,“confirmed”:false}
2025-08-15 15:22:08
888
原创 为什么编程辅助工具，普遍感觉不太好用呢？
虽然现在的编程辅助工具（如GitHub Copilot、ChatGPT、TabNine、Cursor等）已经取得了显著进展，但很多人仍然觉得它们“不太好使”。这种“不好用”的感觉往往并不是因为这些工具完全无效，而是因为它们与程序员的实际工作方式之间存在一系列错位。你可以把它当成一个“有点聪明但不靠谱的实习生”——用得好是助力，用不好是负担。它不会替你开车，但如果你知道怎么问、怎么修正，它确实能让你开得更快一点。写复杂逻辑 一般 用它生成“初稿”，再人工重构。编程辅助工具不是“自动驾驶”，而是“副驾驶”。
2025-08-15 14:16:11
373
原创 Qwen3-30B-A3B-Thinking-2507：你值得拥有的 64 GB 级「推理怪兽」
Qwen3-30B-A3B-Thinking-2507：真正意义上「一张 910B 就能拥有的推理怪兽」但 一张 64 GB 昇腾 910B 就能让它 INT8 全速跑、INT4 全并发。30 B 参数、3.3 B 激活、42 GB 显存、64 GB 单卡就能跑。它在 数学、代码、中文理解 三项 全面碾压 70 B Dense，别再被“3 B 激活”迷惑——它依旧是 30 B 参数的大块头，在 总参 30 B / 激活 3.3 B 的 MoE 架构下，数学 85 分、代码 66 分、中文霸榜。
2025-08-12 23:38:16
1959
原创 显存带宽：大模型推理的隐形天花板
从“12.2 tokens/s”的理论上限到“80 tokens/s”的实际性能，每一步提升都源于对带宽的极致利用。显存带宽不是抽象概念，而是可通过“权重大小÷带宽=耗时”直接计算的物理约束。在大模型推理中，理解这一逻辑才能把握优化核心——不是盲目堆算力，而是通过软件创新逼近带宽的物理极限。
2025-08-08 13:16:52
1618
原创 7卡昇腾910B环境中完成Qwen2.5-32B的部署与测试验证（仅供参考）
指标优化目标测试工具AI Core利用率≥80%单token生成延迟≤100ms（批量=16）vLLM监控API + 自定义脚本吞吐量vLLM显存占用单卡≤90GB。
2025-08-08 10:21:43
1990
原创 算力估算-运行Qwen2.5 32B 要达到2万tokens/s需要多少张昇腾910B卡？
要实现的吞吐量，需根据模型量化精度（FP16/INT8）和昇腾910B的性能保守值重新计算。以下分析基于您的核心前提（FP16单卡800-1000 token/s、INT8单卡1500-2000 token/s），结合模型并行与数据并行的部署策略，给出具体方案和卡数需求。
2025-08-08 10:03:21
1663
人工智能生成式AI在客户服务领域的商业落地方法与效果验证：智能客服系统设计与多维度ROI分析
2025-10-29
winsock全双工多客户端通信
2006-09-21
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人