Top các câu chuyện trên Hacker News ngày 15-06-2025 #

HP mua lại Palm và những bài học thất bại: HP đã không thể tích hợp hiệu quả công nghệ WebOS của Palm do sự thay đổi CEO và điều chỉnh chiến lược, dẫn đến thất bại của TouchPad.
Thiết kế kính lỏng của Apple: Thiết kế giao diện kính lỏng của Apple không chỉ là một bản cập nhật về mặt thị giác mà còn đặt nền móng cho giao diện AR trong tương lai.
Lạc nội mạc tử cung: Lạc nội mạc tử cung là một bệnh phức tạp với nguyên nhân chưa rõ ràng và thiếu các phương pháp chữa trị hiệu quả, cần nhiều nghiên cứu và quan tâm hơn.
Hiện thực hóa Stable Diffusion 3.5 bằng PyTorch thuần túy: miniDiffusion là một triển khai PyTorch thuần túy để phục vụ mục đích giáo dục và thử nghiệm, với code ngắn gọn và cấu trúc rõ ràng.
Mô hình ngôn ngữ thích ứng: Khung SEAL cải thiện khả năng tích hợp kiến thức và khái quát hóa ít mẫu của mô hình ngôn ngữ thông qua tự tinh chỉnh và tối ưu hóa học tăng cường.
Thuật toán tìm kiếm chuỗi con thân thiện với SIMD: Bài viết thảo luận về các thuật toán tìm kiếm chuỗi được tối ưu hóa bằng SIMD, cũng như việc triển khai và so sánh hiệu năng của chúng trên các tập lệnh khác nhau.
Hiện thực hóa lập trình logic: Bài viết giới thiệu các đặc điểm và cách hiện thực của Prolog và Datalog, đồng thời thể hiện tiềm năng của lập trình logic trong truy vấn cơ sở dữ liệu.
Khủng hoảng sa thải trong ngành công nghệ: Việc sa thải chủ yếu do chi phí vốn tăng và thay đổi chính sách thuế gây ra, một số doanh nghiệp ứng phó bằng cách chuyển hoạt động R&D ra nước ngoài.
Gián đoạn dịch vụ Google Cloud: Gián đoạn dịch vụ bắt nguồn từ việc thiếu xử lý lỗi trong quá trình thay đổi code, cho thấy những thiếu sót trong quy trình kiểm thử và triển khai.
Tiến bộ trong quy hoạch tuyến tính số nguyên: Quy hoạch tuyến tính số nguyên hỗn hợp đã đạt được những tiến bộ đáng kể trong các ứng dụng thực tế, nhưng vẫn phải đối mặt với những thách thức và nghiên cứu vẫn đang diễn ra tích cực.

Tôi đã thuyết phục hội đồng quản trị của HP mua Palm và chứng kiến họ giết chết nó #

I convinced HP’s board to buy Palm and watched them kill it

https://philmckinney.substack.com/p/i-convinced-hps-board-to-buy-palm

Phil McKinney đã chia sẻ một câu chuyện mà ông chưa từng kể trước đây trên blog của mình “Phil McKinney’s Studio Notes: Innovation Decisions”: cách ông thuyết phục hội đồng quản trị của Hewlett-Packard (HP) mua lại Palm với giá 1,2 tỷ đô la, sau đó chứng kiến họ phá hủy nó trong một thời gian ngắn. Bài viết này không chỉ là một phân tích về thất bại công nghệ, vì Phil McKinney là Giám đốc Công nghệ (CTO) của HP, ông đã dẫn đầu quá trình thẩm định kỹ thuật đối với Palm và tự tin đề xuất thương vụ mua lại với hội đồng quản trị của HP. Ông tin rằng HP đang mua tương lai của điện toán di động.

Trong bài viết, Phil McKinney mô tả chi tiết lý do tại sao ông tin rằng WebOS là một công nghệ nền tảng đột phá và cách ông trình bày điều này với hội đồng quản trị của HP và CEO Mark Hurd vào thời điểm đó. Ông tin rằng WebOS đại diện cho chìa khóa để HP khác biệt hóa trong thị trường điện toán di động mới nổi. Vào tháng 4 năm 2010, HP đã công bố thương vụ mua lại trị giá 1,2 tỷ đô la này, Phil McKinney tự hào về công việc kỹ thuật đã thực hiện và mong chờ một tương lai được xây dựng cùng nhau.

Sau khi mua lại, vai trò của Phil McKinney chuyển sang giúp nhóm Palm tận dụng khả năng quy mô lớn của HP. Họ đã thảo luận về cách mở rộng WebOS sang máy tính bảng, có thể tích hợp với nền tảng PC của HP và thậm chí tìm ứng dụng trong hệ sinh thái máy in. Mọi thứ dường như đã sẵn sàng cho thành công.

Tuy nhiên, vào tháng 8 năm 2010, Mark Hurd buộc phải từ chức CEO và hội đồng quản trị đã thay thế ông bằng Leo Apotheker, cựu CEO của SAP, người mang đến một tầm nhìn chiến lược hoàn toàn khác. Apotheker có kế hoạch chuyển đổi HP từ một công ty phần cứng thành một công ty phần mềm và dịch vụ, tương tự như sự chuyển đổi của IBM nhiều năm trước. Ông muốn thoái vốn hoặc giảm thiểu hoạt động kinh doanh phần cứng của HP, bao gồm máy tính cá nhân, máy in và các thiết bị di động như TouchPad. Theo quan điểm của ông, WebOS là loại phiền toái phần cứng mà ông muốn loại bỏ.

Vào tháng 6 năm 2011, Phil McKinney cần phẫu thuật ngay lập tức do tình trạng y tế khẩn cấp và phải nằm viện và hồi phục trong tám tuần, điều này khiến ông không thể tham gia vào các quyết định quan trọng nhất về tương lai của nền tảng. Trong thời gian ông hồi phục, toàn bộ bối cảnh điện toán di động của HP bắt đầu sụp đổ.

Vào ngày 1 tháng 7 năm 2011, HP đã ra mắt máy tính bảng TouchPad chạy WebOS 3.0. Phil McKinney đã xem buổi ra mắt từ giường bệnh, hy vọng sẽ thấy thành quả của tất cả công việc kỹ thuật và kế hoạch chiến lược của họ. Tuy nhiên, ông đã chứng kiến sự khởi đầu của một trong những thất bại sản phẩm nhanh nhất trong lịch sử công nghệ. TouchPad có giá quá cao, thiếu hệ sinh thái ứng dụng và sức mạnh tiếp thị để chứng minh vị thế cao cấp của nó. Thiết bị có cảm giác vội vã ra mắt và thiếu sự tinh tế có thể giúp nó cạnh tranh. Đánh giá của người tiêu dùng ở mức hỗn hợp. Số liệu bán hàng ban đầu thật đáng kinh ngạc: HP chỉ bán được 25.000 chiếc TouchPad, trong khi đã xuất xưởng 270.000 chiếc cho các nhà bán lẻ. Trong cùng quý, Apple đã bán được 9 triệu chiếc iPad, trong khi TouchPad bám bụi trên kệ cửa hàng.

Sau đó là thông báo thay đổi mọi thứ. Vào ngày 18 tháng 8 năm 2011, 49 ngày sau khi TouchPad ra mắt, HP tuyên bố sẽ ngừng ngay lập tức tất cả các thiết bị WebOS. Phil McKinney vẫn nằm trên giường bệnh, xem công việc thẩm định kỹ thuật và các khuyến nghị chiến lược của mình bị dỡ bỏ theo thời gian thực thông qua các báo cáo tin tức và phân tích ngành. 49 ngày, không đủ để khắc phục các vấn đề ra mắt, xây dựng động lực cho nhà phát triển hoặc thiết lập quan hệ đối tác bán lẻ. Hoạt động kinh doanh nền tảng thường mất 18-24 tháng để thể hiện sức hút thực sự trên thị trường. Nhưng Leo Apotheker không xem xét dòng thời gian của nền tảng, ông xem xét chiến lược chuyển đổi HP thành một công ty phần mềm của mình.

Phần đau đớn nhất không chỉ là tốc độ của quyết định, mà là việc biết rằng Apotheker đã đưa ra lựa chọn ngừng hoạt động mà thậm chí không thông báo trước cho nhóm Palm. Theo báo cáo, ông dường như vội vàng loại bỏ một sản phẩm không phù hợp với tầm nhìn của ông về HP như một công ty phần mềm. Phil McKinney cảm thấy bất lực, bị phản bội và bằng cách nào đó, ông cảm thấy có trách nhiệm vì đã không ở đó để chiến đấu cho công nghệ đột phá mà ông tin tưởng.

HN | Độ nóng: 634 điểm | 486 bình luận | Tác giả: AndrewDucker #

https://news.ycombinator.com/item?id=44270709

HP đã định giá quá cao khi ra mắt TouchPad, thiếu hệ sinh thái ứng dụng và nỗ lực quảng bá thị trường.
Để thành công cần đầu tư nhiều năm, dự đoán thị trường sai lầm là chuyện thường, điều quan trọng là phải có sự đầu tư liên tục.
Sự thất bại của Microsoft Windows Phone cũng là do thiết bị ra mắt thị trường quá ngắn, không tích lũy đủ ứng dụng.
Intel Itanium dự đoán doanh số sai lầm, trong khi IEA dự đoán về năng lượng mặt trời thì quá bảo thủ.
Dự đoán sai là chuyện bình thường, điều quan trọng là tiếp tục dự đoán cho đến khi cuối cùng đúng.
Tăng trưởng điện mặt trời vượt quá mong đợi, tương lai có thể vượt quá mức tiêu thụ năng lượng toàn cầu.
Những người dự đoán về Itanium đã điều chỉnh đường cong dự đoán theo thời gian, trong khi IEA dường như phớt lờ thực tế và tiếp tục dự đoán.
Ảnh hưởng của AMD trên thị trường máy chủ 64-bit bị đánh giá thấp, Opteron từng chiếm 25% thị phần.
Sự chậm trễ của Intel trong công nghệ đa nhân là do các đối tác phần mềm chính của họ lo ngại về sự hỗ trợ cho thế giới đa nhân.
Intel cho đến khi dòng Xeon 5100 kiến trúc Core ra mắt năm 2006 mới có tính cạnh tranh trên thị trường máy chủ đại chúng.
Intel hy vọng đạt được độc quyền trên thị trường PC và máy chủ, nhưng đã không thể thực hiện được thông qua Itanium, cuối cùng phải cấp phép chéo với AMD64.

