xiaoyanboke的博客

预期输出为Y=-1，在对比xg的时候，输出为y=1那么此时修正W。经过变换之后得到h(x)，这个threshold其实就是常见的 f(x) = WX + b中的b，直线公式就是WX + b = 0。这是一个证明某人是否能够贷款的公式，当他的分数大于threshold的时候则认为可以贷款。由此可得W与分类直线在几何上垂直，推理到高纬也是如此，另外W也被叫做法向量。在某一t轮中，此时的W已经确定，输入X，输出Y。机器学习就是在不断迭代更新W的过程，直到找到一个最适合的W。W就是在这多维上的值。

Word 样式名（Heading/标题/TOC 标题）+ 字号兜底 → 输出 #…首先提取部分要提取出结构化的md标题，方便后面split进行切分。可以看到召回效果显著提升。

文章摘要：本文分析了父子模式的实现机制，包括两种父节点模式（段落模式和全文模式）的切分策略，以及子节点的切分方法。在全文模式下，文档内容被直接拼接后切分；在段落模式下，每个段落独立切分。子节点通过特定方法进行切分，并仅将子节点存入向量数据库。检索时先召回子节点，再通过格式化方法构建父子关系，确保检索结果的完整性和相关性。

摘要 本文探讨了工作流系统中并行节点执行时的输出顺序问题。研究发现，当多个分支同时执行时，输出顺序可能与预期不符，主要原因是系统采用了以下机制：1) 每个节点完成时都会触发流式输出尝试；2) 静态文本和可用变量会立即输出，而无需等待节点实际执行；3) 实际节点执行时才会生成完整输出。这种设计导致非阻塞分支的输出可能先于耗时分支显示，造成表面上的"混乱"。文章详细分析了事件触发机制、依赖关系处理和输出生成逻辑，并给出了节点执行顺序的解释模型。

串行回复当我加上第三条分支，此时的输出就很混乱了，按理来说最后输出的第二波输出反而先结束了，调用LLM结果的第一波输出最后才输出，这是为什么？

本文介绍了Text2SQL系统的实现进展与后续优化计划。系统已完成基础功能开发，包括自然语言转SQL、用户交互优化、模糊时间处理、预定义问题回答等功能，并引入高质量测试集验证效果。后续将重点优化知识库建设、持续学习机制、智能纠错和多路径打分机制，提升SQL生成质量。同时，文章详细说明了如何基于Spider验证集搭建测试环境，包括数据库迁移步骤，使用Python脚本将SQLite数据批量导入PostgreSQL，为系统测试提供真实数据支持。

显卡：RTX5060：python版本：3.10.18CUDA版本：12.9nvidia-smi。

编号问题描述SQL 模板类型Q1查询某城市的客户公司名称SQL模板Q2查询某一年的订单数量SQL模板Q3查询某个客户的所有订单SQL模板Q4查询每个产品的总销售数量完整SQLQ5查询某库存阈值以下的产品SQL模板Q6查询某员工经手的订单SQL模板Q7查询某时间段内的订单数SQL模板Q8查询某类产品的销售明细SQL模板Q9查询某个供应商提供的产品SQL模板Q10查询某年每个月的订单数SQL模板。

本文介绍了面向企业的ChatBI工作流开发进展，重点实现了Text2SQL功能与用户交互优化。系统通过问题分类机制（直接提问、补充修正、异常反馈、格式要求等）动态处理用户查询，并设计了意图识别和智能补全模块提升交互体验。后续将优化预定义回答、知识库建设和持续学习机制。测试显示系统能有效处理模糊时间查询、多轮提问和结果格式调整等场景。该方案为企业数据分析提供了高效的对话式查询解决方案。

本文记录了OCR模型识别文本过程中的问题排查与解决方案。主要问题包括：部分识别结果为空、多行内容无法分段、蓝底白字识别效果差以及显存溢出。通过添加调试代码、引入Y方向投影切分法、优化批量识别逻辑和改为逐box单独识别等方法解决。后续可优化不同背景的文本识别能力并升级模型。最终实现了OCR识别的稳定性与准确性提升。

阅读源码发现其实就是启动 task_executor.py 和 ragflow_server.py 两个服务，但是还有相关的环境变量不知道怎么设置。不知道原因：后面新建了个环境变量文件，把所有的注释都去掉，就能用了。如果已安装，可跳过。#redis_port 无法解析。配置文件示例（建议放入。

Dify更适合固定功能场景，配置简单，但灵活度较低；MCP更像是 AI 的“工具集线器”，适用于复杂任务、多工具调度场景。

严谨验证文件类型，避免因扩展名欺骗导致异常；构建健壮的容错逻辑，提升系统的可用性和用户体验；提供清晰的反馈信息，帮助用户自行解决问题，减少客服压力。对于希望兼容.doc文件的开发者，可以进一步使用pywin32或Mammoth等第三方工具，甚至调用 LibreOffice CLI 实现.doc转.docx，但这涉及系统依赖部署，不适合轻量级 Web 服务。

在编码前，将长文本切分成多个小段（如按固定 token 数、换行符、标点等），每段单独送入模型，单独编码。优点：实现简单缺点每个 chunk 独立编码，上下文信息丢失重复计算（重叠窗口）浪费资源对于每个样本中每段的，提取对应 token 的 embedding；对该区间执行；将结果转换为 numpy 向量，方便存储/检索。特性模型调用次数多次一次上下文信息丢失保留全局上下文实现复杂度简单稍复杂（需记录 span）聚合策略灵活性固定切片高度灵活，支持任意切分逻辑。

文本生成质量： BLEU 和 ROUGE 分数都不算高，说明模型的生成结果和参考答案差距较大，可能需要调整训练数据或改进模型结构。推理性能： 运行时间较长，处理速度较慢，可能与模型大小、计算资源或者 batch size 有关。

llamafactory任然可能会报错环境问题，重启llamafactory可能可以解决问题。在操作量化操作的时候显示需要安装auto_gptq。本地环境：autodl-ai租的服务器。安装了llamafactory，

模型的量化（Quantization）是一种优化技术，主要用于减少深度学习模型的计算复杂度和存储需求。它的核心思想是将模型中的高精度浮点数（通常是 32 位或 16 位）转换为低精度整数（如 8 位或 4 位），以降低计算成本，同时尽可能保持模型的性能。

使用原生的sdk连接。

i=53118。