Liquid Glass của Apple là sự chuẩn bị cho giao diện AR, không chỉ là sự làm mới thiết kế #

Apple’s Liquid Glass is prep work for AR interfaces, not just a design refresh

https://omc345.substack.com/p/from-skeuomorphic-to-liquid-glass

Việc Apple giới thiệu thiết kế giao diện “Kính Lỏng” tại WWDC 2025 không chỉ là một bản cập nhật về mặt thị giác, mà còn là sự tái định hình chiến lược của công ty đối với phương thức tương tác giữa người và máy trong tương lai. Bài viết phân tích bối cảnh và những tác động tiềm tàng của sự thay đổi thiết kế này, chỉ ra rằng đây là sự bố trí của Apple cho thập kỷ tới, nhằm giúp người dùng cảm thấy tự nhiên chứ không xa lạ khi trải nghiệm công nghệ mới.

Sự thay đổi thiết kế của Apple không phải lần đầu tiên gây tranh cãi. Ví dụ, từ thiết kế mô phỏng (skeuomorphic) của iOS 6 đến thiết kế tối giản của iOS 7, người dùng cũng đã từng đặt câu hỏi về tính khả dụng và thẩm mỹ của thiết kế mới. Tuy nhiên, những thay đổi thiết kế của Apple thường báo hiệu những thay đổi căn bản trong phương thức tương tác. Thiết kế mô phỏng giúp người dùng làm quen với công nghệ màn hình cảm ứng, trong khi thiết kế tối giản phản ánh sự thành thạo của người dùng đối với tương tác chạm.

Việc ra mắt thiết kế “Kính Lỏng” có liên quan mật thiết đến visionOS của Apple. Trong thực tế tăng cường, các yếu tố giao diện cần phải cùng tồn tại với thế giới thực, vì vậy chúng không thể chỉ là những khung hình chữ nhật che khuất tầm nhìn. Kính lỏng thông qua độ trong suốt và cảm giác phân lớp động, làm cho giao diện phù hợp hơn với thực tế vật lý, do đó khi người dùng đeo kính thực tế tăng cường, giao diện trông tự nhiên và chân thực hơn.

Kính lỏng không chỉ là một hiệu ứng thị giác, nó còn thể hiện sự kết hợp chặt chẽ giữa phần cứng và phần mềm của Apple. Các đặc tính như hiệu ứng trong suốt động và làm mờ theo thời gian thực, đòi hỏi khả năng xử lý đồ họa mạnh mẽ và quy trình kết xuất (rendering pipeline) được tối ưu hóa. Hoạt động hiệu quả của công nghệ này thể hiện xuất sắc trên các thiết bị của Apple, trong khi trên phần cứng của đối thủ cạnh tranh có thể xuất hiện tình trạng nghẽn cổ chai về hiệu năng, từ đó nâng cao giá trị của các sản phẩm Apple.

Mặc dù tại WWDC 2025, Apple có ít thông báo liên quan đến trí tuệ nhân tạo, nhưng triết lý thiết kế của họ gợi ý về một phương thức tương tác AI nhận biết ngữ cảnh tốt hơn. Ví dụ, các đề xuất thông minh có thể xuất hiện trong tầm nhìn của người dùng dưới dạng bán trong suốt, hòa nhập vào quy trình làm việc hiện tại. Tư duy thiết kế như vậy làm cho tương tác AI trở nên tự nhiên hơn, thay vì xâm nhập.

Mặc dù giao diện kính lỏng mang lại trải nghiệm thị giác mới, nhưng những phản hồi ban đầu chỉ ra các vấn đề về khả năng đọc và gánh nặng nhận thức. Giao diện trong suốt có thể làm giảm độ tương phản của văn bản, khiến việc đọc trở nên khó khăn hơn. Tuy nhiên, kinh nghiệm trước đây của Apple trong lĩnh vực thiết kế cho thấy họ sẽ dần dần cải thiện thiết kế dựa trên phản hồi của người dùng, để nâng cao tính khả dụng và khả năng tiếp cận.

Sự thay đổi thiết kế của Apple không chỉ ảnh hưởng đến các sản phẩm của chính họ, mà còn có thể định hình lại toàn bộ ngành. Các nhà phát triển và nhà thiết kế sẽ có xu hướng bắt chước ngôn ngữ thiết kế mới của Apple, từ đó hình thành một loại “khóa văn hóa” trong tâm trí người dùng, ngay cả những người sử dụng thiết bị của các thương hiệu khác cũng sẽ quen với các mô hình thiết kế của Apple.

Thông qua việc giới thiệu kính lỏng, Apple đã đặt nền móng cho các mô hình tính toán trong tương lai: mọi người sẽ hướng tới giao diện môi trường kết hợp giữa thực tế số và thực tế vật lý. Mặc dù cảm ứng vẫn quan trọng, nhưng các phương thức tương tác bằng giọng nói, cử chỉ và nhận biết ngữ cảnh sẽ trở nên phổ biến hơn. Apple hy vọng thông qua việc xây dựng khung hình trực quan và khái niệm này, sẽ chuẩn bị cho sự chuyển đổi trong tương lai của người dùng và nhà phát triển, để khi kính AR nhẹ trở nên phổ biến, trải nghiệm sử dụng của người dùng có thể diễn ra suôn sẻ và liền mạch.

HN | Độ nóng: 306 điểm | 322 bình luận | Tác giả: lightningcable #

https://news.ycombinator.com/item?id=44271630

Thiết kế kính lỏng của Apple không chỉ là để làm mới thiết kế giao diện, mà còn là để chuẩn bị cho giao diện AR
Từ thiết kế mô phỏng vật thể của iOS 6 đến chủ nghĩa tối giản của iOS 7, đã gây ra các cuộc thảo luận về tính khả dụng và giá trị thẩm mỹ, nhưng hai năm sau, toàn bộ ngành đã áp dụng các nguyên tắc thiết kế phẳng
Các nhà báo công nghệ thường làm ngơ trước những gì Apple làm, cho rằng Apple là người đầu tiên làm như vậy, có thể là do họ chủ yếu sử dụng iPhone và không hiểu rõ về các thiết bị khác
Đôi khi, người bình thường nếu nghiên cứu sâu về một lĩnh vực, có thể hiểu biết hơn cả những người chuyên nghiệp
Trong lĩnh vực y học, bệnh nhân có thể hiểu rõ hơn bác sĩ về bệnh trạng cụ thể của mình
Đánh giá mang tính chủ quan, nếu muốn đưa ra lựa chọn hài lòng, tốt nhất là tìm một người đánh giá có gu thẩm mỹ tương đồng
Người đánh giá có thể có xung đột lợi ích, đặc biệt là đối với các sản phẩm đặt trước
Những người có ảnh hưởng trở nên phổ biến vì họ có thể thuê ngoài những suy nghĩ của bạn
Mọi người không thể tự mình làm tất cả các “suy nghĩ”, mọi người luôn đánh giá mọi thứ cho người khác, đây là một dịch vụ có giá trị
Apple thường là công ty đầu tiên làm những điều mới một cách thành công, các sản phẩm ban đầu có thể không đủ thành công để duy trì hoặc chỉ ở trong một thị trường ngách
Rất khó để định nghĩa thành công, nếu Apple áp dụng và thay đổi một xu hướng thiết kế nào đó, thì đó có được coi là thành công không? Chỉ vì được áp dụng rộng rãi?
Apple thường chờ thị trường chứng minh một công nghệ nào đó rồi mới làm, Face ID là họ đã mua lại công ty sản xuất Xbox Kinect
Apple là người tiên phong trong giao diện đa chạm, GUI máy tính cá nhân và chuột
So sánh Kinect với Face ID trong điện thoại, cần xem xét sự khác biệt về kích thước và công nghệ
Ngoài phát minh ra iPhone, Apple còn có gì là sáng kiến thành công đầu tiên? Đó đã là gần 20 năm trước rồi
Windows Phone OS có thiết kế đơn giản, thiết thực, chức năng vượt trội, nhưng Microsoft đã không nắm bắt được cơ hội
Sự thất bại của Windows Phone là do thiếu hệ sinh thái ứng dụng, Apple và Android có 20 năm tích lũy hệ sinh thái ứng dụng
Nếu Microsoft ra mắt Windows Phone ngày nay, họ có thể tận dụng hệ sinh thái mã nguồn mở để thành công

Lạc nội mạc tử cung là một căn bệnh thú vị #

Endometriosis is an interesting disease

https://www.owlposting.com/p/endometriosis-is-an-incredibly-interesting

Bài viết này là về giới thiệu chi tiết về lạc nội mạc tử cung (endometriosis), một căn bệnh vô cùng thú vị. Bài viết bắt đầu bằng cách đưa ra một vài điểm thú vị về lạc nội mạc tử cung: nguyên nhân chính gây ra nó vẫn chưa được hiểu đầy đủ, nó tương tự như ung thư, không có cách chữa trị thực sự và là một trong những bệnh phổ biến nhất và thiếu kinh phí nhất trên trái đất.

Bài viết giới thiệu định nghĩa lâm sàng của lạc nội mạc tử cung, đó là tình trạng mô giống nội mạc tử cung phát triển bên ngoài tử cung. Mô này có thể cấy vào các mô lân cận, chẳng hạn như buồng trứng và ống dẫn trứng, hoặc thậm chí các cơ quan xa hơn, chẳng hạn như bàng quang và ruột. Do ảnh hưởng liên tục của các yếu tố tăng trưởng hormone (chủ yếu là estrogen), các tế bào giống nội mạc tử cung lạc chỗ này phản ứng theo chu kỳ giống như nội mạc tử cung bình thường. Chúng dày lên, vỡ ra và chảy máu trong mỗi chu kỳ kinh nguyệt, nhưng vì không có nơi nào để thoát ra, các mô và máu này tích tụ lại, dẫn đến đau dữ dội, viêm nhiễm, xơ hóa (hình thành sẹo) và dính giữa các cơ quan. Theo thời gian, các chu kỳ viêm nhiễm và xơ hóa lặp đi lặp lại này có thể dẫn đến những thay đổi cấu trúc vĩnh viễn trong bụng và xương chậu, gây ra đau vùng chậu mãn tính và vô sinh.

Bài viết tiếp tục thảo luận về cách các mô lạc nội mạc tử cung hình thành ban đầu và tại sao chúng bị mắc kẹt. Giả thuyết chính là kinh nguyệt ngược dòng, một lý thuyết lần đầu tiên được đề xuất bởi bác sĩ phụ khoa John Sampson gần 100 năm trước. Lý thuyết này cho rằng, trong thời kỳ kinh nguyệt, một số tế bào nội mạc tử cung bong ra chảy ngược qua ống dẫn trứng vào khoang chậu thay vì chảy ra ngoài qua cổ tử cung. Một khi đến đó, các tế bào này sẽ cấy vào, tiếp tục phát triển và trở thành mô giống nội mạc tử cung đặc trưng của lạc nội mạc tử cung.

Mặc dù lý thuyết kinh nguyệt ngược dòng thường được lặp lại trong giới bác sĩ, nhưng nó không thể giải thích tất cả các trường hợp lạc nội mạc tử cung. Thứ nhất, kinh nguyệt ngược dòng xảy ra ở 75-90% phụ nữ, nhưng hầu hết không bao giờ phát triển thành lạc nội mạc tử cung. Thứ hai, lạc nội mạc tử cung có nhiều dạng, một số chỉ giới hạn ở vùng chậu, nhưng cũng có thể xảy ra ở những vùng rất xa, chẳng hạn như đường tiêu hóa, phổi, thậm chí cả não. Cuối cùng, điều gây sốc nhất là lạc nội mạc tử cung cũng được tìm thấy ở những người chưa từng trải qua kinh nguyệt, chẳng hạn như các bé gái tiền dậy thì từ 8,5-13 tuổi, phụ nữ thiếu tử cung do di truyền, và thậm chí cả nam giới chuyển giới. Những bệnh nhân nam này có thể có nồng độ estrogen cao hơn, có thể do xơ gan (dẫn đến khả năng phân hủy estrogen giảm), điều trị ung thư tuyến tiền liệt bằng estrogen liều cao hoặc béo phì.

Bài viết cuối cùng đề cập rằng, mặc dù lạc nội mạc tử cung có thể xảy ra ở phụ nữ chuyển giới đang điều trị liệu pháp thay thế hormone, nhưng đây là một vấn đề phức tạp và cần nghiên cứu và thảo luận thêm. Nhìn chung, lạc nội mạc tử cung là một căn bệnh phức tạp và bí ẩn, cần được quan tâm và nghiên cứu nhiều hơn.

HN | Độ nóng: 296 điểm | 197 bình luận | Tác giả: crescit_eundo #

https://news.ycombinator.com/item?id=44272933

Việc chẩn đoán cho bệnh nhân nữ gặp khó khăn có thể liên quan đến sự mệt mỏi hệ thống, sự kiêu ngạo, sự phụ thuộc vào chẩn đoán kinh nghiệm, sự thiếu hiểu biết về các bệnh của phụ nữ hoặc sự phân biệt giới tính trong y tế của các bác sĩ.
Bệnh nhân không được đối xử như những cá thể riêng biệt, mà được xử lý nhanh chóng như một nhiệm vụ hàng ngày, dẫn đến 10% các trường hợp đặc biệt không được xử lý đúng cách.
Dù là y tế công hay tư, đều tồn tại vấn đề tương tự, hệ thống công không có những cơ sở như Johns Hopkins để trả tiền giải quyết vấn đề.
Mọi người cho rằng các mô hình ngôn ngữ lớn (LLM) có thể vượt qua bác sĩ, vì chúng có khả năng xử lý 90% các trường hợp phổ biến.
Thông qua dự án LLM về sức khỏe, một người đã phát hiện ra các vấn đề y tế mãn tính mà hai chuyên gia VA và một PCP đã không chẩn đoán được.
Mô hình ngôn ngữ giỏi trong các nhiệm vụ liên kết tự do, như tìm kiếm ngữ nghĩa mơ hồ, trong khi dự đoán token tiếp theo là một trong những cách sử dụng tồi tệ nhất của chúng.
AI có thể là một công cụ phân loại các ca bệnh mới, đưa bệnh nhân trực tiếp đến đúng chuyên gia, từ đó tiết kiệm thời gian cho GP.
Hiện tại không cần giấy giới thiệu của GP để gặp chuyên gia, chỉ cần trả phí.
Các chuyên gia thường không chấp nhận các cuộc hẹn trực tiếp mà không có thư giới thiệu, vì họ không muốn phân loại 90% các trường hợp và hầu hết các cuộc hẹn tại văn phòng đều được lên lịch trước vài tuần đến vài tháng.
Việc có thể gặp trực tiếp chuyên gia hay không phụ thuộc vào khu vực và chuyên môn.
Có người đặt câu hỏi làm thế nào để ngăn chặn những người nói dối để tiếp cận các chuyên gia y tế.
Có người cho rằng ngay cả khi bệnh nhân nói dối cũng không sao, vì những lời nói dối thỉnh thoảng sẽ không dẫn đến kết quả tiêu cực lớn.
Có người đặt ra câu hỏi tại sao AI phải “đánh bại” bác sĩ, thay vì “tăng cường” hoặc “cải thiện” dịch vụ y tế.
Có người cho rằng chỉ có AI mới có thể giải quyết các vấn đề trong các lĩnh vực như y tế, giáo dục, bán hàng, nhân sự, v.v., vì hệ thống quan liêu nhân tạo và hiệu suất hệ thống kém.
Bất kỳ AI nào cũng sẽ phản ánh sự thiên vị của bộ máy quan liêu chịu trách nhiệm tạo ra chúng.
AI có thể được lập trình để kiên nhẫn hơn, điều tra các trường hợp biên và cung cấp dịch vụ tùy chỉnh, từ đó giải quyết vấn đề này.
Việc thu thập dữ liệu tự nó là một vấn đề lớn, đặc biệt là thu thập dữ liệu lâm sàng chất lượng cao.
OpenAI không thiếu vốn đầu tư, nhưng thiếu nguồn dữ liệu lâm sàng chất lượng cao.
Ngay cả khi AI có vấn đề, nhưng trong bối cảnh không có hệ thống phi AI hoàn hảo nào tồn tại, OpenAI đã khá tốt rồi.

Tôi đã triển khai lại Stable Diffusion 3.5 từ đầu bằng PyTorch thuần túy #

I have reimplemented Stable Diffusion 3.5 from scratch in pure PyTorch

https://github.com/yousef-rafat/miniDiffusion

miniDiffusion là một mô hình Stable Diffusion 3.5 được triển khai lại bằng PyTorch thuần túy, với số lượng phụ thuộc tối thiểu. Dự án này được thiết kế cho mục đích giáo dục, thử nghiệm và hack. Triết lý thiết kế của nó là xây dựng lại Stable Diffusion 3.5 từ đầu với lượng mã tối thiểu, chỉ khoảng 2800 dòng mã, bao gồm từ VAE đến DiT đến các script huấn luyện và dataset.

File: Mã mô hình stable diffusion chính nằm trong dit.py, dit_components.py và attention.py. File dit.py chứa mô hình chính, dit_components.py chứa các hàm hỗ trợ cho embedding, normalization, patch embedding và mã DiT, attention.py chứa việc triển khai joint attention. noise.py là nơi đặt Euler scheduler, được sử dụng để giải quyết ODE của Rectified Flow. Bộ mã hóa văn bản nằm trong t5_encoder.py và clip.py, và bộ tokenizer của chúng đều nằm trong tokenizer.py. metrics.py triển khai Fréchet Initial Distance (FID). common.py là nơi chứa các hàm hỗ trợ cho việc huấn luyện, common_ds.py là một triển khai của một dataset có thể lặp lại, chuyển đổi dữ liệu hình ảnh thành dữ liệu huấn luyện cho mô hình DiT.
Thư mục: Thư mục model lưu trữ các checkpoint và log của mô hình đã huấn luyện. Thư mục encoder lưu trữ các checkpoint của các module khác (ví dụ: VAE, CLIP).

⚠️ Cảnh báo: Kho lưu trữ này vẫn có các tính năng thử nghiệm và cần được kiểm tra thêm.

Các thành phần bao gồm module tạo ảnh cốt lõi, việc triển khai VAE, CLIP và bộ mã hóa văn bản T5, việc triển khai bộ tokenizer byte-pair và single-byte, các thành phần SD3, mô hình biến đổi khuếch tán đa phương thức, Euler scheduler khớp dòng chảy, lấy mẫu log-normal, joint attention, các script huấn luyện và suy luận cho SD3.

Bắt đầu sử dụng:

Lấy kho lưu trữ: Thông qua lệnh git clone “https://github.com/yousef-rafat/miniDiffusion”.
Cài đặt các phụ thuộc: Sử dụng lệnh pip install -r requirements.txt.
Cài đặt checkpoint mô hình: Trước khi chạy script, hãy thêm token Hugging Face vào get_checkpoints.py. Sử dụng lệnh python3 encoders/get_checkpoints.py.

Giấy phép: Dự án này được cấp phép theo giấy phép MIT và được thiết kế cho mục đích giáo dục và thử nghiệm.

Về: Đây là một mô hình Stable Diffusion 3.5 được triển khai lại bằng PyTorch thuần túy.

Tài nguyên: Cung cấp thông tin Readme và giấy phép MIT.

HN | Độ nóng: 267 điểm | 36 bình luận | Tác giả: yousef_g #

https://news.ycombinator.com/item?id=44276476

Các triển khai tham khảo có thể có vấn đề về việc không được bảo trì và lỗi.
Các dự án Flux và minRF phù hợp cho người mới bắt đầu học và huấn luyện các mô hình khuếch tán nhỏ.
Mã của triển khai tham khảo có thể có vấn đề vì sử dụng triển khai tham khảo CLIP bị lỗi.
Việc sửa tokenizer không nên tốn quá nhiều công sức.
Có thể tắt CLIP trong Flux mà không ảnh hưởng đến chất lượng.
Quan điểm cho rằng mã quan trọng hơn trọng số đã được huấn luyện.
Cung cấp khóa học xây dựng Stable Diffusion trên fast.ai làm tài nguyên học tập.
Cho rằng kiến thức cơ bản được đề cập trong khóa học fast.ai vẫn hiệu quả và hữu ích.
Triển khai Stable Diffusion không có giới hạn về giấy phép.
Thuật toán là toán học nên không thể được bảo vệ bản quyền, nhưng mô hình thì có.
Việc triển khai mã có thể được bảo vệ bản quyền, việc bảo vệ bản quyền của trọng số là một vùng xám.
Nếu trọng số của OpenAI GPT 4 bị rò rỉ, cả thế giới có thể sử dụng miễn phí.
Dự án này cho phép sử dụng trọng số AI hiện có để chạy và tinh chỉnh mô hình, nhưng có thể có vấn đề về giấy phép.
Giấy phép cộng đồng hạn chế một số cách sửa đổi trọng số nhất định, không cho phép sử dụng trong sản xuất và tính phí.
Cho rằng dự án này là một bản viết lại phòng sạch/phòng bẩn.
Cho rằng triển khai PyTorch có thể gọi CUDA/C/một số thứ độc quyền, khó hiểu hơn so với triển khai PyTorch thuần túy.
Cho rằng dự án này là một dự án thú vị để tái phát minh bánh xe từ những nguyên tắc đầu tiên.
Hỏi về tính khả dụng của các nguồn học thuật gốc.
Hỏi liệu triển khai này có thuộc tính đặc biệt nào không, liệu một số phần có chậm hơn hoặc nhanh hơn không.
Hỏi liệu triển khai này có nắm bắt được sự chú ý giữa các token như SD 3.5 đầy đủ hay không, hoặc có được đơn giản hóa để rõ ràng hơn không.
Cho rằng “từ đầu” bây giờ có nghĩa là “trong PyTorch”.
Cho rằng bất kỳ bài đăng “từ đầu” nào cũng nên bắt đầu bằng một liên kết đến video kỹ thuật gốc.
Không quan tâm đến dự án này trừ khi tác giả được nuôi dưỡng bởi tinh tinh.
Cho rằng nên triển khai dự án này bằng ngôn ngữ assembly.

Mô Hình Ngôn Ngữ Tự Thích Ứng #

Self-Adapting Language Models

https://arxiv.org/abs/2506.10943

Tiêu đề: Mô hình Ngôn ngữ Tự thích ứng

Tác giả: Adam Zweiger, Jyothish Pari, Han Guo, Ekin Akyürek, Yoon Kim, Pulkit Agrawal

Tóm tắt: Các mô hình ngôn ngữ lớn (LLMs) rất mạnh mẽ, nhưng chúng tĩnh và thiếu cơ chế để điều chỉnh trọng số dựa trên các nhiệm vụ, kiến thức hoặc ví dụ mới. Bài viết này giới thiệu một khung có tên SEAL (Self-Adapting LLMs), cho phép LLMs tự thích ứng bằng cách tạo dữ liệu tinh chỉnh và hướng dẫn cập nhật của riêng chúng. Với một đầu vào mới, mô hình sẽ tạo ra một bản tự chỉnh sửa, bản này có thể tái cấu trúc thông tin theo những cách khác nhau, chỉ định các siêu tham số tối ưu hóa hoặc gọi các công cụ tăng cường dữ liệu và cập nhật dựa trên gradient. Thông qua tinh chỉnh có giám sát (SFT), những bản tự chỉnh sửa này dẫn đến các cập nhật trọng số lâu dài, cho phép mô hình liên tục thích ứng. Để huấn luyện mô hình tạo ra các bản tự chỉnh sửa hiệu quả, chúng tôi sử dụng một vòng lặp học tăng cường với việc cập nhật hiệu suất downstream của mô hình làm tín hiệu phần thưởng. Không giống như các phương pháp trước đây dựa vào các mô-đun thích ứng riêng biệt hoặc mạng lưới phụ trợ, SEAL sử dụng trực tiếp thế hệ của chính mô hình để kiểm soát quá trình thích ứng của nó. Các thử nghiệm về tích hợp kiến thức và khái quát hóa ít mẫu cho thấy SEAL là một bước đầy hứa hẹn hướng tới các mô hình ngôn ngữ có khả năng tự hướng dẫn thích ứng. Trang web và mã của chúng tôi có thể được truy cập tại liên kết sau: [liên kết].

Phân loại chủ đề: Học máy (cs.LG)

Định dạng trích dẫn: arXiv:2506.10943 [cs.LG]

Liên kết DOI: https://doi.org/10.48550/arXiv.2506.10943

Lịch sử gửi: Được gửi bởi Jyothish Pari, ngày 12 tháng 6 năm 2025.

Liên kết toàn văn: Có thể xem phiên bản PDF của bài báo, phiên bản HTML (thử nghiệm), mã nguồn TeX và các định dạng khác.

Thông tin giấy phép: Xem giấy phép.

Ngữ cảnh duyệt hiện tại: cs.LG

Tài liệu tham khảo và trích dẫn: NASA ADS, Google Scholar, Semantic Scholar, v.v.

Xuất trích dẫn BibTeX: Đang tải…

Mã, dữ liệu và phương tiện liên quan đến bài viết này: alphaXiv, CatalyzeX Code Finder for Papers, DagsHub, GotitPub, Huggingface, Papers with Code, ScienceCast, v.v.

Demo: Replicate, Hugging Face Spaces, TXYZ.AI, v.v.

Đề xuất các bài báo liên quan: Influence Flower, CORE Recommender, IArxiv Recommender, v.v.

Giới thiệu về arXivLabs: arXivLabs là một khuôn khổ cho phép các đối tác phát triển và chia sẻ các tính năng arXiv mới trực tiếp trên trang web arXiv. arXiv cam kết các giá trị về tính cởi mở, cộng đồng, sự xuất sắc và quyền riêng tư dữ liệu người dùng, đồng thời chỉ hợp tác với các đối tác tuân thủ các giá trị này.

HN | Độ nóng: 197 điểm | 54 bình luận | Tác giả: archon1410 #

https://news.ycombinator.com/item?id=44271284

Thuật toán NEAT/HyperNEAT và thuật toán được mô tả trong bài viết này đều nhằm giải quyết cùng một vấn đề, nhưng thuật toán trước tiến hóa cấu trúc mạng, thuật toán sau tiến hóa trọng số.
Phương pháp tự chỉnh sửa tối ưu hóa cách mô hình tự học cách tái cấu trúc thông tin thông qua học tăng cường, các loại kiến thức khác nhau cần các phương pháp biểu diễn khác nhau.
Mô hình tìm thấy định dạng huấn luyện tốt hơn thay vì chỉ nhiều dữ liệu hơn, nhưng vấn đề quên thảm khốc vẫn chưa được giải quyết.
Chi phí tính toán lớn, mỗi lần đánh giá phần thưởng mất 30-45 giây, không thực tế đối với hầu hết các trường hợp sử dụng, nhưng có thể đáng giá đối với xử lý tài liệu có giá trị cao.
Hạn chế là cần có các chỉ số đánh giá rõ ràng, phù hợp với các lĩnh vực tài liệu kỹ thuật hoặc nội dung giáo dục có thể tạo ra đánh giá.
Các mô hình ngôn ngữ lớn (LLMs) mạnh mẽ nhưng tĩnh, thiếu cơ chế thích ứng với các nhiệm vụ mới, quá trình học tập và suy luận hoàn toàn tách biệt.
Học tăng cường có thể được sử dụng để tinh chỉnh LLM, như Deepseek đã chứng minh.
Phản hồi tích cực và tiêu cực của người dùng đối với đầu ra có thể được sử dụng để huấn luyện LLM, huấn luyện bằng đầu vào và đầu ra.
Từ nghiên cứu tự điều chỉnh của Anthropic, mô hình có thể huấn luyện mô hình mới tốt hơn con người.
Nghiên cứu cách để LLM học hỏi trong công việc và các rào cản để đạt được mục tiêu này, chẳng hạn như chi phí, sự cố mô hình, v.v.
Chúng ta không biết làm thế nào để đạt được học tập liên tục, cần phải mở rộng không gian biểu diễn của mô hình trong khi vẫn giữ cho không gian biểu diễn ban đầu hầu như không thay đổi.
AI có thể cần “ngủ” hoặc nghỉ ngơi để đạt được học tập liên tục.

Các thuật toán thân thiện với SIMD để tìm kiếm chuỗi con (2018) #

SIMD-friendly algorithms for substring searching (2018)

http://0x80.pl/notesen/2016-11-28-simd-strfind.html

Bài viết này được viết bởi Wojciech Muła, chủ yếu thảo luận về ứng dụng của thuật toán tìm kiếm chuỗi trong tối ưu hóa tập lệnh SIMD (Single Instruction Multiple Data). Bài viết bắt đầu bằng cách giới thiệu các phương pháp được sử dụng trong các ngôn ngữ lập trình phổ biến để định vị chuỗi con trong chuỗi, chẳng hạn như hàm strstr của ngôn ngữ C, phương thức find của lớp std::string trong C++, các phương thức pos và index của chuỗi trong Python, v.v. Các phương pháp này được thiết kế để tìm kiếm một lần. Trong vài thập kỷ qua, nhiều thuật toán đã xuất hiện để giải quyết vấn đề này, và những thuật toán này có thể được chia thành hai loại lớn: các thuật toán dựa trên máy trạng thái hữu hạn xác định (DFA), chẳng hạn như Knuth-Morris-Pratt, Boyer-Moore, v.v.; và các thuật toán dựa trên so sánh đơn giản, chẳng hạn như thuật toán Karp-Rabin.

Bài viết chỉ ra rằng một vấn đề chính của các thuật toán tiêu chuẩn này là chúng mặc định rằng việc so sánh các cặp ký tự, tìm kiếm các bảng bổ sung và các điều kiện là rẻ, trong khi so sánh hai chuỗi con là tốn kém. Nhưng CPU máy tính để bàn hiện đại không đáp ứng giả định này, đặc biệt là trên CPU 64 bit, việc so sánh 1, 2, 4 hoặc 8 byte không có sự khác biệt. Khi bộ xử lý hỗ trợ các lệnh SIMD, chi phí so sánh các vectơ (tức là 16, 32 hoặc 64 byte) thấp như so sánh một byte duy nhất. Do đó, việc so sánh các chuỗi ký tự ngắn có thể nhanh hơn các thuật toán phức tạp tránh so sánh này.

Bài viết tiếp tục giới thiệu hai phương pháp sử dụng lệnh SIMD, cả hai phương pháp này đã được mô tả trong sửa đổi Rabin-Karp thân thiện với SIMD và tìm kiếm chuỗi SSE4. Bài viết hợp nhất các nội dung này, so sánh hai phương pháp và mở rộng tài liệu. Bài viết cũng trình bày kết quả hiệu suất của các triển khai khác nhau từ SWAR đến AVX512F.

Thuật toán Karp-Rabin thực hiện so sánh chuỗi con chính xác khi băm yếu bằng nhau. Một hàm băm được tính cho chuỗi con được tìm kiếm và một hàm băm khác được tính cho phần của chuỗi; trong mỗi lần lặp, hàm băm thứ hai được cập nhật với chi phí nhỏ. Giải pháp SIMD thay thế vị từ băm bằng vị từ vectơ, vị từ này được tính toán song song và hy vọng tính toán nhanh.

Bài viết trình bày chi tiết thuật toán “SIMD chung”, thuật toán này phù hợp với tất cả các tập lệnh SIMD và phương pháp SWAR. Nó sử dụng ký tự đầu tiên và cuối cùng của chuỗi con làm vị từ. Hai ký tự này được điền vào hai thanh ghi F và L tương ứng. Sau đó, trong mỗi lần lặp, hai khối chuỗi được tải. Khối đầu tiên (A) được đọc từ độ lệch i, khối thứ hai (B) được đọc từ độ lệch i + k - 1, trong đó k là độ dài của chuỗi con. Sau đó, các biểu thức vectơ F == A và B == L được tính toán. Bước này tạo ra một vectơ byte (hoặc mặt nạ bit), trong đó giá trị “true” biểu thị vị trí xuất hiện của chuỗi con tiềm năng. Cuối cùng, chỉ có so sánh chính xác chuỗi con được thực hiện ở những vị trí này.

Bài viết cũng thảo luận về cách chọn ký tự đầu tiên và cuối cùng của chuỗi con, cũng như cách triển khai các phiên bản SSE và AVX2. Các phiên bản SSE và AVX2 thực tế là giống nhau, đều sử dụng số lượng lệnh tối thiểu. Bài viết cũng đề cập rằng, vì chúng ta đã biết ký tự đầu tiên và cuối cùng khớp nhau, chúng ta không cần phải sử dụng memcmp để so sánh chúng nữa.

Cuối cùng, bài viết giới thiệu phương pháp SWAR, phương pháp này sử dụng phép toán XOR để so sánh đẳng thức, kết quả là không khi hai byte bằng nhau. Do đó, thay vì thực hiện phép AND trên các kết quả từng phần, phép toán OR được sử dụng. SWAR cần nhiều công việc hơn để định vị các byte không. Bài viết cung cấp một triển khai C++ cho vectơ 64 bit và thảo luận về một điều kiện bổ sung trong vòng lặp, mặc dù có vẻ không tối ưu lắm, nhưng việc tìm kiếm bit được thiết lập đầu tiên rồi xóa nó (như phiên bản SSE đã làm) sẽ chậm hơn.

HN | Độ nóng: 179 điểm | 28 bình luận | Tác giả: Rendello #

https://news.ycombinator.com/item?id=44274001

ripgrep sử dụng regex crate của Rust để tăng tốc tìm kiếm, ngay cả các biểu thức chính quy đơn giản cũng có thể hưởng lợi từ đó.
Các thuật toán tìm kiếm chuỗi được tối ưu hóa bằng SIMD nhanh hơn so với các triển khai memmem truyền thống Two-Way hoặc GNU libc.
Thuật toán chọn hai byte có tần suất xuất hiện thấp hơn thông qua phân phối tần suất nền, thay vì luôn sử dụng byte đầu tiên và cuối cùng của chuỗi mẫu.
Việc triển khai các thuật toán SIMD thường không xem xét các trường hợp biên, dẫn đến hành vi không xác định (UB).
Trong các ứng dụng thực tế, việc xử lý các trường hợp biên có thể rất khó khăn, trừ khi có các trường hợp sử dụng rất cụ thể, nếu không thì không muốn chạm vào tìm kiếm chuỗi SIMD.
C# cũng đã triển khai một số tối ưu hóa SIMD trong phương thức IndexOf.
Đối với độ dài haystack đã biết và chuỗi mẫu lớn, việc kết hợp phương pháp Quick Search có thể hữu ích hơn.
Có nhiều phương pháp SIMD khác nhau được sử dụng để tìm kiếm và phân tách chuỗi.
Một phiên bản sửa đổi của tìm kiếm cửa sổ LZ77 cố gắng sử dụng SIMD chung của Zig.
hparse sử dụng thuật toán SIMD để phân tích cú pháp HTTP nhanh.
Thuật toán swar có thể có hành vi không xác định do ép buộc dữ liệu căn chỉnh 1 byte thành căn chỉnh 8 byte.
Các thuật toán SIMD lý tưởng hóa hoặc mã giả thường không xem xét việc xử lý chính xác các điều kiện biên.
strstr của musl hoạt động tốt hơn libc, nhưng các thuật toán SIMD vẫn có thể cải thiện so với nó.
Các thuật toán SIMD có thể trở nên phức tạp bậc hai khi xử lý các chuỗi mẫu lớn, tuần hoàn, trong khi các thuật toán tránh hành vi bậc hai có chi phí thiết lập cao hơn.
Đối với các chuỗi nhỏ, mã thiết lập SIMD (căn chỉnh, tính toán kích thước, v.v.) thường đắt hơn tìm kiếm cơ bản hướng theo byte.

Triển khai Lập trình Logic #

Implementing Logic Programming

https://btmc.substack.com/p/implementing-logic-programming

Bài viết này thảo luận về việc triển khai lập trình logic, tác giả Sir Whinesalot giới thiệu sự khác biệt giữa lập trình logic và các mô hình lập trình khác (như lập trình thủ tục, lập trình hướng đối tượng và lập trình hàm). Mặc dù lập trình logic không phổ biến bằng ba mô hình còn lại, nhưng nó rất hiệu quả trong việc giải quyết một số loại vấn đề cụ thể.

Tổng quan về Lập trình Logic #

Lập trình logic khác với các mô hình lập trình truyền thống, nó không định nghĩa chương trình thông qua các hàm mà thông qua các quan hệ (hoặc vị từ). Trong lập trình logic, không có sự phân biệt rõ ràng giữa đầu vào và đầu ra, định nghĩa của các quan hệ rất linh hoạt và có thể được diễn giải theo nhu cầu.

Tác giả sử dụng Prolog làm ví dụ, trình bày cách định nghĩa các sự kiện và quy tắc đơn giản. Thông qua việc định nghĩa các vị từ như “male” và “female”, chương trình có thể biểu diễn giới tính của một số người. Ngoài ra, thông qua việc định nghĩa vị từ “parent”, có thể thiết lập mối quan hệ giữa cha mẹ và con cái.

Tác giả cũng giới thiệu cách tạo các quy tắc, ví dụ như “father (X, Y) :- male (X), parent (X, Y)” biểu thị rằng nếu X là nam và là cha mẹ của Y, thì X là cha của Y.

Truy vấn #

Thông qua cơ chế truy vấn của Prolog, người dùng có thể đưa ra câu hỏi, ví dụ như tìm kiếm cha của một người cụ thể hoặc tất cả các cặp cha con. Tính linh hoạt và khả năng truy vấn mạnh mẽ này là một ưu điểm lớn của lập trình logic.

Đệ quy và Quan hệ phức tạp #

Lập trình logic cho phép sử dụng đệ quy để định nghĩa các mối quan hệ phức tạp hơn, ví dụ như quan hệ tổ tiên. Tác giả trình bày cách sử dụng đệ quy để suy ra các mối quan hệ gia đình thông qua việc định nghĩa “ancestor (X, Y)”.

Hạn chế của Lập trình Logic #

Mặc dù Prolog mạnh mẽ, nhưng nó cũng có một số hạn chế, chẳng hạn như thứ tự thực thi có thể ảnh hưởng đến kết quả và bản thân Prolog không hoàn toàn mang tính khai báo. Sự không chắc chắn trong quá trình thực thi đòi hỏi sự cẩn trọng khi viết chương trình Prolog.

Giới thiệu về Datalog #

Tác giả chuyển sang tập trung vào Datalog, một tập hợp con của Prolog, không có tính Turing hoàn chỉnh. Datalog tập trung vào mô hình hóa các mối quan hệ và dễ dàng tối ưu hóa và kết thúc hơn. Mặc dù Datalog không thể phát triển các ứng dụng hoàn chỉnh, nhưng nó có tiềm năng ứng dụng rất lớn trong các truy vấn cơ sở dữ liệu, và tác giả tin rằng nó nên thay thế SQL làm ngôn ngữ chính của cơ sở dữ liệu.

Hiện thực hóa Datalog #

Tác giả đề xuất một thuật toán Naïve Evaluation đơn giản để hiện thực Datalog. Đây là một thuật toán điểm cố định từ dưới lên, bằng cách liên tục áp dụng các quy tắc cho đến khi không có sự kiện mới nào có thể suy ra được. Bài viết bao gồm các ví dụ mã Python, trình bày cách định nghĩa các cấu trúc cơ bản như biến, giá trị và vị từ, cũng như cách quản lý “cơ sở dữ liệu”.

Việc hiện thực cụ thể được chia thành một vài lớp:

Variable: Biểu diễn biến.
Atom: Biểu diễn việc sử dụng vị từ, bao gồm tên vị từ và tham số.
Rule: Biểu diễn quy tắc, bao gồm phần đầu và phần thân.
Predicate: Biểu diễn vị từ, bao gồm tập hợp các sự kiện và quy tắc.
Datalog: Quản lý toàn bộ cơ sở dữ liệu Datalog, cho phép thêm biến, vị từ, sự kiện và quy tắc.

Kết luận #

Bài viết nhấn mạnh lợi thế của lập trình logic trong việc mô hình hóa các mối quan hệ phức tạp, đồng thời thể hiện tiềm năng của lập trình logic thông qua các ví dụ triển khai bằng Datalog. Mặc dù lập trình logic không phổ biến trong lập trình chính thống, nhưng nó vẫn có giá trị quan trọng trong một số lĩnh vực cụ thể (như cơ sở dữ liệu và suy luận quan hệ).

HN | Độ nóng: 175 điểm | 56 bình luận | Tác giả: sirwhinesalot #

https://news.ycombinator.com/item?id=44272467

miniKanren và microKanren là những nguồn tài nguyên tốt để học lập trình logic, có thể hiện thực một engine lập trình logic hoàn chỉnh với ít code.
SICP 4.4 cung cấp một cách hiện thực lập trình logic dễ hiểu, phù hợp cho người mới bắt đầu.
Datalog không chỉ phù hợp cho cơ sở dữ liệu, mà còn là một công cụ tốt để hiểu lập trình logic.
Thông qua SICP để học cách hiện thực Prolog, có thể hiểu sâu hơn về cơ chế hoạt động bên trong của lập trình logic.
Tính đồng hình (homoiconicity) của ngôn ngữ Scheme giúp việc tạo ra các ngôn ngữ lập trình logic như quine trở nên dễ dàng hơn.
Có các phiên bản Datalog được đơn giản hóa, có thể đạt được cú pháp đơn giản hơn và sử dụng biến phi tuyến tính bằng cách hy sinh một số chức năng.
Có thể dịch chương trình Datalog thành SQL để tận dụng chức năng và hiệu suất của engine cơ sở dữ liệu.
Hiện thực engine Datalog thông qua Python AST + Z3 là một thử nghiệm thú vị.
Có thể dịch Datalog thành biểu thức bảng chung đệ quy (CTE) của PostgreSQL để giảm số lần khứ hồi cơ sở dữ liệu.
CTE đệ quy có thể hiệu quả hơn so với việc thực hiện lặp dữ liệu logic bằng các truy vấn riêng lẻ.
Cần một số kiến thức về toán học rời rạc để hiểu lập trình logic.
Brachylog là một ngôn ngữ lập trình logic để chơi code golf, cung cấp các phương pháp giải quyết vấn đề khác thường.
Thông qua miniKanren để hiện thực trình kiểm tra kiểu nhỏ, có thể liệt kê các chương trình đáp ứng các kiểu cụ thể.
Có những nghiên cứu đang cố gắng làm cho việc tạo LLM an toàn về kiểu trở nên khả thi.

Sự Suy Thoái Việc Làm Trong Ngành Công Nghệ #

The Tech Job Meltdown

https://www.professoraxelrod.com/p/the-tech-job-meltdown

Bài viết này thảo luận về hiện tượng hơn 500.000 lao động công nghệ bị sa thải kể từ năm 2023 và phân tích những nguyên nhân đằng sau đó. Bài viết chỉ ra rằng, điều này không phải do các nguyên nhân thường thấy như COVID, hiệu suất làm việc kém của lao động kỹ thuật, hiệu quả tăng lên của công nghệ AI, tuyển dụng quá mức hoặc vấn đề lao động H1B, mà là do sự kết thúc của chính sách lãi suất bằng không (ZIRP) và chi phí vốn tăng lên. Điều này dẫn đến việc đầu tư mạo hiểm trở nên kém hấp dẫn hơn, các công ty mới nhận được ít vốn hơn và các công ty hiện tại khó vay vốn hơn.

Bài viết tiếp tục phân tích quy định về xử lý thuế đối với chi phí nghiên cứu và phát triển (R&D) theo Điều 174 của Bộ luật Thuế vụ Hoa Kỳ. Trong 70 năm qua, các công ty Hoa Kỳ có thể khấu trừ ngay lập tức 100% “chi phí R&D đủ điều kiện”, đóng góp vào việc tạo ra hoặc cải tiến sản phẩm có thể được coi là giảm thuế. Chính sách này đã thúc đẩy sự thịnh vượng của công nghệ Hoa Kỳ, bao gồm Bell Labs, Microsoft, Apple, Google và Facebook. Tuy nhiên, Đạo luật Cắt giảm Thuế và Việc làm (TCJA) năm 2017 đã sửa đổi Điều 174, từ năm 2022, chi phí R&D phải được khấu hao trong 5 năm (nghiên cứu trong nước) và 15 năm (nghiên cứu nước ngoài). Sự thay đổi này đã loại bỏ tùy chọn khấu trừ ngay lập tức chi phí R&D, làm tăng gánh nặng thuế cho các công ty trong ngắn hạn.

Bài viết giải thích cách sự thay đổi quy tắc này làm tăng thu nhập chịu thuế của các doanh nghiệp, vì họ không còn có thể khấu trừ ngay lập tức chi phí R&D. Điều này dẫn đến căng thẳng về dòng tiền, đặc biệt đối với các công ty khởi nghiệp và các công ty công nghệ nhỏ phụ thuộc vào R&D. Để đối phó với gánh nặng thuế, các công ty buộc phải thực hiện các biện pháp như sa thải nhân viên. Ví dụ, một công ty nhỏ có thể sa thải một kỹ sư phần mềm với mức lương hàng năm là 200.000 đô la để trả hóa đơn thuế 189.000 đô la.

Bài viết cũng đề cập rằng, mặc dù thời gian khấu hao 15 năm đối với chi phí R&D ở nước ngoài có thể khiến việc thuê kỹ sư không phải người Mỹ trở nên kém ưu đãi về thuế hơn, nhưng trên thực tế, nó không mang lại hiệu quả như mong đợi. Thay vào đó, các công ty lớn đối phó bằng cách thuê ngoài R&D cho các quốc gia có hệ thống thuế thuận lợi hơn, dẫn đến mất việc làm ở Hoa Kỳ. Ví dụ, Google đã chuyển một số công việc sang Đức, Microsoft đã chuyển một lượng lớn công việc nghiên cứu sang Trung Quốc, không chỉ vì mức lương ở đó tốt hơn mà còn vì các công ty con địa phương tuân theo luật pháp của quốc gia sở tại, chứ không phải luật thuế của Hoa Kỳ.

Cuối cùng, bài viết chỉ ra rằng, Đạo luật Cắt giảm Thuế và Việc làm (TCJA) được thông qua năm 2017 là thành tựu lập pháp mang tính biểu tượng trong nhiệm kỳ của Tổng thống Trump, nó đã giảm thuế suất doanh nghiệp từ 35% xuống 21%, điều này trên giấy tờ có vẻ như là một tổn thất doanh thu lớn cho chính phủ liên bang. Để Đạo luật năm 2017 tuân thủ các quy tắc ngân sách của Thượng viện, các nhà lập pháp đã phải thực hiện một số biện pháp để bù đắp khoản lỗ này, bao gồm cả việc sửa đổi Điều 174. Kết quả của chiến lược thuế này là các kỹ sư Hoa Kỳ bị sa thải, đồng thời các công ty tái cấu trúc hoạt động ở nước ngoài. Điều này đã không diễn ra theo kế hoạch.

HN | Độ nóng: 164 điểm | 69 bình luận | Tác giả: mooreds #

https://news.ycombinator.com/item?id=44273790

Tiêu đề bài viết gây hiểu lầm, nội dung chủ yếu là về các luận điểm phản đối Mục 174, chứ không phải xu hướng việc làm.
Tác giả cho rằng Mục 174 là một trong những nguyên nhân dẫn đến sự suy thoái của ngành công nghệ, nhưng không phải là tất cả.
Có ý kiến cho rằng, việc chuyển chức năng công việc ra nước ngoài là nguyên nhân chính của việc sa thải, chứ không chỉ là Mục 174.
Có người chỉ ra rằng, sự trưởng thành của ngành, sự thiếu hụt các nền tảng phát triển mới và sự phản ứng dữ dội sau đại dịch đối với những công nhân tự tin hơn cũng là những yếu tố dẫn đến sự suy thoái của ngành công nghệ.
Có người cho rằng ảnh hưởng của Mục 174 tương đối nhỏ, việc bãi bỏ nó có thể không mang lại nhiều thay đổi.
Có người đề cập rằng, năm 2022 có nhiều sự kiện xảy ra đồng thời, bao gồm sự suy yếu của ảnh hưởng đại dịch, sự thay đổi chính sách bảo mật, bầu không khí kinh tế toàn cầu, lãi suất tăng, v.v., những điều này đều có ảnh hưởng đến ngành công nghệ.
Có người chỉ ra rằng, dự luật phân bổ ngân sách đang được Thượng viện xem xét đã bãi bỏ Mục 174.
Có người bày tỏ sự không hài lòng về các cuộc thảo luận về Mục 174 trên HN, cho rằng những cuộc thảo luận này bỏ qua việc dự luật đã được thông qua trong dự luật ngân sách.
Có người đặt câu hỏi tại sao cuộc thảo luận về Mục 174 không đề cập đến việc nó được bao gồm trong dự luật ngân sách lớn, có thể là do dự luật chứa nhiều nội dung không được hoan nghênh khác.
Có người phản đối những thay đổi của Mục 174, cho rằng điều này sẽ có lợi cho sự nghiệp của họ, không nên phản đối chỉ vì người khác có thể được hưởng lợi nhiều hơn.
Có người chỉ ra rằng, các dự luật tổng hợp lớn là một phương pháp lập pháp cố ý mơ hồ.
Có người đề cập rằng, lao động của kỹ sư phần mềm nước ngoài có thời gian khấu hao là 15 năm.
Có người đặt câu hỏi tại sao bài viết không đề cập đến “Đạo luật Vĩ đại và Xinh đẹp” của Trump, vì nó cũng chứa nhiều nội dung gây tranh cãi và không được hoan nghênh khác.

Báo cáo sự cố Google Cloud – 2025-06-13 #

Google Cloud Incident Report – 2025-06-13

https://status.cloud.google.com/incidents/ow5i3PPK96RduMcb1SsW

Sự cố về tình trạng dịch vụ của nền tảng Google Cloud: Nhiều sản phẩm GCP gặp sự cố dịch vụ

Trang trạng thái dịch vụ cung cấp thông tin về trạng thái của các dịch vụ Google Cloud. Nếu bạn gặp sự cố không được liệt kê trên trang này, vui lòng liên hệ bộ phận hỗ trợ. Để biết thêm thông tin về dịch vụ, hãy truy cập https://cloud.google.com/。

Các dịch vụ bị ảnh hưởng bao gồm API Gateway, Agent Assist, AlloyDB for PostgreSQL, Apigee, Apigee Edge Public Cloud, Apigee Hybrid, Cloud Data Fusion, Cloud Firestore, Cloud Logging, Cloud Memorystore, Cloud Monitoring, Cloud Run, Cloud Security Command Center, Cloud Shell, Cloud Spanner, Cloud Workstations, Contact Center AI Platform, Contact Center Insights, Data Catalog, Database Migration Service, Dataform, Dataplex, Dataproc Metastore, Datastream, Dialogflow CX, Dialogflow ES, Google App Engine, Google BigQuery, Google Cloud Bigtable, Google Cloud Composer, Google Cloud Console, Google Cloud DNS, Google Cloud Dataflow, Google Cloud Dataproc, Google Cloud Pub/Sub, Google Cloud SQL, Google Cloud Storage, Google Compute Engine, Identity Platform, Identity and Access Management, Looker Studio, Managed Service for Apache Kafka, Memorystore for Memcached, Memorystore for Redis, Memorystore for Redis Cluster, Persistent Disk, Personalized Service Health, Pub/Sub Lite, Speech-to-Text, Text-to-Speech, Vertex AI Online Prediction, Vertex AI Search, Vertex Gemini API, Vertex Imagen API, reCAPTCHA Enterprise.

Nhiều sản phẩm GCP gặp sự cố dịch vụ, sự cố bắt đầu vào ngày 12 tháng 6 năm 2025 lúc 10:51 và kết thúc vào ngày 12 tháng 6 năm 2025 lúc 18:18 (tất cả đều theo giờ Thái Bình Dương của Hoa Kỳ). Các khu vực bị ảnh hưởng bao gồm Johannesburg, Châu Á đa khu vực, Đài Loan, Hồng Kông, Tokyo, Osaka, Seoul, Mumbai, Delhi, Singapore, Jakarta, Úc đa khu vực, Sydney, Melbourne, Châu Âu đa khu vực, Warsaw, Phần Lan, Stockholm, Madrid, Bỉ, Berlin, Turin, London, Frankfurt, Hà Lan, Zurich, Milan, Paris, Toàn cầu, Doha, Dammam, Tel Aviv, Montreal, Toronto, Mexico, Sao Paulo, Santiago, v.v.

Tóm tắt báo cáo sự cố được công bố vào ngày 13 tháng 6 năm 2025 lúc 16:45 PDT:

Các sản phẩm Google Cloud, Google Workspace và Google Security Operations gặp phải lỗi 503 gia tăng, ảnh hưởng đến khách hàng có yêu cầu API bên ngoài. Chúng tôi vô cùng xin lỗi về tác động của sự gián đoạn này đối với khách hàng và cam kết sẽ cải thiện để tránh những tình huống tương tự xảy ra lần nữa.

Chuyện gì đã xảy ra?

Google và Google Cloud API được cung cấp thông qua mặt phẳng quản lý và kiểm soát Google API của chúng tôi. Các mặt phẳng quản lý và kiểm soát này được phân phối trên khắp các khu vực và chịu trách nhiệm đảm bảo rằng mọi yêu cầu API đến đều được ủy quyền và tuân thủ các chính sách và kiểm tra thích hợp (chẳng hạn như hạn ngạch). Lõi nhị phân, tức là Service Control, là một dịch vụ khu vực, nó đọc thông tin hạn ngạch và chính sách từ kho dữ liệu khu vực. Siêu dữ liệu của các kho dữ liệu này được sao chép gần như tức thời trên toàn cầu để quản lý các chính sách hạn ngạch của Google Cloud và khách hàng.

Vào ngày 29 tháng 5 năm 2025, Service Control đã thêm một chức năng mới để kiểm tra chính sách hạn ngạch bổ sung. Thay đổi mã và bản phát hành nhị phân này được triển khai theo từng khu vực, nhưng vì cần có một thay đổi chính sách để kích hoạt mã, nên đường dẫn mã bị lỗi chưa bao giờ được thực thi trong quá trình triển khai. Như một biện pháp phòng ngừa an toàn, thay đổi mã này đi kèm với một “nút đỏ” để tắt đường dẫn dịch vụ chính sách cụ thể.

Vấn đề là thay đổi này không có xử lý lỗi thích hợp và cũng không được bảo vệ bằng cờ tính năng. Không có xử lý lỗi thích hợp, con trỏ null dẫn đến sự cố nhị phân. Cờ tính năng được sử dụng để dần dần kích hoạt các chức năng mới trong các dự án của mỗi khu vực, bắt đầu với các dự án nội bộ, để chúng tôi có thể nắm bắt các vấn đề.

Vào khoảng 10:45 sáng PDT ngày 12 tháng 6 năm 2025, một thay đổi chính sách đã được chèn vào bảng Spanner khu vực mà Service Control sử dụng cho chính sách. Do tính chất toàn cầu của quản lý hạn ngạch, siêu dữ liệu này đã được sao chép trên toàn cầu trong vài giây. Dữ liệu chính sách này chứa các trường trống không mong muốn. Service Control sau đó đã thực hiện kiểm tra hạn ngạch đối với chính sách trong mỗi kho dữ liệu khu vực. Điều này đã đưa các trường trống vào thay đổi chính sách tương ứng và thực thi đường dẫn mã dẫn đến vòng lặp sự cố nhị phân. Do mỗi khu vực triển khai, điều này đã xảy ra trên toàn cầu.

Nhóm kỹ thuật độ tin cậy trang web của chúng tôi đã bắt đầu xử lý sự cố này trong vòng 2 phút. Trong vòng 10 phút, nguyên nhân gốc rễ đã được xác định và việc triển khai “nút đỏ” (vô hiệu hóa đường dẫn dịch vụ) đã bắt đầu. “Nút đỏ” đã sẵn sàng để triển khai trong khoảng 25 phút sau khi sự cố bắt đầu. Trong vòng 40 phút sau khi sự cố xảy ra, việc quảng bá “nút đỏ” đã hoàn tất và chúng tôi bắt đầu thấy các khu vực phục hồi, bắt đầu với các khu vực nhỏ hơn.

Ở một số khu vực lớn hơn, chẳng hạn như us-central-1, khi các tác vụ Service Control khởi động lại, nó đã tạo ra hiệu ứng bầy đàn đối với cơ sở hạ tầng cơ bản phụ thuộc (tức là bảng Spanner), dẫn đến quá tải cơ sở hạ tầng. Service Control không có triển khai lùi lại theo cấp số nhân ngẫu nhiên thích hợp để tránh tình trạng này. Việc giải quyết hoàn toàn us-central-1 mất khoảng 2 giờ 40 phút, vì chúng tôi đã hạn chế việc tạo tác vụ để giảm thiểu tác động đến cơ sở hạ tầng cơ bản và định tuyến lưu lượng truy cập đến cơ sở dữ liệu đa khu vực để giảm tải. Vào thời điểm đó, Service Control và dịch vụ API đã được khôi phục hoàn toàn ở tất cả các khu vực.

Các sản phẩm Google và Google Cloud tương ứng bắt đầu phục hồi, một số sản phẩm cần nhiều thời gian hơn tùy thuộc vào kiến trúc của chúng.

Lộ trình trước mắt của chúng tôi là gì?

Sau khi khôi phục, chúng tôi đã đóng băng tất cả các thay đổi đối với ngăn xếp Service Control và tạm dừng việc đẩy chính sách thủ công cho đến khi chúng tôi có thể sửa chữa hoàn toàn hệ thống.

Chúng tôi giao tiếp như thế nào?

Chúng tôi đã công bố báo cáo sự cố đầu tiên lên trạng thái dịch vụ đám mây khoảng 1 giờ sau khi sự cố bắt đầu, do cơ sở hạ tầng trạng thái dịch vụ đám mây bị ngừng hoạt động do sự gián đoạn này. Đối với một số khách hàng, cơ sở hạ tầng giám sát mà họ đang chạy trên Google Cloud cũng gặp sự cố, khiến họ không có tín hiệu về sự cố hoặc hiểu được tác động đối với doanh nghiệp và/hoặc cơ sở hạ tầng của họ. Chúng tôi sẽ giải quyết vấn đề này.

Phương pháp tiếp cận của chúng tôi là gì?

Ngoài việc đóng băng hệ thống như đã đề cập ở trên, chúng tôi sẽ ưu tiên và hoàn thành một cách an toàn những điều sau:

Chúng tôi sẽ mô-đun hóa kiến trúc của Service Control để cách ly chức năng và mở ra sự thất bại. Do đó, nếu kiểm tra tương ứng không thành công, Service Control vẫn có thể…

HN | Độ nóng: 160 điểm | 147 bình luận | Tác giả: denysvitali #

https://news.ycombinator.com/item?id=44274563

Báo cáo sự cố của Google Cloud tiết lộ những thiếu sót của họ trong việc xử lý lỗi, phạm vi kiểm thử và triển khai dần, một số người đặt câu hỏi liệu các tiêu chuẩn của Google có đang đi xuống hay không.
Có người suy đoán rằng việc sa thải hàng loạt và việc CEO đổ lỗi cho nhân viên có thể khiến nhân viên tập trung hơn vào tốc độ hơn là chất lượng, do đó ảnh hưởng đến văn hóa công ty.
Có người cho rằng, các công ty FAANG không phải là đỉnh cao của năng lực kỹ thuật, các tiêu chuẩn và thành tựu của họ phần lớn dựa trên những vấn đề họ cần giải quyết.
AWS hầu như không có sự cố nào về cách ly dữ liệu khách hàng, so với đó, hiệu suất bảo mật của AWS khá ổn định.
Có người cho rằng, mặc dù các công ty FAANG thuê một số chuyên gia xuất sắc, nhưng điều đó không có nghĩa là họ đứng đầu về năng lực kỹ thuật tổng thể.
Có người mỉa mai rằng, mỗi khi nghe thấy có công ty sử dụng Azure, anh ta sẽ vào các trang web rò rỉ công khai để kiểm tra dữ liệu của họ.
Có người cho rằng, việc triển khai thất bại là do dự án không phân bổ đủ nguồn lực kỹ thuật để hỗ trợ các mô hình triển khai mạnh mẽ và linh hoạt hơn, nhưng điều đó không có nghĩa là các kỹ sư bất tài.
Có người chỉ ra rằng, các sự cố toàn cầu của Google Cloud thường là do triển khai nhanh các cấu hình sai, nhưng Google Cloud đã cải thiện điều này.
Có người đề xuất rằng, nên có các tiêu chuẩn cao hơn cho việc triển khai cấu hình toàn cục để tránh việc bỏ qua các phương pháp hay nhất.
Có người cho biết, người dùng thường yêu cầu cập nhật hạn ngạch nhanh chóng và nhất quán trên các khu vực, điều này dẫn đến việc mọi người coi trọng trải nghiệm người dùng hơn là tính khả dụng.
Có người trích dẫn một báo cáo năm 1864, chỉ ra rằng ngay cả những công cụ nguy hiểm, mọi người cũng sẽ dần mất đi sự thận trọng ban đầu sau khi quen thuộc.
Có người đề cập rằng, độ tin cậy cao và các tiêu chuẩn cao của ngành hàng không đã bác bỏ quan điểm trên.

Năm mươi năm qua của quy hoạch tuyến tính số nguyên: Những tiến bộ thực tế gần đây #

Last fifty years of integer linear programming: Recent practical advances

https://inria.hal.science/hal-04776866v1

Bài viết này nói về quá trình phát triển của Quy hoạch tuyến tính nguyên (Integer Linear Programming, ILP) trong năm mươi năm qua, đặc biệt tập trung vào những tiến bộ gần đây trong các ứng dụng thực tế. Bài viết được đăng trên “Tạp chí Nghiên cứu Vận trù học Châu Âu” (European Journal of Operational Research), tác giả là François Clautiaux và Ivana Ljubić.

Bài viết trước hết chỉ ra rằng Quy hoạch tuyến tính hỗn hợp nguyên (Mixed-Integer Linear Programming, MILP) đã trở thành một nền tảng của vận trù học. Điều này có được là nhờ sự cải thiện hiệu quả của các bộ giải hiện đại, cho phép các bộ giải tìm ra lời giải tối ưu toàn cục cho các bài toán mà mười năm trước không thể giải được trong vài giây. Tính linh hoạt của các bộ giải này đã giúp chúng được ứng dụng thành công trong nhiều lĩnh vực như giao thông, logistics, quản lý chuỗi cung ứng, quản lý doanh thu, tài chính, viễn thông và sản xuất.

Mặc dù đã đạt được những thành công ấn tượng, bài viết chỉ ra rằng lĩnh vực MILP vẫn phải đối mặt với nhiều thách thức và là một lĩnh vực nghiên cứu rất tích cực. Bài viết cung cấp một cái nhìn tổng quan về những thành tựu đáng chú ý nhất đạt được trong các phương pháp giải quyết MILP. Do khối lượng tài liệu về chủ đề này là rất lớn, các tác giả đã có ý thức lựa chọn tập trung vào các khía cạnh tính toán và những cải tiến hiệu suất thực tế gần đây, nhấn mạnh các nghiên cứu báo cáo các thử nghiệm tính toán.

Bài viết tổ chức nội dung khảo sát thành ba phần chính, lần lượt dành cho phương pháp Nhánh và Cắt (Branch-and-Cut), phân tích Dantzig-Wolfe và phân tích Benders. Bài viết kết thúc bằng cách nhấn mạnh những thách thức đang diễn ra và các cơ hội trong tương lai trong nghiên cứu MILP.

Các từ khóa bao gồm Tối ưu hóa tổ hợp (Combinatorial Optimization), Quy hoạch tuyến tính hỗn hợp nguyên (Mixed-Integer Linear Programming), Phương pháp Nhánh và Cắt (Branch-and-Cut), Phân tích Dantzig-Wolfe và Phân tích Benders. Những từ khóa này bao gồm các kỹ thuật và phương pháp chính được thảo luận trong bài viết.

Siêu dữ liệu của bài viết cung cấp thông tin về tệp và bản xem trước, bao gồm liên kết tải xuống tệp chính, cũng như thông tin liên hệ và mã định danh ORCID của các tác giả François Clautiaux và Ivana Ljubić. Ngày gửi bài là 12 tháng 11 năm 2024 và ngày sửa đổi cuối cùng là 18 tháng 3 năm 2025. Mã định danh HAL của bài viết là hal-04776866, DOI là 10.1016/j.ejor.2024.11.018. Bài viết được phân loại trong lĩnh vực khoa học máy tính và toán học.

HN | Độ nóng: 151 điểm | 44 bình luận | Tác giả: teleforce #

https://news.ycombinator.com/item?id=44274567

Các trình giải quyết quy hoạch tuyến tính số nguyên (ILP) thương mại (như Gurobi) vượt trội hơn các trình giải quyết miễn phí/mã nguồn mở vì chúng hợp tác chặt chẽ với khách hàng để triển khai các tối ưu hóa tăng tốc cho các vấn đề cụ thể, bao gồm các phương pháp heuristic và chiến lược cắt tùy chỉnh.
Các nhà nghiên cứu trong lĩnh vực nghiên cứu hoạt động, bằng cách viết các phương pháp cắt và heuristic của riêng họ, thường có thể dễ dàng đánh bại các trình giải quyết như Gurobi, trong khi các công ty giải quyết liên tục thực hiện tối ưu hóa này bằng cách thuê các đội ngũ tiến sĩ và nhà nghiên cứu.
Các trình giải quyết mã nguồn mở bị giới hạn bởi nhiều vấn đề, bao gồm ngưỡng cao để tham gia vào lĩnh vực phát triển trình tối ưu hóa tiên tiến nhất, số lượng nhà nghiên cứu/nhà phát triển có thể đóng góp ít và các dự án mã nguồn mở ít có khả năng nhận được các ví dụ, dữ liệu hiệu suất và phân tích cần thiết để cải thiện trình giải quyết.
Các trình giải quyết SAT hiện đại là những ví dụ về các thuật toán tốt, không chỉ là heuristic, trong các vấn đề NP-khó, thuật toán CDCL là một trong số đó.
Các trình giải quyết thương mại lớn có nguồn lực và hỗ trợ khách hàng, dành nhiều thời gian để điều chỉnh trình giải quyết cho phù hợp với các vấn đề trong thế giới thực, bao gồm xác định các bài toán con đơn giản hơn hoặc các giải pháp gần đúng có thể được đưa trở lại bài toán đầy đủ.
Trong các lĩnh vực cần tối ưu hóa, chẳng hạn như các công ty giao dịch định lượng, các trình giải quyết mã nguồn mở thường không thể giải quyết các vấn đề lớn, dẫn đến các lỗi như tràn bộ nhớ.
Trong thực tế, các trình giải quyết được sử dụng rộng rãi trong việc lên lịch pin gia đình và xe điện, tối ưu hóa sự kết hợp của hàng ngàn hộ gia đình và giao dịch các kết hợp này.
Việc thiết lập giá giao ngay điện của EU được thực hiện thông qua việc chạy một trình giải quyết lớn, dự án Euphemia có giới thiệu về điều này.
Mặc dù có những ví dụ về việc cố gắng sử dụng các phương pháp học máy/trí tuệ nhân tạo để giải quyết những vấn đề này, nhưng thường thì lựa chọn tốt nhất vẫn là mua giấy phép Gurobi và sử dụng nó.
Có người đề cập rằng, so với 20 năm trước, các trình giải quyết hiện nay đã có những cải tiến đáng kể về thuật toán và khả năng tính toán, giúp giảm đáng kể thời gian giải quyết.
Có người hỏi về chi tiết định giá của Gurobi, nhưng vì bảo mật nên không thể chia sẻ, nhưng có đề cập rằng có các trình giải quyết MIP mã nguồn mở/phi thương mại miễn phí để sử dụng.
Gurobi cung cấp giấy phép tạm thời miễn phí, giới hạn ở kích thước bài toán 1000 nút, phù hợp cho việc học tập và dùng thử.
Có người hỏi về so sánh giữa trình giải quyết mã nguồn mở và lp_solve.